[Proposal]: Re-rename to Roles and Extensions

[MadsTorgersen]

Re-rename to Roles and Extensions

This has been moved to https://github.com/dotnet/csharplang/blob/main/meetings/working-groups/extensions/rename-to-roles-and-extensions.md.

[colejohnson66]

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.

[Sergio0694]

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".

[KathleenDollard]

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.

[HaloFour]

One thing I kind of liked about the implicit vs explicit extension types is that it conveyed that one was widening while the other was narrowing, in that explicit extensions might not always apply to the underlying type and that some type of possibly fallible validation/conversion was required. I think that's an important feature for the type and I don't think role conveys that concept at all.

[KennethHoff]

With the name explicit extensions the fact that this scenario did not work made some amount of sense; "it's just an extension to the underlying type, of course it doesn't act any differently", but if we go for a name like "role" it implies that it should be more than just "extension to some underlying type", so I hope this use-case gets re-considered.

[FaustVX]

One thing I kind of liked about the implicit vs explicit extension types is that it conveyed that one was widening while the other was narrowing, in that explicit extensions might not always apply to the underlying type and that some type of possibly fallible validation/conversion was required. I think that's an important feature for the type and I don't think role conveys that concept at all.

To me, it's the other way. extension doesn't mean there will be some validation to be required. role sound better; ie: not every people can have a role of any job, you have to qualify to apply.

[timcassell]

With the name explicit extensions the fact that this scenario did not work made some amount of sense; "it's just an extension to the underlying type, of course it doesn't act any differently", but if we go for a name like "role" it implies that it should be more than just "extension to some underlying type", so I hope this use-case gets re-considered.

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.

[Thaina]

Just happen to see this was changed into role so pardon me for duplicate

I am not so sure about current use case of role but I have an idea I wish it could support

I think role should have conditional checking for casting as is. If it fail the condition it should be null

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 when and expression block

public role Adult for Person when (Age.TotalYears >= 18)
{
    public bool HasJob => false;
    public bool Occupation => "College Student";
}