[Discussion]: Extensions

[333fred]

Discussed in #5496

^{Originally posted by MadsTorgersen November 30, 2021}
https://github.com/dotnet/csharplang/blob/main/proposals/extensions.md

[hez2010]

I prefer using of or something else to distinguish the type being extended and interfaces:

public extension Foo of int : IA, IB, IC, ...
{
    ...
}

Otherwise it will be too confusing if you are extending an interface:

public extension Foo : IA, IB, IC { }

vs

public extension Foo of IA : IB, IC { }

of can be relatively safely made as a keyword since it's neither a verb nor a noun, so almost nobody would choose of as an identifier.

[HaloFour]

I'm curious as to how the team weighs the relative benefits between "roles" and "extension implementation". It feels that without some additional effort in the runtime the two are somewhat incompatible with each other, so if those differences can't be reconciled which of the features might the team lean towards?

Personally, I find extension implementation much more exciting than roles, but that's just my opinion.

[FaustVX]

@hez2010
Maybe, instead of of, for would be a better name for the keyword as it's already a keyword.

public extension Foo for IA : IB, IC { }

[333fred]

I'm curious as to how the team weighs the relative benefits between "roles" and "extension implementation". It feels that without some additional effort in the runtime the two are somewhat incompatible with each other, so if those differences can't be reconciled which of the features might the team lean towards?

Who gave you an early preview of my notes? They're up now, discussion at #5500.

[sab39]

Here's a scenario that will be great fun to try to accommodate in the design:

interface IFoo { }
interface IBar { }
class Thing { }
public extension FooThing for Thing : IFoo { }
public extension BarThing for Thing : IBar { }
void Frob<T>(T t) where T : IFoo, IBar { }

Frob(new Thing());

On an unrelated bikeshedding note, what about using the existing reserved keywords explicit and implicit as modifiers, rather than treating roles and extensions as completely separate things? An extension is, more or less, just a role that gets applied implicitly based on type rather than needing to be explicitly named in the declaration. Using implicit role as the syntax would spell that correspondence out more (no pun intended) explicitly?

[CyrusNajmabadi]

@sab39 Given, as you've mentioned, how similar these two concepts are. I too am looking for a good syntactic way to convey that similarity, with a clear way to do indicate in which way they differ. Thanks for the explicit/implicit idea, definitely something we'll consider!

[TahirAhmadov]

I'm not sure if I should re-post my comments from the discussion here?
In short, I think the extensions and especially interface "adapters" make sense, but roles don't. The main motivation example - DataObject - is an anti-pattern, IMO; it runs into expensive runtime changes; and causes confusion - now you have to keep in mind when looking at an identifier in a "type receiving context" if it's a type or a role.

Here's a scenario that will be great fun to try to accommodate in the design:

interface IFoo { }
interface IBar { }
class Thing { }
public extension FooThing for Thing : IFoo { }
public extension BarThing for Thing : IBar { }
void Frob<T>(T t) where T : IFoo, IBar { }

Frob(new Thing());

This is complicated, but doable using current constraints of the framework. An anonymous type can be generated:

class <mangled>Thing_IFoo_IBar : IFoo, IBar
{
  internal <mangled>Thing_IFoo_IBar(Thing thing) { this._thing = thing; }
  readonly Thing _thing;

  void IFoo.Foo() { ... } // these member(s) are copied from, or call into, FooThing
  void IBar.Bar() { ... } // these member(s) are copied from, or call into, BarThing
}
Frob(new <mangled>Thing_IFoo_IBar(new Thing()));

The same can be done for generic types, etc. Yes, it's complicated, but unlike roles, it's very possible.

[CyrusNajmabadi]

The main motivation example

This was just one example. It's not the main motivation. We discussed in the LDM that there were definitely plenty of scenarios where you'd still want adapters in a strongly typed way that would be sensible.

[sab39]

