Relaxing modifier order for ref struct

[huoyaoyuan]

Currently internal ref unsafe partial struct is invalid, and the error message is confusing. Only internal unsafe ref partial struct is valid.

The runtime repo is hitting this: dotnet/runtime#94840

There was a discussion in LDM: https://github.com/dotnet/csharplang/blob/main/meetings/2018/LDM-2018-04-04.md#ordering-of-ref-and-partial-keywords . Is there any further actions?

[ufcpp]

dotnet/roslyn#63010 (comment)

[333fred]

#946

The issue is in the Any Time milestone, which means we'd accept an implementation, but are probably not going to work on it ourselves unless we happen to be changing something else in the area.

[333fred]

It is marked as needs impl, not needs spec.

[huoyaoyuan]

What is the agreed form of this feature? Just relaxing ref and partial in the original issue, or relaxing all of them to satisfy this request?

/cc @alrz

[alrz]

I'm wondering if partial could be disallowed as a type name, that could make this slightly simpler, otherwise some complex lookaheads will be needed to decide what the next token really is while parsing type members (note this could meaningfully apply to partial methods and properties but also fields e.g. partial partial;). I'm not sure if that's an option.

(edit: partial fields could also be valid for adding attributes but that hasn't been discussed afaik; I think those need to be settled prior to this feature)

[CyrusNajmabadi]

partial as a type name shouldn't ever really be a problem. The typ ename has to come after the class/struct token, so it's clearly separated out from the modifiers.

[alrz]

That becomes a problem when talking about type members. Not saying it's impossible to do (definitely not as hard as collection expressions). Maybe using a different parsing strategy could help e.g scan to see how many true modifiers there are beforehand. But the one used in the prototype is not quite straightforward.