Syntactic ambiguity with .. in range, list-remainder, spread syntaxes, and what should we do about them.

[CyrusNajmabadi]

For context, we use .. in teh following fashions.

For range expressions:

    start..end // corresponds to new Range(index1, idnex
    start..    // corresponds to start..^0
    ..end      // corresponds to 0..end
    ..         // corresponds to 0..^0

With list patterns (coming soon):

var x is [p1, .. var rem, p2, p3]; // here `..` effectively corresponds to `x[1..^2]`

With collection expressions (hopefully coming in a future release):

var x = [e1, e2, .. c1, e3, e4, .. c2 ]; // here .. is used to 'spread' the elements of c1/c2 into the final result.

This all works decently well, and allows .. to generally represent the idea of something rangish. e.g. you can squint and see how in list patterns that .. collects a sub-range of the the original object, just with indices determined by the patterns around it. For collection expressions it kind of says "grab the whole range of a collection and add all the items in that range into the final collection".

However, this raises some syntactic concerns.

First, while there is no syntactic ambiguity with patterns today, there may be in the future. For example, by our 'correspondence principle' we might want to have a range pattern in the future which might look like this: if (x is (var p1 .. var p2)) { ... } to grab out the indices from a range (and potentially have deeper patterns for those parts).

Second, for expressions this is purely syntactically ambiguous. ..c2 has meaning today as a range-expression. To have it now mean spread-expression would mean something very different based on context. This introduces papercuts such as forcing users to parenthesize if they actually want a collection of ranges. e.g.: [.., e1.., (..e2)].

Do we want to go forward with reusing .. for all these meanings? Or should we consider a path that avoids that?

[jnm2]

Extracting the indices from a range and having deeper patterns for those parts could be achieved using a range Deconstruct method: if (x is (var p1, var p2)). It wouldn't correspond syntactically but it would be consistent with what you'd see for types like Point.

[333fred]

Addressed in LDM: https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-03-09.md#ambiguity-of--in-collection-expressions.

Conclusion: we think we can be smart here about "splattable" contexts, and that we can have both forms in the language without an issue.