@TahirAhmadov That works, more or less, for the specific example I gave, but what if Frob<T> had other constraints like where T : class or where T : struct or where T : new() or where T : SomeBaseClass? What about if it were Frob<T, T2> where T2 : T? In general it's not actually possible to generate an anonymous type that can meet all possible constraints that T would meet and also implement IFoo and IBar. This suggests to me that it's not possible to fully support this scenario without runtime assistance.

[TahirAhmadov]

The main motivation example

This was just one example. It's not the main motivation. We discussed in the LDM that there were definitely plenty of scenarios where you'd still want adapters in a strongly typed way that would be sensible.

If it's not the main motivation, surely it shouldn't be the one discussed in the OP, should it?

[CyrusNajmabadi]

The OP is simply showing a demonstration. This is a broad topic and we need to spend a ton more time on it prior to even getting close to a place where we could write something up that was fully fleshed out and chock full of examples and whatnot.

[TahirAhmadov]

@TahirAhmadov That works, more or less, for the specific example I gave, but what if Frob<T> had other constraints like where T : class or where T : struct or where T : new() or where T : SomeBaseClass? What about if it were Frob<T, T2> where T2 : T? In general it's not actually possible to generate an anonymous type that can meet all possible constraints that T would meet and also implement IFoo and IBar. This suggests to me that it's not possible to fully support this scenario without runtime assistance.

The where T : class constraint simply rejects Thing extensions if Thing doesn't satisfy the constraints. The where T : new() rejects all extensions outright. where T : SomeBaseClass also rejects extensions of Thing because it's a different type. Frob<T, T2> where T2 : T is completely irrelevant.

[BhaaLseN]

Back with .NET Framework, I've often ran into situations where i wanted a Math.Clamp<T>(T value, T min, T max), Math.Max(TimeSpan val1, TimeSpan val2) or Path.GetRelativePath(...) for discoverability; but there was no way for me to get this done. Same with string.Contains(string, StringComparison) etc. except as instance extension (which is somewhat taken care of by extension methods though.)
Nowadays most are in there since either .NET Core or .NET 5/6, but it would feel more natural to simply extend the existing classes (with a very high-up namespace inside the project, so its most likely in scope all the time; or with a global using for example) when another one of those situations comes up. At least compare to MathEx, MathUtilities, PathHelpers etc. which often aren't as obvious.

The only thing I don't quite get is why we need two keywords here, role and extension. They mean different things if you talk about them, sure, but does this actually matter once you write the code? I'd assume they'll be lowered to virtually the same thing during compilation after all, and I can practically hear the "what's the difference" question coming when I present this to my team during a knowledge transfer meeting.

[TahirAhmadov]

The OP is simply showing a demonstration. This is a broad topic and we need to spend a ton more time on it prior to even getting close to a place where we could write something up that was fully fleshed out and chock full of examples and whatnot.

That's the thing, it would be very interesting to see an example which would demonstrate how roles make something worthwhile possible or significantly easier, before effort is spent on prototypes, implementation planning, etc.

[CyrusNajmabadi]

That's fine. It's something we're working on at this moment '-). The point was raised and was something we intend to get to and write more on. I def don't want us to get the impression that it's just for that. Thanks!

[aradalvand]

@HaloFour The reasons provided for the current abomination would be rectified by this new proposal.
Would welcome any feedback.

[HaloFour]

@aradalvand

Add some generics.

[aradalvand]

Add some generics.

@HaloFour

public extension<TSource> Enumerable(IEnumerable<TSource> source)
{
    public bool All(Func<TSource, bool> predicate);
}

[HaloFour]

@aradalvand

That's a possibility. I have suggested that whatever syntax could be applied in different scopes, from a single member, to groups of members, to all of the members declared within a type, etc. A separate clause also has the advantage of being declared within another member, and I, personally, think that extension implementation could be compelling for allowing hyper-localized extensions that could capture state.

