LDM Notes for October 14th, 2024

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-10-14.md

Agenda

• Extensions

[qrli]

You may disagree, but my feeling is that the LDM focused too much on the problems than the goal, and were revising the goal according to the problems.
The members approach can work but it would be minor or little improvement over the old. If every feature starts at -100 points, why push hard on that at all?
With the type approach, there are a lot more potential future improvements which can easily fit in.

[CyrusNajmabadi]

but my feeling is that the LDM focused too much on the problems than the goal,

I mean... we have to. Goals don't mean much if problems prevent you from achieving them.

[qrli]

I mean... we have to. Goals don't mean much if problems prevent you from achieving them.

I understand your stand. But imagine that C# took the members approach, and then other languages like Java, etc. followed the wave yet they chose to take the poison to do it in a more clean-cut way. Then more innovations came to this area, and you had more legacy to deal with. Would you regret?

[HaloFour]

C# already took the members approach, 17 years ago. That's why this discussion is happening, as this is an evolution of that existing feature, which is used extremely widely by the ecosystem and the BCL. Cutting off that enormous amount of existing code to be relegated to the "legacy syntax" is undesirable, as would be unintentional breaks caused by people attempting to migrate from one to the other not realizing that they are wholly incompatible. This discussion needs to happen, even if at the end of it the team decides that it's not possible/practical to bridge the two forms.

Java has no concept of extensions today, so they wouldn't have to take existing functionality into consideration. Every language of a non-trivial age and with a non-trivial user base has to deal with legacy.

[CyrusNajmabadi]

to do it in a more clean-cut way

I don't agree that it's more clean cut. The more I look at this space, and the more we look at how people actually write and use extensions, the less appropriate the type -based approach seems.

Then more innovations came to this area, and you had more legacy to deal with. Would you regret?

I see it the opposite way. I think the type -oriented approach will limit innovations. So yes, I would have regrets if we go that route.

[HaloFour]

Gonna throw a little more spaghetti at the wall, based loosely on Scala 3's approach to extensions, which use a primary constructor-like syntax to declare a separate parameter list for the extension target. That lets you specify the type and parameter name of the extension target with a little more flexibility.

Also, allows extension itself to be generic, which would allow an extension type to have two separate generic parameter type lists. The extension generic parameter types are prepended to the member generic type parameters, if any. That doesn't solve the case when the extension generic type is not the first generic type parameter.

Also continues to allow partial extensions, which are merged together into a static class. It could be confusing to have each part allowing it's own "primary constructor"-like syntax for the parameter target.

public partial extension Enumerable(this IEnumerable source) {
    public IEnumerable<T> OfType<T>() { ... }
}
public partial extension<T> Enumerable(this IEnumerable<T> source) {
    public IEnumerable<T> Where(Func<T, bool> predicate) { ... }
}
public partial static class Enumerable {
    public static IEnumerable<T> Empty<T>() { ... }
}

[FaustVX]

I am exploring alternative syntax to make that more clear.

Yes I know that, I like that a lot of syntax/concept is explored :)

You could argue that the compiler should flatten the generic type parameter list of the type into the method, to achieve this compatibility.

I would prefer to have a coherent syntax with slightly different behavior, we already have that in C# (record primary constructor has parameter syntax but with property behavior)

[HaloFour]

Scala has nearly identical primary constructor syntax and behavior as C# (including the differences between classes and records, aka case classes), which is why I found it interesting that it used that same syntax to represent the extension target for extension types. I think it's fine to reuse the syntax in this case, and vastly I prefer it to the other options suggested for supporting in/ref types or explicitly naming the parameter.

[HaloFour]

Learned two things about the behavior of the Scala 3 syntax. First, they aren't emitted into a generated container class. They are emitted at whatever level they are declared. So, if they're not declared within an object (equivalent of static class), then they are top-level methods.

object Enumerable:
  extension[T] (source: IEnumerable[T])
    def map[TR](mapper: T => TR): IEnumerable[TR] = { ... }
    def filter(predicate: T => Boolean): IEnumerable[T] = { ... }

Second, you can both group them and declare them individually and they mean the same thing, e.g.:

extension (x: Int)
    def intToString() => Integer.toString(x)
    def doubleIt() => x * 2

// same as
extension (x: Int) def intToString() => Integer.toString(x)
extension (x: Int) def doubleIt() => x * 2

Interesting food for thought.

[RikkiGibson]

So, if they're not declared within an object (equivalent of static class), then they are top-level methods.

How is a top-level method represented in metadata in Scala?

[HaloFour]

@RikkiGibson

Gets silently emitted into a class based on the source file name, e.g.:

// main.scala

def foo(): String = "Hello World"

compiled to:

public class main$package$ {
    public static final main$package$ MODULE$ = new main$package$();

    private main$package$() { }

    public String foo() {
        return "Hello World";
    }
}