Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
alrz opened this issue Oct 21, 2017 · 10 comments

Comments

@alrz
Copy link
Contributor

commented Oct 21, 2017

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:

@jcouv jcouv added the Discussion label Oct 22, 2017

@jcouv

This comment has been minimized.

Copy link
Member

commented Oct 22, 2017

Tagging @VSadov in case something to add.

@alrz

This comment has been minimized.

Copy link
Contributor Author

commented Oct 26, 2017

@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

This comment has been minimized.

Copy link

commented Oct 27, 2017

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

@alrz

This comment has been minimized.

Copy link
Contributor Author

commented Oct 27, 2017

@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

This comment has been minimized.

Copy link

commented Oct 27, 2017

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

This comment has been minimized.

Copy link

commented Oct 27, 2017

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

This comment has been minimized.

Copy link
Member

commented Nov 3, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Nov 4, 2017

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

This comment has been minimized.

Copy link
Member

commented Dec 13, 2017

@jcouv jcouv changed the title Discussion: ref this vs this ref in ref extension methods Discussion: ref this vs this ref in ref extension methods (15.6, as a 7.2 bug fix) Jan 4, 2018

@jcouv

This comment has been minimized.

Copy link
Member

commented Jan 9, 2018

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

@jcouv jcouv reopened this Jan 9, 2018

@gafter gafter assigned jcouv and unassigned VSadov Jan 9, 2018

@gafter gafter added this to C# 7.3 in Language Version Planning Mar 6, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.