[Proposal]: Extensions #5497

333fred · 2021-12-02T17:24:08Z

Discussed in #5496

^{Originally posted by MadsTorgersen November 30, 2021}

Extensions

Proposed
Prototype: Not Started
Implementation: Not Started
Specification: https://github.com/dotnet/csharplang/blob/main/proposals/extensions.md

LDM Meetings

hez2010 · 2021-12-02T18:09:50Z

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 · 2021-12-02T18:43:41Z

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 · 2021-12-02T18:46:14Z

@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 · 2021-12-02T19:20:26Z

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 · 2021-12-03T16:28:53Z

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 · 2021-12-03T16:35:23Z

@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 · 2021-12-03T17:11:02Z

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 · 2021-12-03T17:14:13Z

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 · 2021-12-03T17:34:49Z

@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 · 2021-12-03T17:42:08Z

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 · 2021-12-03T17:48:21Z

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 · 2021-12-03T17:50:08Z

@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 · 2021-12-03T17:58:28Z

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 · 2021-12-03T18:54:57Z

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 · 2021-12-03T19:18:05Z

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!

orthoxerox · 2021-12-03T19:27:40Z

Roles feel like they need a validator method, something that is invoked to by the "implicit conversion" to ensure that the underlying object can fill in that role. I'm not even sure the conversion should be implicit. I'm sure it will be annoying to do stuff like public Customer Customer => (Customer)this["Customer"]; over and over again, but I also want to be able to say if (payload is Order order) { ....

sab39 · 2021-12-03T19:29:29Z

Hmm, that almost makes it sound like you want Extension DUs...

orthoxerox · 2021-12-03T19:54:08Z

I don't want them to be a DU per se, it's more similar to getting an object from some API and casting it to the expected type. Right now the roles work more like dynamic instead.

vladd · 2021-12-03T21:29:13Z

@orthoxerox F# has a feature Partial Active Patterns which looks somewhat like your idea.

hez2010 · 2021-12-04T02:43:49Z

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.

C# isn't the only language on CoreCLR, without runtime support how would you expect roles to be defined and used in other languages? Other languages don't recognize the mangled anonymous class.

TahirAhmadov · 2021-12-04T03:54:02Z

C# isn't the only language on CoreCLR, without runtime support how would you expect roles to be defined and used in other languages? Other languages don't recognize the mangled anonymous class.

The pseudocode I wrote was specifically for extensions, not roles.
In any case, though, the mangled anonymous type is generated at the call site, not at the extension declaration site. Specifically because there can be multiple permutations of extensions (or roles - ignoring the fact that I don't like the idea of roles/shapes), these machinations have to be performed when all the information is available: what interfaces are "adapted", etc.
Also, regardless of the language, the extension will have to be added somehow to the metadata; the easiest way would be using a class with some special attributes. The other languages can decide whether to implement this feature - in which case they can interpret these attributes like C# does; otherwise, it becomes a class, probably a static one, which they can use in an "old school way". The same is true for existing extension methods.
Further, even when it's a simple scenario, for interface "adaptation" to work, the easiest way is again, an anonymous type:

class Thing { }
interface IFoo { void Foo(); }
extension FooThing: Thing, IFoo { void Foo() { ... } }
void Frob(IFoo foo) { }
// this line:
Frob(new Thing());
// is compiled to this:
class <mangled>Thing_IFoo : IFoo
{
  internal <mangled>Thing_IFoo(Thing thing) { this._thing = thing; }
  readonly Thing _thing;

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

Thaina · 2021-12-04T06:07:54Z

I also want to voice that I wish there would be some keyword being reused instead of casting new keyword role and extension. Or at least create only one and use implicit/explicit as above

Or implicit class possible?

Aside from that I have nothing against, and fully support this issue

hez2010 · 2021-12-04T06:13:27Z

instead of casting new keyword role and extension. Or at least create only one and use implicit/explicit as above

Or implicit class possible?

Keywords can be introduced as contextual keywords so it can be made not to introduce breaking changes.

Thaina · 2021-12-04T06:35:19Z

@hez2010 I know there is no breaking change but it still should be the last option to introduce any new keyword. If there would be any possible for composite or reuse then we should

333fred · 2021-12-04T07:14:06Z

I found the idea of implicit and explicit very interesting and forwarded your comment to our working group @sab39, thanks for the suggestion!

iam3yal · 2021-12-04T16:08:22Z

I don't get why roles need an implicit and explicit modifiers, can't they be applied based on the context? what does it mean to have these modifiers? why treat them more or less the same and not exactly the same where the only difference is context? I get the you're trying out different ideas but merge these concepts needs to be core principle the way I think about is similar to aggregation vs composition where aggregation is an extension of existing type and composition is a wrapper the only difference is what they user want them to be based on context and not how they were constructed I don't think we want to end up with a situation where "I can do this when it's explicit but not when it's implicit or vice-versa" but maybe I'm misunderstanding why we need to have different rules for these two concepts, it's not clear whether they are similar or identical features yet but based on the OP I think they are either identical or similar to the point where it can be confusing to grasp why we are speaking about two different concepts.

I'll just copy/paste my comment from the other post so something like this:

// Customer.cs
namespace Data;

public extension Customer : DataObject // Wrapper type
{
    public string Name => this["Name"].AsString();
    public string Address => this["Address"].AsString();
    public IEnumerable<Order> Orders => this["Orders"].AsEnumerable();
}

// JsonDataObject.cs
namespace Data;

using JsonLibrary;

public extension JsonDataObject : DataObject // Extension type
{
    public string ToJson() { … this … }
    public static T FromJson<T>(string json) { … }
}

// Program.cs / Main method
using Data;
using Data.JsonDataObject; // Importing a specific extension type
using Data.*; // Importing all extensions types in the namespace Data

var customer = customer.FromJson<Customer>(args[0]);
WriteLine(customer.ToJson());

Reinms · 2021-12-04T16:11:18Z

Would this be allowed under roles?

role Foo<T> : T
    where T : ISomeInterface
{
}

or would we be forced to directly extend the interface and bring in boxing conversions all over the place as we implicitly cast back and forth in a generic function?

TahirAhmadov · 2021-12-04T17:23:57Z

Thinking about it, I imagine this happening:

class Thing { }
interface IFoo { void Foo(); }
// the following line
public extension FooThing: Thing, IFoo { void Foo() { ... } }
// is compiled to:
// these attributes are once per assembly, similar to NRT attributes
class ExtensionTypeAttribute { public ExtensionTypeAttribute(params Type[] types) { ... } ... }
class ExtensionInstanceMemberAttribute {  }
class ExtensionStaticMemberAttribute {  }
// the actual extension becomes:
[ExtensionType(typeof(Thing), typeof(IFoo))]
public static class FooThing
{
  [ExtensionInstanceMember]
  public static void Foo(Thing @this) { ... }
}

void Frob(IFoo foo) { }

// this line:
Frob(new Thing());
// is compiled to this:
class <mangled>Thing_IFoo : IFoo
{
  internal <mangled>Thing_IFoo(Thing thing) { this._thing = thing; }
  readonly Thing _thing;

  void IFoo.Foo() { FooThing.Foo(this._thing); }
}
Frob(new <mangled>Thing_IFoo(new Thing()));

hamarb123 · 2024-08-12T12:03:12Z

I know that suggestions for extensions for enums have been proposed for different use cases, but have there been any thoughts on how extensions might add enum members to an existing enum? There are a few proposals on this repo looking to be able to "extend" existing enums with new values:

I mean, you could almost certainly write this, even without explicit support for adding new enum members (whether you should is another question):

public implicit extension ConsoleColorExtensions for ConsoleColor
{
    public const ConsoleColor NewColor = (ConsoleColor)71;
}

zms9110750 · 2024-08-17T22:43:58Z

I have a problem.
Game engines provide a vector class and basic mathematical methods.
If I am dissatisfied with them, I may write extensions. But if I want to apply to all vectors provided by engines, is there a way?

To avoid the extension of vector 2D affecting vector 3D, we should specify the type of extension to be applied.
But specify without modifying the code.
Declare ( extended of extension ) for bridging in a specific project?

alrz · 2024-08-25T10:00:04Z

This is probably further down the line but I think this could solve record custom equality for lists,

public implicit extension EnumerableEquitableExtension<T> : IEquitable<IEnumerable<T>> for IEnumerable<T> 
    where T : IEquitable<T> 
{
    public bool Equals(IEnumerable<T> other) => this.SequenceEqual(other);
}

That's assuming EqualityComparer<T>.Default could take extensions into account.

HaloFour · 2024-08-25T11:21:24Z

@alrz

That's assuming EqualityComparer<T>.Default could take extensions into account.

I don't imagine that it could? Given that property is already compiled there's nowhere for the extension binding to occur. You'd need some kind of runtime registry of extensions (or implementations) per type, I'd think. However, if the goal was specifically to support that for equality comparison of the fields of a record, the language could have always supported mechanisms to provide custom equality comparers, it's just something that the language team intentionally didn't want to do. I don't see this as a way to backdoor that decision, given I think it'd be a much messier approach.

alrz · 2024-08-26T16:19:57Z

I don't imagine that it could?

I think that's a question of its own. If these interfaces are supported by is and IsAssignableFrom, EqualityComparer support would fall out of that.

HaloFour · 2024-08-26T16:32:24Z

@alrz

I think that's a question of its own. If these interfaces are supported by is and IsAssignableFrom, EqualityComparer support would fall out of that.

I doubt it. EqualityComparer<List<Foo>>.Default wouldn't know anything about the potential extensions that exist for List<Foo> that happen to be in scope at the point of invocation. You would need the compiler to understand the specific context and emit said code, which could be a new strategy that the compiler could employ to support custom equality/sorting for types. Personally I think that'd be way too subtle a way to implement that.

colejohnson66 · 2024-08-26T16:42:43Z

Agreed. If you want a custom IEquatable extension as shown, you'd need to do EnumerableEquitableExtension<List<Foo>>

alrz · 2024-08-26T16:43:54Z

EqualityComparer<List<Foo>>.Default wouldn't know anything about the potential extensions

My point was that this is not about EqualityComparer specifically. Extending is and IsAssignableFrom is certainly not impossible (new conversions can be encoded using attributes for both compiler and reflection to use), but it is a question if these implementations are going to be integrated into the type system and if so to what degree? - the minimum being only in generic constraints, maybe.

HaloFour · 2024-08-26T16:50:33Z

Extending is and IsAssignableFrom is certainly not impossible (new conversions can be encoded using attributes for both compiler and reflection to use), but it is a question if these implementations are going to be integrated into the type system and if so to what degree?

I totally agree, it is an interesting conversation. The real question is can it be done efficiently without effectively making all type checks that much more expensive. I assume it wouldn't affect already compiled code, but maybe the compiler could emit additional type checks for extensions that are in scope?

// given
public interface IFoo { }
public extension Int32FooExtension for int : IFoo { }

object o = 123;

// then
if (o is IFoo foo) { }

// lowers to
if (o is IFoo foo) {
    // already is IFoo
}
// otherwise enumerate extensions in scope that implement IFoo
if (o is int $temp) {
    IFoo foo = new Int32FooExtension($temp);
}

alrz · 2024-08-26T17:29:51Z

In Rust there's a whole concept of trait objects to support this by capturing anything about the trait impl at the time of assignment. Generic contraints are different because the information is available statically so naturally there's no performance penalty if used that way, otherwise you get a complete different codegen.

CyrusNajmabadi · 2024-08-26T19:10:39Z

so naturally there's no performance penalty if used that way

Well, there can be a penalty. It just depends on if it's ok where that penalty happens. In rust, this penalty often happens at initial compile time, as well as with potentially huge code-size explosion. That's often the right tradeoff for users, but it's not universally so. A lot of people have a distaste about runtime costs. But practically speaking, it's usually totally ok, and extremely high perf code doesn't care anyways, since it's not using tehse operations to begin with as even the stock behavior today is too costly for them.

ds5678 · 2024-08-26T21:37:35Z

I'm against implicit extensions affecting EqualityComparer.Default. That feels like spooky action at a distance. Only explicit extensions or extensions used as type parameters should affect it.

Okay:

EqualityComparer<ExplicitExtension>.Default
EqualityComparer<ImplicitExtension>.Default
EqualityComparer<T>.Default // where an extension is used as the type argument

Not okay:

EqualityComparer<BaseType>.Default

HaloFour · 2024-08-27T12:22:48Z

@alrz

In Rust there's a whole concept of trait objects to support this by capturing anything about the trait impl at the time of assignment. Generic contraints are different because the information is available statically so naturally there's no performance penalty if used that way, otherwise you get a complete different codegen.

I don't know a whole lot about Rust but reading a bit about implementation and coherence it seems Rust also forbids the ability to provide an implementation for an external trait to an external type. So this kind of behavior wouldn't be permitted in Rust anyway, and that is intentional so that you cannot change the meaning of existing code. It also prevents the problem of having multiple implementations for the same trait to the same type. That's a very different design from extensions where the point of extension implementations would be to extend external types, and extensions can be scoped by namespace.

The idea of extensions affecting the runtime behavior of code is certainly an interesting conversation to have, but I think there are several cans of worms there.

wherewhere · 2024-10-10T08:44:33Z

Is that possible to use extension to create COM/WinRT wrapper?

// Such as we have a COM interface.
[GeneratedComInterface, Guid("70C65787-A406-49A8-938C-CE8CBBD26421")]
public partial interface IInterface
{
    void Method();
}

// And we have a class in some place.
public class Class
{
    public void Method()
    {
        // do something...
    }
}

#if Expect
// Then we can use extension to implement COM/WinRT interface for the class.
[GeneratedComClass]
public partial extension CoClass for Class : IInterface;
#else
// Which should write like this now.
[GeneratedComClass]
public partial class CoClass(Class inner) : IInterface
{
    public void Method() => inner.Method();
}
#endif

Now I need to write like this: https://github.com/wherewhere/SelfCOMServer/blob/main/SelfCOMServer/Common/RemoteProcess.cs
Since GeneratedComClass can only used in class, maybe we need to allow class type extension.

[GeneratedComClass]
public partial extension class CoClass for Class : IInterface;

aradalvand · 2024-11-16T13:19:18Z

I'm begging you to ditch the syntactic abomination that is the most recent extensions proposal — this is the ugliest syntax I could possibly imagine for this feature:

public static class Extensions
{
    extension<T>
    {
        public bool (List<T>).IsEmpty => this.Count == 0;
    }
}

What the heck is the point of the enclosing class?! Why introduce a million nesting levels?!?! This is aesthetically horrendous. Compare it with this:

public extension Extensions<T>(List<T>)
{
    public bool IsEmpty => this.Count == 0;
}

Is there any sane human being that could look at these examples and be like "yep the first one looks so much more intuitive"?

Update: Please, for the love of god, consider this proposal instead.

HaloFour · 2024-11-16T14:35:03Z

@aradalvand

I suggest you check out the discussion here: The design space for extension

It lays out the problems with the extension type syntax, the concerns that the language team are trying to address and a variety of different forms of syntax that are an attempt to address it. Many of these proposals are explorations in the design to see how the concerns can be addressed, and the reason for wanting to enclose extensions within a separate class is explicitly discussed.

IS4Code · 2024-11-16T14:42:34Z

@aradalvand

Is there any sane human being that could look at these examples and be like "yeah the first one looks so good"?

Before I read the latest proposal, I had been thinking about the syntax options for extensions and this was what I suspected the outcome would be. To me it makes sense. Consider:

You need to be able to re-use all of the existing syntax for members.
You might want just one extension member.
You might wish to extend different types in a single class.

On top of that, you should pick a syntax that might work everywhere, even top-level or in method bodies.

This might not be the prettiest syntax, but it is the most general syntax that simply works everywhere that makes sense. You would eventually converge on this type of syntax, be it extension {, extension(T) {, extension for T {, this(T) {, this is T {, #extension T or any of the myriad of possibilities.

That being said, I 100% expect the development to go with shortcuts that make using this syntax easier. Compare the unsafe keyword, for example ‒ you can make a whole scope unsafe, or you can use it as a modifier just for a single method, or a whole class.

I am sure this will be the case, if not in the same version of C# that gets the general syntax, then in the one after that.

To be fair though, I do feel unsure about the parentheses in (List<T>).IsEmpty. I don't think they are or should be needed in most cases ‒ parentheses are used for precedence or grouping, and there is no ambiguity here. I would much rather see something like this:

public static class Extensions
{
    public extension<T>(List<T>) bool IsEmpty => this.Count == 0;
}

Having a single unified syntax that works for members, for classes, and for scopes would be a major win.

macco3k · 2024-11-16T16:37:18Z

I wonder why not keeping a syntax similar to the one currently used by extension methods:

public static class Extension {
    extensions<T>(this List<T> source) {
        bool IsEmpty => source.Count == 0;
    }
}

I like extensions better tbh.

aradalvand · 2024-11-16T16:55:32Z

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

HaloFour · 2024-11-16T16:59:49Z

@aradalvand

Add some generics.

aradalvand · 2024-11-16T17:16:58Z

Add some generics.

@HaloFour

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

HaloFour · 2024-11-16T17:23:49Z

@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 · 2024-11-16T17:28:17Z

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 · 2024-11-16T17:30:01Z

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 · 2024-11-20T23:33:58Z

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 · 2024-11-21T00:00:23Z

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 · 2024-11-21T00:09:54Z

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 · 2024-11-21T17:42:35Z

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

333fred added the Proposal champion label Dec 2, 2021

333fred assigned MadsTorgersen Dec 2, 2021

dotnet locked and limited conversation to collaborators Nov 28, 2024

jcouv converted this issue into discussion #8696 Nov 28, 2024

This issue was moved to a discussion.

[Proposal]: Extensions #5497

[Proposal]: Extensions #5497

Comments

333fred commented Dec 2, 2021 • edited Loading

Discussed in #5496

Extensions

LDM Meetings

hez2010 commented Dec 2, 2021 • edited Loading

HaloFour commented Dec 2, 2021

FaustVX commented Dec 2, 2021

333fred commented Dec 2, 2021

sab39 commented Dec 3, 2021

CyrusNajmabadi commented Dec 3, 2021

TahirAhmadov commented Dec 3, 2021

CyrusNajmabadi commented Dec 3, 2021

sab39 commented Dec 3, 2021

TahirAhmadov commented Dec 3, 2021

CyrusNajmabadi commented Dec 3, 2021

TahirAhmadov commented Dec 3, 2021

BhaaLseN commented Dec 3, 2021

TahirAhmadov commented Dec 3, 2021 • edited Loading

CyrusNajmabadi commented Dec 3, 2021 • edited Loading

orthoxerox commented Dec 3, 2021

sab39 commented Dec 3, 2021

orthoxerox commented Dec 3, 2021

vladd commented Dec 3, 2021 • edited Loading

hez2010 commented Dec 4, 2021 • edited Loading

TahirAhmadov commented Dec 4, 2021

Thaina commented Dec 4, 2021 • edited Loading

hez2010 commented Dec 4, 2021

Thaina commented Dec 4, 2021

333fred commented Dec 4, 2021

iam3yal commented Dec 4, 2021 • edited Loading

Reinms commented Dec 4, 2021

TahirAhmadov commented Dec 4, 2021 • edited Loading

hamarb123 commented Aug 12, 2024

zms9110750 commented Aug 17, 2024

alrz commented Aug 25, 2024

HaloFour commented Aug 25, 2024

alrz commented Aug 26, 2024

HaloFour commented Aug 26, 2024

colejohnson66 commented Aug 26, 2024

alrz commented Aug 26, 2024

HaloFour commented Aug 26, 2024

alrz commented Aug 26, 2024

CyrusNajmabadi commented Aug 26, 2024

ds5678 commented Aug 26, 2024 • edited Loading

HaloFour commented Aug 27, 2024

wherewhere commented Oct 10, 2024

aradalvand commented Nov 16, 2024 • edited Loading

HaloFour commented Nov 16, 2024 • edited Loading

IS4Code commented Nov 16, 2024 • edited Loading

macco3k commented Nov 16, 2024

aradalvand commented Nov 16, 2024

HaloFour commented Nov 16, 2024

aradalvand commented Nov 16, 2024

HaloFour commented Nov 16, 2024

CyrusNajmabadi commented Nov 16, 2024

CyrusNajmabadi commented Nov 16, 2024 • edited Loading

yaakov-h commented Nov 20, 2024

CyrusNajmabadi commented Nov 21, 2024

yaakov-h commented Nov 21, 2024

En3Tho commented Nov 21, 2024 • edited Loading

This issue was moved to a discussion.

333fred commented Dec 2, 2021 •

edited

Loading

hez2010 commented Dec 2, 2021 •

edited

Loading

TahirAhmadov commented Dec 3, 2021 •

edited

Loading

CyrusNajmabadi commented Dec 3, 2021 •

edited

Loading

vladd commented Dec 3, 2021 •

edited

Loading

hez2010 commented Dec 4, 2021 •

edited

Loading

Thaina commented Dec 4, 2021 •

edited

Loading

iam3yal commented Dec 4, 2021 •

edited

Loading

TahirAhmadov commented Dec 4, 2021 •

edited

Loading

ds5678 commented Aug 26, 2024 •

edited

Loading

aradalvand commented Nov 16, 2024 •

edited

Loading

HaloFour commented Nov 16, 2024 •

edited

Loading

IS4Code commented Nov 16, 2024 •

edited

Loading

CyrusNajmabadi commented Nov 16, 2024 •

edited

Loading

En3Tho commented Nov 21, 2024 •

edited

Loading