LDM Notes for September 18th, 2024

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-09-18.md

Agenda

• Nullability in field
• Extensions naming

[huoyaoyuan]

My cent from non-native speaker. role feels a bit strange and view is really overloaded. Attributive on type feels better to me.

[saint4eva]

Is type not overloaded as well?

[huoyaoyuan]

I mean compositive word like view type.

[saint4eva]

view type is similar to explicit extension. Developer should and will get used to Role as a relevant word in C#. Many developers have gotten used to Record.

[spydacarnage]

A strong "no" for view from me - too much overloading, especially in MVC/Razor.

I quite like role, or maybe mode, as that implies a mild transformative property.

[saint4eva]

Yes, I think role should be preferred and developers will get used to it anyways.

[orthoxerox]

If C# took itself less seriously, I would propose hat.

[HaloFour]

I tried to describe the feature to ChatGPT and ask it for suggestions and it spit out a boatload of nouns and none of them really stood out as "better" to me.

Naming aside, I thought the main reason for the implicit/explicit naming was to capture the widening/narrowing behavior of the extension type. Is that behavior changing? Is it expected that you can declare a variable of an extension type. If so, what does that mean compared to a variable of a role type?

If the behavior of the two constructs is to differ, maybe we can revisit the elision behavior of these role types? Can they be proper types, a single-field struct, so that overloading and proper type checking can apply? What about the validation/conversion stories for role? For example, for the JsonElement roles declared in the rename proposal I'd like to know that I could validate on conversion that the JSON node was of the correct type and contained the correct fields. Same with pattern matching.

[HaloFour]

Extensions are still built on top of roles. So, an extension is a kind of role, but a role is not a kind of extension.

I'm not sure that makes sense? There's definitely a huge amount of overlap, but I would expect "roles" to support validation or narrowing conversions in some manner, which doesn't make sense for extensions.

I guess you can say that an "extension" is a "role" that requires no validation. But can an extension "inherit" from a role that does require validation? What does that mean?

[TahirAhmadov]

Not even an honerable mention for trait? I think role seems to be more inline with record though in terms of look and feel.

"Trait" means something different in English:

A distinguishing feature, as of a person's character. synonym: quality. Similar: quality
A genetically determined characteristic or condition. "a recessive trait."

I don't think it's a good match meaning-wise.

[jnm2]

Rust has a thing called traits. trait didn't make it, the objection being that the term is overloaded.

[jnm2]

A Rust trait is like a C# interface.
Then, Rust's impl SomeTrait for SomeType would be like declaring a C# role that implements an interface.
Rust trait impls are anonymous and there can't be more than one impl per trait per underlying type. C# roles are named and if/when they support interface implementation, there will be able to be more than one role that implements the same interface for the same underlying type.

[colejohnson66]

Rust trait impls are more like implicit extensions; They extend the existing type, not create new ones. Rust’s Deref[Mut] trait when used on proxy types is similar to explicit extensions.

[En3Tho]

Recently I've been working with Vulkan via Silk.Net and I was in a need for light-weight typing to introduce some compiler guarantees while trying not to hinder myself too much. I ended up with struct wrappers but roles could be a really good fit for this kind of thing.

I wonder if ldt already has questions for these questions:

1. self type and roles: do methods that return TType when used with TType turn to returning TRole when used with TRole? Basically, does self type propagate? E.g.

MyType
    MyType ReturnMyself() => this;
MyRole : MyType ...

MyType t;
MyRole r = t;
var self = r.ReturnMyself() // is it MyType or MyRole here?

2. Implicit casting to undertlying type and pointers and refs. Can ref TRole or &TRole be converted automatically to ref TType and &TType respectfully? I thinking of a case where I do not want roles to be interchangeable but at the same time I want this for roles and their underlying types. E.g.

MyRole : MyType
    ... some implicit casting members to MyType here, if needed

MyType t = ...
MyRole r= (MyRole) t;
MyType t2 = r; // implicitly casted
MyType* mt = &r; // implicitly casted
ref MyType rt = ref r; // implicitly casted

[TahirAhmadov]

view implies it's a "read only" interface into the object, similarly to database views (yes data modifications are allowed on views under a very narrow set of rules, but that feature is barely used and not widely associated with views in the industry). Whereas "explicit extensions" don't have any implied limitations WRT being "read only". The other proposals are meh, too. I would return to role and call it a day.

I also agree with those who say that (implicit) extension is the more important (to me, much more important) feature. If "roles" get postponed to a future release, then a) naming can be decided later, b) the runtime work to make roles work as desired can be done without a rush.

[MgSam]

The notes mention that explicit extensions cannot adapt types to one another- I thought that was one of the key goals for an upcoming version of the feature was to allow interface implementation? So that types that do not actually implement an interface could be given a facade to make it appear that they do via the explicit extension. To me this was by far the most valuable of this whole feature set.

Otherwise the whole concept of explicit extensions seems fairly toothless to me. The canonical example of a wrapper around JSON is fundamentally broken in my opinion- it only works if your data is 100% strings. If it’s any other data type you would need to do conversion every time the property is accessed which is way worse perf wise than just building a real type and doing proper deserialization.

[333fred]

I thought that was one of the key goals for an upcoming version of the feature was to allow interface implementation

Yes, and they will be able to do that (eventually). What they can't do is adapt all types to one another; you can't use them to get multiple inheritance.