Triage:
- XML doc comment features
- New
foreach
pattern usingLength
and indexer - Object initializers for
readonly
members readonly
struct methodsparams Span<T>
- Nullable reference type features on
Nullable<T>
Proposals:
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.
Proposal: #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.
Proposal: #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.
Proposal: #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.
Proposal: #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.
Proposal: #1865
Let's look at this for 8.0 if only to make sure doing it later is not a breaking change.