A potential bug in custom string interpolation constructor resolving for ref parameters

[PaulusParssinen]

Version Used: VS Version 17.10.0 Preview 7.0 - reproduces against main branch (see SharpLab)

As discussed on the C# discord, here's the minimal repro (a left out implementation details, the issue is the binding of the interpolation ctor)

A minimal repro: SharpLab

Diagnostic Ids: CS1620, CS8350, CS8352

Expected Behavior: The instance method binds the interpolated handler constructor similarly to the extension method.

Actual Behavior: Various ref safety diagnostics emitted for the instance variant.

Not critical but it'd be also nice to have same lowering for the instance versions as the extension varitant (while testing various different combinations of ref keywords, I saw a lot of local tmps , while this static extension has none)

[333fred]

So, I'm thinking this is not bug (or at least, not an implementation bug. It may be a specification bug.) The constructor resolution section of the interpolated string handler specification says this (emphasis added):

• Otherwise, the type of every resolved px is added to the argument list, in the order specified by the Arguments array. Each px is passed with the same ref semantics as is specified in M1.

Where px is the parameter of the resolved constructor, and M1 is the method being called (Append_Instance or Append_Extension in this case). The ref semantics of the receiver of an instance method isn't well-specified as far as I can tell; however, I'm somewhat unconvinced it should be allowed to be treated as ref implicitly, given that we may or may not emit dups for some structs. Should this code compile if the builder was a readonly parameter, for example? To make forward progress on this, I think a full rules change for C# would need to be proposed, specifying when a receiver would be allowed to be passed by ref to the constructor of an interpolated string handler; those rules could then be verified and reviewed, and we would have a full spec to test the implementation against. That would need to be opened on csharplang, and I would likely be willing to champion such a feature, but the proposal would need to come from someone else.