Omit this
when using extension methods within extended type?
#2762
Replies: 3 comments
-
better betterness removes further invalid candidates, extension everything is about what kind of member you can define as extension, on the other hand, this is more about binding, currently only "member access" fallback to extension lookup, not simple identifiers. As far as I can tell, this couldn't make anything ambigious because extension lookup comes last in the binding sequence. This probably get cut due to the easy workaround and because you don't often call "extensions" from inside of the class itself - if it's going to be an extension i.e. not part of class contract, why it needs to be called from the type itself? so it's probably a good idea to just make it an instance member. |
Beta Was this translation helpful? Give feedback.
-
The extension method might be something like linq that operates on a range of types, rather than this specific type. |
Beta Was this translation helpful? Give feedback.
-
This proposal makes sense when base class is from one downloaded Nuget package, and the extension is from another. |
Beta Was this translation helpful? Give feedback.
-
Background code:
Without proposed feature:
With proposed feature:
This is a quite minor "better betterness" feature, but maybe it would compliment the "extension everything" set of changes #192. Unless of course there is something fundamentally wrong with this from language design point?
Beta Was this translation helpful? Give feedback.
All reactions