Only supporting it at the type level comes with the issue of having to declare potentially many types to capture the design space we already have. Is that better? That's extremely subjective. I don't find a level of indentation to be onerous, the IDE is doing that for me anyway.

[CyrusNajmabadi]

Add some generics.

@HaloFour

public extension<TSource> Enumerable(IEnumerable<TSource> source)
{
    public bool All(Func<TSource, bool> predicate);
}

This appears to just be bike shedding on collapsing syntactic forms. Something virtually every design member I've heard from seems fine with.

As I've mentioned many times now. We are not doing the bikeshedding portion currently. We are deciding on core capabilities and semantics. Syntactic pleasantries come last. We have to start though with a STRAWMAN syntax that clearly delineates all the capabilities we want and answers all the questions on every complex case without confusion (like how do different generics merge)

[CyrusNajmabadi]

I have suggested that whatever syntax could be applied in different scopes, from a single member, to groups of members, to all of the members declared within a type, etc

And as I've mentioned, my feeling is that virtually all of the ldm is on board with that. But it's not an area of focus now because it doesn't change anything fundamentally. That's just syntactic sugar for later. We need to be dealing with the vet hard problems around semantics, compat, etc. first.

Also, personally, I very much want this. For example, I definitely have extensions and non-extensions side by side today. Being forced to group these separately is a downside for me. So while I am totally fine with higher level grouping constructs, I still want to be able to apply things at an individual (or small group) level.

[yaakov-h]

I'm confused by something in the recent Unified Extensions proposal: (#8665)

Given this sample:

public static class NullableExtensions
{
    extension([NotNullWhen(false)] string? text)
    {
        public bool IsNullOrEmpty => text is null or [];
    }
}

It seems odd to me to have nullability attributes on the reciever rather than on the method. I would have expected something more like:

public static class NullableExtensions
{
    extension(string? text)
    {
        [this: NotNullWhen(false)] 
        public bool IsNullOrEmpty => text is null or [];
    }
}

Otherwise, are there additional restrictions on the methods inside the extension scope?

What would the following mean, or would it become a warning/error?

public static class NullableExtensions
{
    extension([NotNullWhen(false)] string? text)
    {
        public object Foo => throw null!; // doesn't return a bool
        public void Foo => throw null!; // doesn't return anything
    }
}

[CyrusNajmabadi]

It seems odd to me to have nullability attributes on the reciever rather than on the method

This exactly matches existing extension methods. The return value tells you the state of the receiver value on exit.

[yaakov-h]

Yes, but on current extension methods you would put it on a method that returns bool, not on a scope containing methods which may or may not return bool.

Though with that said, there is nothing stopping you from writing the following at the moment:

using System.Diagnostics.CodeAnalysis;

public static class C
{
    public static void M([NotNullWhen(false)] this object? x) {
        throw null!;
    }
}

But it does also seem odd to me to force users of the new extension syntax to group methods by their nullability state, rather than any other logical grouping.

[En3Tho]

Or something like this

public static class NullableExtensions
{
    extension([NotNullWhen(false)] string? text)
    {
        public bool IsNull => return this == null;
        public bool IsNotNull => return this != null;
    }
}

Now what NotNullWhen(false) actually means for these 2 methods?

I think something like this is much better (if there actually was this target):

public static class NullableExtensions
{
    extension(string? text)
    {
        [this: NotNullWhen(false)]
        public bool IsNull => return this == null;

        [this: NotNullWhen(true)]
        public bool IsNotNull => return this != null;
    }
}

[hez2010]

Thinking about the top-level syntax, we can use:

public extension<T>(IEnumerable<T> source) as Enumerable
{
    // ....
}

advantages:

1. specify the type name explicitly
2. don't need to declare the type parameter on the type
3. get rid of the weird static class, also means we get more flexible emitting strategies where we don't have to emit the extensions into a static class
4. we can use partial to allow multiple declarations in different locations
5. extensions now can be defined in top-level

