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

[Proposal]: Re-rename to Roles and Extensions #8431

Open
MadsTorgersen opened this issue Sep 13, 2024 · 8 comments
Open

[Proposal]: Re-rename to Roles and Extensions #8431

MadsTorgersen opened this issue Sep 13, 2024 · 8 comments
Assignees

Comments

@MadsTorgersen
Copy link
Contributor

MadsTorgersen commented Sep 13, 2024

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
Copy link

colejohnson66 commented Sep 13, 2024

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
Copy link

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
Copy link
Collaborator

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
Copy link
Contributor

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
Copy link

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
Copy link

FaustVX commented Sep 16, 2024

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
Copy link

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
Copy link

Thaina commented Oct 3, 2024

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";
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants