csharplang/meetings/2018/LDM-2018-09-19.md

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.