Discussion: ref this vs this ref in ref extension methods (15.6, as a 7.2 bug fix)

[alrz]

Currently this ref int is not permitted and you need to use ref this int while throughout the language ref T denotes a "ref type" and you may add this modifier on a parameter to define an extension method, so it would be sensible to use this ref int to define a ref extensions method. That being said, the restriction seems arbitrary, both could be allowed but IMO this ref int looks more natural based on current rules.

As a minor point, the fact that all extension method's parameter lists start with this makes it easier to scan for extension methods in a static class.

LDM:

• https://github.com/dotnet/csharplang/blob/master/meetings/2017/LDM-2017-12-04.md#this-ref-vs-ref-this

[jcouv]

Tagging @VSadov in case something to add.

[alrz]

@jcouv @VSadov Any news here? My impression is that this can't be done within 15.5 timeframe but maybe as part of #946? And tbh I can't see the rationale behind the current restriction. partial has had this restriction for a long time and it's ok to make it a "feature" but this is new, maybe it would be sensible to not restrict it in the first place..

[benaadams]

You can change the this pointer? So it is kinda ref this int?

[alrz]

@benaadams this is just a modifier, the actual "pointer" is the parameter itself, and that's of type ref T, making ref this int nonsensical. I'd go so far to say that we should only allow this ref T.

[benaadams]

I'd go so far to say that we should only allow this ref T.

Makes what would define an extension very explicit e.g. (this which is probably a good thing.

What would be readonly ref extension? e.g.

(this in T or (this readonly ref T

[ufcpp]

I also prefer (this ref T and (this in T. I'd rather like to know why the compiler team chose (ref this T from which I can't find any rationality.

[VSadov]

Both ref and this are modifiers to the parameter. The formal type of the parameter is T, regardless of the kind of argument passing.

We could allow parameter modifiers in any order and just picked one order to not allow more than necessary.

I.E. it can be relaxed to make combinations like (this in T self, ...) valid

[alrz]

I supposed ref and in are modifiers on the "type" because they change the type of the parameter to a T&. Anyways, relaxing the ordering is probably the best option here. Thank you.

PS: for comparison, consider ref int x = e; vs. const int x = e; the former denotes a "ref type" i,e. ref is part of the type, but the latter has const as a modifier on the whole declaration statement.

[jcouv]

FYI This was discussed in LDM https://github.com/dotnet/csharplang/blob/master/meetings/2017/LDM-2017-12-04.md

[jcouv]

Keeping the issue open so that it appears in the milestone as expected.
The fix was merged to 15.6