LDM Notes for February 22, 2023

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-02-22.md

Agenda

• Primary Constructors
• Extensions

[TahirAhmadov]

Can we make implicit be the default? So that it's either extension or explicit extension.

[TahirAhmadov]

I think that's a virtue. They are similar. The same as if you had record struct or record class.

The words struct and class are sufficiently different to be obvious. I keep thinking back to a couple of videos I saw about highway sign design in the US and UK back when the road networks were being built rapidly.

You only write this once, and you're good. It's like implicit operator and explicit operator. There's no need for a shorter form at the decl location. The consumption side is what matters, and there things are ergonomic.

Yes and no. Yes, declaration is not as important as the usage. But, operator overloading is a lot less common, and in fact can be called a "niche" feature. Whereas I expect extensions to be very popular. And yes, it's sometimes hard to quickly comprehend the operator declarations. (Not that we can do anything about it..)

[CyrusNajmabadi]

The words struct and class are sufficiently different to be obvious.

As are the words implicit and explicit. I mean, that already are with operators.

[CyrusNajmabadi]

Whereas I expect extensions to be very popular.

I expect then to be as popular as extension methods are today. So they'll exist and be declared occasionally, and used a lot.

And yes, it's sometimes hard to quickly comprehend the operator declarations.

As your said, it's niche for you. So it's harder for you to comprehend. However, if it's not niche, you will quickly see and understand it. It's a self fixing problem.

[333fred]

But still, a different keyword could be picked for role, instead of resorting to 2 keywords every time.

As both the notes from LDM and the working group mentioned, we considered this. But we think the singular keyword is better for the feature, as it unifies it.

[TahirAhmadov]

I understand the value of using the name "extension" to describe the entire feature. Still, it seems to be a bit too verbose to type implicit extension every time.
Now that I think about it, it would be cool to drop the implicit keyword from both the extensions and the operators.

However, I concede this is not super important. The actual meat of the feature is much more important and I'm glad progress is being made.

[alrz]

• Would it be possible to not specify a name for the extension extension<T> for IEnumerable<T>?
• There's a limitation for trait implementation in Rust: Either the trait or the type must be defined inside the same compilation. This matters if extensions could affect semantics of the code elsewhere. Would there be any such limitation for adding interfaces?
• Isn't TSelf type parameter relevant here? (If I understand this correctly, implicit extension is like impl X for Y in Rust).

[CyrusNajmabadi]

Would it be possible to not specify a name for the extension

Yes. We are considering this. Though, if no name is provided, i would be highly against allowing type parameters.

Isn't TSelf type parameter relevant here?

Not sure what this means.

[333fred]

There's a limitation for trait implementation in Rust: Either the trait or the type must be defined inside the same compilation. This matters if extensions could affect semantics of the code elsewhere. Would there be any such limitation for adding interfaces?

Possible. We still need to think about the orphan rule.

[qrli]

Looks like the primary constructor design can neatly simply dependency injection scenario:

public class MyService(FooService foo, BarService bar, ...)
{
    public async Task DoSomething()
    {
        await foo.Blabla();
        ...
    }
}

The only tiny missing thing is to mark the captured field readonly.

[iam3yal]

Unambiguous for both human and computer compilers. Interface1 is the extended type, and Interface2 is the type being added.

I'm not sure I understood the difference so does this mean that role is replaced with extension?

[iam3yal]

@CyrusNajmabadi Can you use for both for explicit and implicit extensions? from your comment I guess that atm it's only available for explicit extensions? or it's not related and these explicit/implicit modifier just specifies whether the extension is going to be imported into a namespace explicitly/implicitly, I'm not sure I understand.

[TahirAhmadov]

@eyalalonn I think @CyrusNajmabadi can answer definitively, but I'm pretty sure it would be the for syntax for both explicit and implicit extension.

[iam3yal]

@CyrusNajmabadi Okay @HaloFour just answered this on another issue. :)

[CyrusNajmabadi]

for is used for (no pun intended) both types of extensions. You're always saying what base-thing you are extending.

[CyrusNajmabadi]

Note: We are considering making for optional in teh case where you do this: extension E1 for int { } ... extension E2 : E1 { }. Here you wouldn't need to restate the base-thingy because it will be the same as the other extension you are deriving from.

but this is very in flux.

[HaloFour]

The changes to extensions here remind me a lot of Scala implicit classes, which were introduced in Scala 2.10 and intended to accomplish the same thing. The way they worked was that as long as you had the implicit class in scope you could then invoke members of that implicit class on the underlying type and the compiler would implicitly convert the underlying type into the implicit type:

// given
object Extensions {
    implicit class IntExtensions(x: Int) {
        def doubled() = x * 2
    }
}

// then
import Extensions._
val r = 5.doubled

