# 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.