Add: allow ref this parameter in extension methods for variables created implicitly by the compiler

[marchewek]

First things first to set the context - I find myself very good in object-orientation paradigm and consistency (as a kind of life philosophy), but I never excelled in the low level stuff (main reason I decided to stick with C# instead of C++). Therefore my finding doesn't have to necessarily be a "missing language feature" but simply a "documentation about that low level stuff in C# is poor"-kind-of finding. Please keep that in mind going forward. I'm also not an English-native, so please forgive me any linguistic mistakes I made along the way. This is a follow up to the original post I made in the incorrect repo*.

As pointed out in my original post, the language right now behaves differently for explicit and implicit variables (by implicit I mean a variable created by the compiler in the background):

public class TestCode
{
	internal static void Main()
	{
		// with explicit variable it works well
		var x = new SomeStruct();
		x.ExtensionsRefParam();
		x.ExtensionRefParamRefRet();

		// with implicit variable neither compiles (triggers CS1510)
		new SomeStruct().ExtensionsRefParam();
		new SomeStruct().ExtensionRefParamRefRet();

		// compiles, but copies the struct, so out of scope; kept for completeness 
		new SomeStruct().InstanceMethod();
		new SomeStruct().ExtensionNoRefParam();
	}
}

public struct SomeStruct
{
	public SomeStruct InstanceMethod()
	{
		return this;
	}
}

public static class SomeExtensions
{
	public static SomeStruct ExtensionNoRefParam(this SomeStruct @this)
	{
		return @this;
	}

	public static SomeStruct ExtensionsRefParam(ref this SomeStruct @this)
	{
		return @this;
	}

	public static ref SomeStruct ExtensionRefParamRefRet(ref this SomeStruct @this)
	{
		return ref @this;
	}
}

Now as @stephentoub pointed out in the original post, I could use the "in" indicator for the argument and in my case that actually solved the problem - I never intended to modify the implicit variable. But what if someone actually wants to modify the variable? Why make it inconsistent between an explicit and implicit variable?

Once again, my finding comes mostly from consistency standpoint; if this is something impossible due to technical constraints or I am asking for something that would enable some explicitly-unintended scenarios then maybe improving documentation about this part of language would be good enough.

[EDIT 1]
The OP lacked particular use cases, so here are the two that emerged from the discussion.

1. Implementing the fluent builder pattern via extension methods while at the same time not wanting to copy the struct in (ref parameter) nor out (return ref), because the structure is big:

var built = new SomeStruct().Config1().Config2().Config3().Build();

2. Implementing the fluent configuration pattern while [... the same as above]:

var someStruct = ref new SomeStruct().Config1().Config2().Config3();

Personally I find ref here redundant (makes the syntax more complex), but it may be required due to technical constraints (makes the language definition less complex).

* sorry about that; those are my baby steps in contributing to C#

[HaloFour]

I mean, it is consistent in that you can't pass that expression to a method that accepts a ref parameter either. But beyond that, doing something for the sake of consistency doesn't seem to be all that important if the feature doesn't provide value by itself.

[marchewek]

I think you have a misunderstanding of lang design

And I think we just use different architecture documentation standards. When I implement anything that is shared I document which scenarios I decided to address and which I decided not to address, both with some rationale.

So far, that case has not been made.

For me it's a natural extension of "we allow you to reduce the number of heap allocations (use structures instead of classes) and avoid copying them in case they are large (with ref-in and ref-out)".

I did provide two use cases and updated the post, what should be enough to showcase the intended scenario. If you don't like that idea, then I guess fine, you don't have to, and feel free to close the discussion.

[jilles-sg]

You can do something like this today:

using System.Diagnostics.CodeAnalysis;

struct SomeStruct {
    [UnscopedRef]
    public ref SomeStruct StartBuilding() => ref this;
}

Once StartBuilding has been called, it's also possible to call extension methods.

The nice thing about mutating the receiver and returning ref (apart from performance considerations) is that the return value can be ignored, so both

var result = new SomeStruct().StartBuilding().Config1().Config2().Build();

and

SomeStruct builder = new();
builder.Config1();
builder.Config2();
var result = builder.Build();

work.

I kind of like the idea, but without move-only/non-copyable structs it is too easy to mutate a copy accidentally. So I don't think the first step here should be changing the behaviour of ref this extension methods.

[CyrusNajmabadi]

. When I implement anything that is shared I document which scenarios I decided to address and which I decided not to address, both with some rationale.

We have given our rationale. Specifically that we don't add support for language features that no compelling use case has been made for.

I did provide two use cases and updated the post, what should be enough to showcase the intended scenario.

The op does not do this. It demonstrates the feature, but gives no reason or example for why it's a good thing. It's telling that the name of the struct is simply "SomeStruct". Something vague without any actual example showing a use case where this would be wanted.

If you don't like that idea,

I don't have any opinion on the idea yet. All I've said is that we need compelling use cases to consider language support and that no good cases have been presented. And even the vague things that have been alluded to come with fairly substantial problems that we would be wary about.

[marchewek]

@jilles-sg thanks for the idea 👍 it requires some modification of the original structure though.

@CyrusNajmabadi sorry for not meeting your demand to provide a very concrete use case; it's because I don't have one. My line of thought was more on a conceptual level - it was like "here you have reference types, but meh it's heap allocation, garbage collection takes time and stuff, so we want to allow you to write some more efficient code by using stack allocations instead, so we added ref in (a long time ago) and a ref out (recently), but you know what? no, you won't be able to write the same API on classes and ref structs fully avoiding copying (in other words - you won't have the same developer experience), though conceptually both are pointers to memory (just in a different location)" and I thought like "well, this is a bit surprising", because I was expecting to be able to get similar behavior for ref structs that I had for classes and instead I got a compiler error.

That said, it doesn't mean that I will suddenly switch to java (as we know they don't see sharp; sorry it was stronger than me).

I don't have any opinion on the idea yet.

Feel free to close the discussion if you come to a conclusion that you dislike it. I've already shared all my thoughts.

P.S. Yes, I will be missing details of defining the language - I wrote a compiler only once in my life, during my studies, some 15 years ago, and concluded that it's not my kind of thing. Luckily there are people who like this kind of stuff.

[CyrusNajmabadi]

sorry for not meeting your demand to provide a very concrete use case; it's because I don't have one

No worries.

Absent a use case, our default position is: we will not add support for it.

We have limited resources and tons of things that will be helpful, so we spend our efforts there.

When I implement anything that is shared I document which scenarios I decided to address and which I decided not to address

I wanted to address this. There are a finite set of things we have added support for, and an infinite number we haven't. We can't document the reasons for the infinite set of things as that would be an unending process :-)

[FaustVX]

You can use the in keyword instead of ref.

You just have to use ref readonly return on the last extension

sharplab.io

[marchewek]

Only if you don't intend to modify the argument; otherwise you should use ref...