Allow ref struct primary constructor to capture ref-like (inside) parameters

[dellamonica]

A ref struct can have a primary constructor, just as regular classes/structs, however, C# will complain if you actually use the parameters anywhere other than initializing a field in the ref struct (see CS9110: Cannot use primary constructor parameter that has ref-like type inside an instance member.)

This proposal asks for this restriction to be lifted, allowing primary constructors to capture any ref-like parameter that is used by the type.

[TahirAhmadov]

If all PC params are auto-promoted to fields, it becomes a lot more like a record, no? Not saying it's a bad thing, but definitely a slightly different behavior than PCs on classes and regular structs.
I am curious, though, as to why the same behavior as classes/regular structs wasn't adopted WRT PC params - if it's used, promote it, otherwise don't.

[dellamonica]

Indeed, it looks more like a record. Since ref structs cannot be records, we already have some difference in the language behavior that are particular to ref structs.

I feel like if this proposal would be done, it makes for a very convenient way to use them as low overhead, no allocation substitutes for lambdas (obviously carrying all the restrictions of being always on the stack).

[HaloFour]

I think the ask is to allow ref captures in ref struct:

// legal
public struct Foo1(int x) {
    public int M() => x;
}

// also legal
public ref struct Foo2(int x) {
    public int M() => x;
}

// also legal
public ref struct Foo3(ref int x) {
    // manually capturing to a field
    private ref int x = ref x;

    public ref int M() => ref x;
}

// not legal
public ref struct Foo4(ref int x) {
    // error CS9109: Cannot use ref, out, or in primary constructor parameter 'x' inside an instance member
    public ref int M() => ref x;
}

[dellamonica]

It applies to PC argument types that are ref like too, not only refs.

[HaloFour]

Presumably for the same reasons.

[jaredpar]

This proposal asks for an automatic promotion of the parameters to fields (with the same name as the parameter) since it is the only thing you can actually do with them.

An automatic promotion or only when they are used?

[dellamonica]

But this is exactly the inconsistency pointed out by this discussion! For ref struct you are not allowed to capture the PC ref-like parameter (CS9109, CS9110). By auto promoting it to a field, it would effectively work as a capture. Maybe I'm not seeing any difference between auto-promotion and capturing. Is there some?

Regarding the ref like types, I think it makes sense to cover them as well. As you said, it is an expert feature and an expert should know that capturing requires a field in the ref struct.

As I said in another remark, a good use case for ref structs is for substituting lambdas, and PCs with ref capture/promotion can reduce the amount of boilerplate code.

[CyrusNajmabadi]

Maybe I'm not seeing any difference between auto-promotion and capturing. Is there some?

A capture is not a field. It is just a parameter, used normally within the bodies of members (like any other parameters). It is not visible externally. A field is a field. It can be accessed off of this (unlike a parameter). It can be accessed off of another instance (like other.theField (unlike a parameter). etc. etc. Fields and parameters are very different, and as such auto-promotion to field is very different from capturing.

[dellamonica]

Maybe I'm not seeing any difference between auto-promotion and capturing. Is there some?

A capture is not a field. It is just a parameter, used normally within the bodies of members (like any other parameters). It is not visible externally. A field is a field. It can be accessed off of this (unlike a parameter). It can be accessed off of another instance (like other.theField (unlike a parameter). etc. etc. Fields and parameters are very different, and as such auto-promotion to field is very different from capturing.

Sure, I was more focused on the implementation side, where the capture will have to be mapped to a field of the struct. Of course, it can be mapped to a private field with unspeakable name so you can't access it outside the scope of the capture.

If you guys feel that capturing is more in line with the language, then I'd change the proposal from promotion to capture.

[CyrusNajmabadi]

Well, it's more that auto-promotion is the realm of records. It would face a stiff uphill battle to be accepted. Relaxing the capturing restriction, on the other hand, is likely more palatable for the group and would likely solve the main use cases.

[dellamonica]

Updated the title/initial comment.

[jaredpar]

Think the idea of allowing a ref struct to capture ref struct parameters in the primary ctor is pretty reasonable. There really aren't many complications there I can think of.

There are complications to consider though when this is extended to all ref like arguments. Consider for example the following:

ref struct S1(Span<byte> span) 
{
  // legal
  Span<byte> Span => span;
}

ref struct S2(ref Span<byte> span)
{
  // can't be legal
  Span<byte> Span => span;
}

The reason being that you cannot have ref struct as a ref field today (language limitation).

Beyond that I'm still a bit hesitant about the idea of allowing capture of ref / in parameters as they end up creating ref fields under the hood. That is not ground we've crossed in the compiler before and I'm not sure it will match customers intuition around behavior. Having a ref field is very much expert territory and silently creating one feels a bit too far.

[dellamonica]

I agree that a ref of a Span is overkill, however the ref-like that is currently forbidden is Span itself.

The following code gives a CS9110.

[jaredpar]

Generally when we say ref like we mean locations that are either a ref struct or a ref / in / out. Those are both ref like. When speaking about simply types like Span<T> and not ref / in / out then we typically simplify to just ref struct as it's more accurate.

[dellamonica]

I'm just using the language of the error (CS9110)

Cannot use primary constructor parameter 'x' that has ref-like type inside an instance member

In case of the span argument, the key word here is "inside" so I've updated again the title to reflect this.

[jaredpar]

I'm just using the language of the error (CS9110)

Understood. I'm just trying to elaborate on why I'm choosing the particular language that I'm using here.