108 lines
3.7 KiB
Markdown
108 lines
3.7 KiB
Markdown
|
|
||
|
# C# Language Design Notes for September 19, 2018
|
||
|
|
||
|
## Agenda
|
||
|
|
||
|
Triage:
|
||
|
|
||
|
1. XML doc comment features
|
||
|
2. New `foreach` pattern using `Length` and indexer
|
||
|
3. Object initializers for `readonly` members
|
||
|
4. `readonly` struct methods
|
||
|
5. `params Span<T>`
|
||
|
6. Nullable reference type features on `Nullable<T>`
|
||
|
|
||
|
## Discussion
|
||
|
|
||
|
### XML Doc and related features
|
||
|
|
||
|
Proposals:
|
||
|
|
||
|
- https://github.com/dotnet/csharplang/issues/313
|
||
|
- https://github.com/dotnet/csharplang/issues/1766
|
||
|
- https://github.com/dotnet/csharplang/issues/1767
|
||
|
- https://github.com/dotnet/csharplang/issues/1768
|
||
|
- https://github.com/dotnet/csharplang/issues/315
|
||
|
- https://github.com/dotnet/csharplang/issues/320
|
||
|
- https://github.com/dotnet/csharplang/issues/401
|
||
|
- https://github.com/dotnet/csharplang/issues/1764
|
||
|
- https://github.com/dotnet/csharplang/issues/1765
|
||
|
|
||
|
We're not very excited about designing features in doc comments, primarily
|
||
|
because a lot of design work depends more on tooling ecosystem than language
|
||
|
design. It seems like there's a lot of coordination that should happen
|
||
|
outside LDM before we look at it inside LDM. Most of the features aren't
|
||
|
useful without a near-term guarantee of tooling support.
|
||
|
|
||
|
**Conclusion**
|
||
|
|
||
|
We need the tooling and ecosystem designers and owners to weigh in before
|
||
|
we're ready to move forward. Specifically, we need a fully fleshed out,
|
||
|
detailed proposal for exactly what the total work is and a timeline for
|
||
|
completion. Once that's in place, we should consider all the XML doc comment
|
||
|
changes at once. We're moving this into an `X.0` release, since we think the
|
||
|
tooling changes merit a major release and we are blocked on external work.
|
||
|
|
||
|
### New `foreach` pattern using `Length` and indexer
|
||
|
|
||
|
Proposal: https://github.com/dotnet/csharplang/issues/1424
|
||
|
|
||
|
There are a bunch of options around signaling support for this feature
|
||
|
without incurring a breaking change, including using an attribute, using a
|
||
|
new interface, considering a new pattern (including the ref/ref-readonly
|
||
|
variants). `foreach` already has a lot of different variants, so any change
|
||
|
has to fully account for all the possibilities.
|
||
|
|
||
|
It's also notable that we've seen LINQ performance as a concern for quite a
|
||
|
while and we haven't ruled out doing something for that. If we add a new
|
||
|
interface for LINQ we might want to use the same interface as a trigger for
|
||
|
new optimizations here. We almost certainly wouldn't want to create a
|
||
|
duplicate interface.
|
||
|
|
||
|
**Conclusion**
|
||
|
|
||
|
We don't like this specific proposal, but will continue to look at features
|
||
|
in this area.
|
||
|
|
||
|
### Readonly object initializers
|
||
|
|
||
|
Proposal: https://github.com/dotnet/csharplang/issues/1684
|
||
|
|
||
|
**Conclusion**
|
||
|
|
||
|
A lot of crossover with records proposals here. This seems like more of a special
|
||
|
case -- let's see if we can make a generalization work before we go this route.
|
||
|
|
||
|
### `readonly` functions on structs
|
||
|
|
||
|
Proposal: https://github.com/dotnet/csharplang/issues/1710
|
||
|
|
||
|
First concern is ordering restrictions of the "readonly" modifier. It can
|
||
|
also indicate a "readonly ref" return type, so we need to make sure it's not
|
||
|
ambiguous.
|
||
|
|
||
|
There's also another option: do we allow explicit receivers so the user could
|
||
|
specify `void M(in this S s)` and explicitly declare the variables which are
|
||
|
readonly?
|
||
|
|
||
|
**Conclusion**
|
||
|
|
||
|
We're interested. Let's keep the design as-is for now.
|
||
|
|
||
|
### `params Span<T>`
|
||
|
|
||
|
Proposal: https://github.com/dotnet/csharplang/issues/1757
|
||
|
|
||
|
This would be especially interesting if the CLR implements a new feature for
|
||
|
stack allocating an array of reference types.
|
||
|
|
||
|
**Conclusion**
|
||
|
|
||
|
Let's keep it in C# 8. A lot of stuff to work out here.
|
||
|
|
||
|
### Add nullable reference type features to nullable value types
|
||
|
|
||
|
Proposal: https://github.com/dotnet/csharplang/issues/1865
|
||
|
|
||
|
Let's look at this for 8.0 if only to make sure doing it later is not
|
||
|
a breaking change.
|