// and the compiler would emit
val r = IntExtensions.apply(5).doubled()

That mental model translates to extensions proposed here:

// given
implicit extension IntExtensions for int {
    int Doubled { get => this * 2; }
}

// then
var r = 5.Doubled;

// and the compiler would emit something like
var r = ((IntExtensions) 5).Doubled;

The "cast" to the extension type occurs implicitly for an implicit extension because it is a widening conversion, but must be explicit for explicit extension because it is a narrowing conversion, and you would need to explicitly cast to the extension type:

// given
explicit extension IntExtensions for int {
    int Doubled { get => this * 2; }
}

// not legal
var r = 5.Doubled;

// legal
IntExtensions ext = (IntExtensions) 5;
var r = ext.Doubled;

I'm hoping that the conversation around explicit extensions will explore conditional conversions. I imagine static Try* methods would suffice, but I think there's a big opportunity to explore explicit extensions as active patterns:

// given
explicit extension NonZero<T> for T where T : INumberBase<T> {
    // spaghetti at the wall syntax
    public static bool operator is(T number) {
        return !T.IsZero(number);
    }

    public void Tada() { }
}

// then
var x = 1;
if (x is NonZero<int> nz) {
    nz.Tada();
}

[HaloFour]

Asking around it seems that the "implementation" vs. "intent" was the primary reason. Implicit classes were seen as too low level. I don't think that same problem applies here.

Although, for similar comparisons, Scala 3's answer to "explicit extension" are opaque types. I kind of like how they are two features that can be combined for the desired effect, vs. two flavors of extensions.

[CyrusNajmabadi]

I'm hoping that the conversation around explicit extensions will explore conditional conversions. I imagine static Try* methods would suffice, but I think there's a big opportunity to explore explicit extensions as active patterns:

I'm hoping this as well. There's definite interest here in this.

[CyrusNajmabadi]

The "cast" to the extension type occurs implicitly for an implicit extension because it is a widening conversion, but must be explicit for explicit extension because it is a narrowing conversion,

This is exactly the mental-model/intuition and set of rules I'd actually like us to provide here (as much as is feasibly possible at least). I think it's clean, intuitive, and makes a bunch of questions/behaviors clear in how they should operate.

It also has extremely nice symmetry with existing implicit/explicit conversion operators.

[HaloFour]

@CyrusNajmabadi

It also has extremely nice symmetry with existing implicit/explicit conversion operators.

I can understand that, although I think I like the model Scala has taken here by splitting into two orthogonal but complementary features. I can see wanting to have an aliased subtype of a type without needing to provide extension members, and that could be accomplished via "explicit extensions", but that seems like a degenerate way to achieve it:

// given
public explicit extension ClientId for string {
    // spaghetti at the wall syntax
    public static bool operator is(string value) {
        return !string.IsNullOrWhitespace(value);
    }

    // no need/desire for other members here
}

public void DoSomething(ClientId cid) { }

// then
string s = ...;
DoSomething(s); // compiler error

if (s is ClientId cid) {
    DoSomething(cid); // fine
}

However, if the aliased subtype was a separate feature (which would separately provide the conversion validation) and then you could define extensions on the subtype then you have clean separation of concerns.

// given
public subtype NonZero<T> for T where T : INumberBase<T> {
    // spaghetti at the wall syntax
    public static bool operator is(T number) {
        return !T.IsZero(number);
    }
}

public extension NonZeroExtensions<T> for NonZero<T> where T : INumberBase<T> {
    // we later decide we do want extensions, or want to extend a subtype defined in another assembly
    public void Tada();
}

// then
var x = 1;
if (x is NonZero<int> nz) {
    nz.Tada();
}

[CyrusNajmabadi]

Yup yup. I see what you're saying. I think we'll def be looking into this more closely. Especially as we are interested in the is/active-pattern space for runtime validation if a value can map into these domains.

[iam3yal]

Previously you wrote that Roles where one of the motivating scenarios for Type Classes is it still on the table? does it still applies/fits to Extensions? or you're thinking to do something completely different?

[TahirAhmadov]

This is just a naming overhaul; instead of roles and extensions, we now have explicit extensions and implicit extensions, respectively.

[iam3yal]

@TahirAhmadov Yes but this doesn't answer my question, did you try to reply to my previous question/comment?

[TahirAhmadov]

I think your question pertains to the overall feature, whereas we've been discussing just these LDM notes in this discussion. As part of these notes, there don't seem to be any changes WRT implementing "type classes" with "roles" (now known as "explicit extensions").
Obviously feel free to ask others what they think about it, probably better to do it in #5497, as it's outside the scope of these LDM notes.

[iam3yal]

@TahirAhmadov Thank you.

[MgSam]

Do you guys have some examples of extensions anywhere? Hard to keep up with the proposal when its all theoretical.