-
Notifications
You must be signed in to change notification settings - Fork 1k
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
[Proposal]: Re-rename to Roles and Extensions #8431
Comments
I get the argument, and I could agree it’s better than “implicit/explicit” extension, but I can’t shake the feeling that “role” is weird. Because an explicit extension/role is still conceptually an extension of the specified type, just one you only use in specific situations - a proxy type of sorts. I don’t know; Just my $0.02. |
Just my 2 cents: if we want to drop implicit/explicit, would "extension type" not be an option for roles? I agree that "role" sounds weird. To me an explicit extension (a role) is really just a type. You treat it exactly as if it were an actual type in code (you use it to declare parameters, locals, can cast to it, etc.). It's just that it's specifically also an extension, not a "real" type. So to me "extension type" seems intuitive in that sense, more than "role". With the latter you get into "what is a role", "what does a role mean", etc., whereas with the former, people will just look at it as "oh ok, it's just a type I can declare an use, cool". |
I suggest we use "extension types" instead of "extensions" for implicit extensions. I think we will want to distinguish these from extension methods and also discuss the two in combination. |
One thing I kind of liked about the |
With the name |
To me, it's the other way. |
I imagine C# could fake it by emitting an unspeakable function name to IL and mapping it to the declared name for source code. Though it would be better if the CLR would add extension/role types to the type system. |
Just happen to see this was changed into role so pardon me for duplicate I am not so sure about current use case of I think Suppose we have public class Person
{
public DateTimeOffset birthDay;
}
public extension PersonExt for Person
{
public TimeSpan Age => DateTimeOffset.Now - birthDay; // everyone has age
}
public role Adult for Person // not everyone is adult
{
public static bool operator is(Person person) => person.Age.TotalYears >= 18;
public bool HasJob => false;
public bool Occupation => "College Student";
}
////
Person person0 = LoadFromDB(pid0);
if(person0 is Adult adult0) // check with operator is
Console.WriteLine(adult0.Occupation);
var adult1 = (Adult)LoadFromDB(pid1) // null if operator is return false Alternative syntax might be public role Adult for Person when (Age.TotalYears >= 18)
{
public bool HasJob => false;
public bool Occupation => "College Student";
} |
Re-rename to Roles and Extensions
Summary
Rename
explicit extension
back torole
andimplicit extension
back to simplyextension
.Motivation
The proposed Extensions feature design eliminates the previously proposed distinction between "roles" and "extensions", in recognition that they are in fact two flavors of the same feature. Instead it introduces modifiers
explicit
andimplicit
onto the shared declaration keywordextension
.This makes sense from a language designer economy-of-concepts point of view. However, the intended mainline use of the two kinds of extension differs considerably: One is explicitly used as a type, whereas the other implicitly adds members to an existing type. The overlap in intended usage is small, boiling down to using an implicit extension explicitly as a type for disambiguation purposes.
We've now had some time to get experience with the design. In practice, anyone but a language designer or implementer rarely has to discuss the overall feature as a whole. Any given declaration is either an "explicit extension" or an "implicit extension", and the intended mode of use follows from that. The terms are not only long but deceptively similar, causing confusion as well as verbosity.
We should go back to clear, separate nouns for the two features. The previously used nouns "role" and "extension" are great candidates, though the choice of terms is less important than the choice of having two of them. This will help people understand them separately, in a manner specific to their main usage patterns. It allows developers to adopt them one at a time, and not worry much about the connections between them.
Going back to a narrower use of the term "extension" also keeps it better aligned with the meaning developers are already used to from extension methods. There have been demands for "extension members" and "extension everything" ever since extension methods were added, and this use of the term matches the intuition reflected in these asks.
This is not a proposal to turn roles and extensions into completely separate features. With the rename an extension will still also be a role. The two features benefit hugely from having a shared core. The syntax of declarations, the type of
this
inside them, the conversions to and from the underlying type, the code generation strategies, etc., etc., all entirely overlap. Additionally, envisioned future feature evolution such as inheritance and interface implementation apply to and have compelling scenarios for both features.It is conceivable that this step opens up opportunities where more differences between roles and extensions would be possible and beneficial. That is totally fine but is not implied here.
Detailed design
In the proposal grammar change the
extension_declaration
production as follows:Rename all productions named
extension_NNN
torole_NNN
. Throughout the proposal, update code snippets accordingly.In prose, change "implicit extension" to "extension" and unqualified "extension" to "role". There are only two occurrences of "explicit extension" in prose; they can easily be rewritten (to e.g. "non-extension role"), and "role" can safely be used as the overarching term. It turns out that it is rare for the specification to have to talk about explicit extensions only, since everything that applies to them applies to implicit extensions also.
In the Implementation Details section we will want to adjust the naming of emitted attributes and members, and there are probably a few other places that would benefit from a rewording after this change.
Examples
Drawbacks
It becomes less directly clear from syntax that extensions are just roles with more behavior.
Alternatives
Alternative nouns
While "extension" is very likely the right term for "implicit extensions" because of the connection to the existing extension methods, there is more room for debate about "role". While that term does occur in literature, it is not particularly established among developers. We can essentially pick whichever term we like, and many others have been proposed.
Allowing
extension role
If we want the language to more directly reflect that every extension is a role, we could make the declaration syntax for extensions allow an optional
role
keyword to occur in the declaration:This would be somewhat similar to
record class
which is allowed to be abbreviated torecord
. However, for records the use ofrecord class
might be motivated by wanting to highlight that it is not arecord struct
. Forextension role
on the other hand there is noextension something-else
to distinguish it from.We don't have great scenarios at the moment (outside disambiguation) where an extension is also intended to be used as a role (i.e. an explicit type), but such scenarios may come up. In those cases, it might be useful to stress this intent by explicitly putting the word
role
in the declaration, even if it doesn't have semantic impact.This is something that could be added anytime. We could ship the feature without it, and add the ability to say
extension role
as a long form ofextension
add any future point if it seems warranted. By analogy we also shippedrecord
first and then retcon'ed it to be an abbreviation ofrecord class
in a subsequent release whenrecord struct
was added.Implementing extensions before roles
Using separate nouns as proposed here, it may become an option to ship extensions first and roles later. While
this
-access and disambiguation for extensions use them as a named type, that is only going to be needed locally in a function body. By contrast, roles are likely to be used in signatures, and so require quite an elaborate metadata scheme for implementation.Perhaps there's a stage where we leave out role declarations, as well as disallow extension types from occurring in signatures. The latter restriction would be similar to the one that applies to anonymous types in today's C#.
Unresolved questions
Design meetings
https:/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-09-18.md#extensions-naming
The text was updated successfully, but these errors were encountered: