Spacing with collection spreads and slices

[zdenek-jelinek]

I'm using dotnet format during build validation and it fails if a spread in collection expression does not contain space between the operator and the operand. I find this surprising. It seems to conflict with range operator which has the opposite requirement - no spaces allowed.

To illustrate:

var values = (List<int>)[1, 2, 3, 4];

_ = values[1..]; // OK - no space
_ = values[1 ..]; // error WHITESPACE: Fix whitespace formatting. Delete 1 characters.

_ = values[..2]; // OK - no space
_ = values[.. 2]; // error WHITESPACE: Fix whitespace formatting. Delete 1 characters.

_ = (List<int>)[..values]; // error WHITESPACE: Fix whitespace formatting. Insert '\s'.
_ = (List<int>)[.. values]; // OK - contains space

_ = values is [var _, ..var _]; // error WHITESPACE: Fix whitespace formatting. Insert '\s'.
_ = values is [var _, .. var _]; // OK - contains space

This occurs even without .editorconfig, just using dotnet format --verify-no-changes.

Is there a way to configure the collection spread operator spacing, please? I haven't found anything in either Visual Studio or dotnet spacing editorconfig properties. I'd be happy even if it wasn't validated at all since currently it enforces style which is the opposite of what I want.

Ideally, I'd like to have an option to specify this behavior using .editorconfig like I do for e.g. binary operators and such. Where can I raise this as a request, please? I'd be inclined to raise IDE feature request ticket here but I'm not sure this is even the correct repo. I believe that this is not wholly in dotnet format's domain as Visual Studio also adjusts the spaces accordingly on reformat, so that led me here.

[CyrusNajmabadi]

Ranges and spreads are entirely different and intentionally have different spacing to reflect that. As you correctly surmised though, spreads and slice patterns are aligned in their requirements as they have a semantic relationship we want to preserve in Syntax.

[zdenek-jelinek]

Thank you for getting back to me with the explanation, this is much appreciated.

I have since come across #71219 and the related discussion under #31691 so I guess that answers the "Is there a way we could change this?" portion of my query. This has also now appeared as a question at SO (https://stackoverflow.com/q/78327529).

I must say, unfortunately, this is an area where what seems logical from language designer perspective will be in contrast with what some people - including me - expect and find natural. And the logical explanation will probably not suffice.

That being said, I'm happy to know that if the interest is big enough, something might be done.

[CyrusNajmabadi]

And the logical explanation will probably not suffice

Generally, that would be how it ends up. We have to balance engineering costs with the truth that there are always small groups that will not be happy with a default (even if logical and intentional).

Fortunately, an extensible formatter would help here. And that is something we are interested in.