examples:

public partial extension<T>(IEnumerable<T> source) as Enumerable where T : IFoo
{
    // ...
}
public partial extension<T>(IEnumerable<T> source) as Enumerable where T : IBar
{
    // ...
}
public partial extension(IEnumerable<int> source) as Enumerable
{
    // ...
}
public partial extension(IEnumerable<long> source) as Enumerable
{
    // ...
}
public partial extension(string? source) as Enumerable
{
    // ...
}

instead of

public static class Enumerable
{
    extension<T>(IEnumerable<T> source) where T : IFoo { ... }
    extension<T>(IEnumerable<T> source) where T : IBar { ... }
    extension(IEnumerable<int> source) { ... }
    extension(IEnumerable<long> source) { ... }
    extension(string? source) { ... }
}

[MaguiSantosSilva-CAL]

Would this prevent me from extending a type that already has an extension elsewhere, but without a partial declaration?

Would the absence of partial effectively seal the class from being extended?

[weltkante]

considering partial is source-level and not part of the assembly (the partial definitions are already merged together in the assembly) you could always add a missing partial keyword ...

[MaguiSantosSilva-CAL]

So you're saying that the absence of a partial in an existing extension in a library would not prevent that class from being extended because it's not assembly level. Ok, thanks for clarifying that for me.

[ViIvanov]

Hi, I recently found the following code example here:

public static class MyExtensions
{
    extension<T>(IEnumerable<T> source)
    {
        public bool IsEmpty => !source.Any();
        public IEnumerable<T> Where(Func<T, bool> predicate) 
            => new (source.Where(predicate));
        public T this[int index] => source.ElementAt(index);

        public static IEnumerable<T> Empty => [];
        public static implicit operator ReadOnlySpan<T>(IEnumerable<T> sequence)
            => sequence.ToArray().AsSpan();
    }
    extension(IEnumerable<int> source)
    {
        public IEnumerable(int element, int count) 
            => Enumerable.Repeat(element, count);

        public static IEnumerable<int> Range(int start, int count) 
            => Enumerable.Range(start, count);
        public static IEnumerable<int> operator +(IEnumerable<int> sequence, int value)
            => sequence.Select(i => i + value);
    }
}

Interesting, what does mean => new (source.Where(predicate)); above in the Where method body? Which "constructor" is called and why?

[jnm2]

I don't think the bodies here are intended to be meaningful or intended to introduce new syntax. That is confusing!

[iam3yal]

@IS4Code, @jnm2 I thought it creates an instance of ReadOnlySpan<T> but then it wouldn't compile so yeah might help if things like this would have some clarification or a notice that says it's for demonstration purposes.

[LokiMidgard]

To be honest, if I had a list and would use the + opperator my assumption would be concat…

[jnm2]

Mads agreed, so I'm putting up #9086. For +, I agree but it's at least not distracting from the point of the examples.

[ViIvanov]

Thanks @jnm2, now the example is clear to me 👍I was just afraid that I was missing something from the concept.

[RikkiGibson]

It looks like the extensions grammar as currently defined does not permit static fields or const fields. Is this intended? Is it possibly something that could come along in the future?

The reason I ask is that the extensions feature may satisfy the use cases for people who want partial enums. But without being able to use const fields, the "extension enum members" won't be usable in attributes and so on. Probably static properties would have to be used instead.

[jcouv]

Yes, we'd likely want to add support for other member kinds. See this section

[scarletquasar]

someone help me i am pretty sure I disabled this thread notifications at least 4 times along these years

[wherewhere]

Here

[zms9110750]

Can a new keyword be extracted from the static class?
Kvp<K, V>is a struct, while a type with the same name Kvp is a class.
Entering with confusion, I found that he had only provided a static method.
And now extension requirements do not include generics, top-level classes, and static classes.
Why don't we create a new keyword for this requirement to indicate that it has nothing to do with the class?