The New Extensions EVERYTHING Feature of C# 13! 

Thank you for the heads up

It is indeed

Use the DeArrow extension and you will get non-clickbait titles.

So it's not clickbait... Lol clickbait is only when it is not justified, if you give worms to fish without fishing them, then its not bait is food

If this is "changing everything", your code base has bigger problems.

They can't own state. They are meant to add different behaviors to already existing data based on context in which it is used. I think the better example would be extending some PropertyBag types like ClaimsPrincipal or other Dictionaries with type safe properties.

I don't know, but given that Serialization usually is performed on the instance type using reflection I doubt that these extension methods will be included in the output. They are not really instances, i.e. they don't hold state. As a counter example, assume serialization _does_ work. What would you then expect de-serialization to look like? You can't populate Age with a value since it does not have a backing field to store it. So serialization is bust I am pretty sure.

@@sunefred Very interesting observations, I'd like to try this out and see

What about sealed classes? I'm assuming this would be disallowed but didn't know.

@@pfili9306 I'm not so sure about that. Check out the example in the official announcement docs. They show an example where classes Person and Organization are pulled in, and each Person object needs an Organization property passed in, but in this example scenario there is only one Organization object for the whole application, making the extra property for Person tedious to assigns. So they make an implicit extension for Organization, add a private static Organization ourOrganization = new Organization("C# Design");, and then add a CreatePerson function that always assigns the new Person object with ourOrganization as the Organization property. The property is static in this case, but I don't see anything mentioning that as a restriction rather than what happened to make sense in the scenario.

You would be able to implement interfaces with extensions. It's the second purpose of extensions

You would probably like rust's traits

@@zachemny How does that work? Do you have a link to where it's described?

Adapter pattern

@@zachemny That would mean I could mock dependencies that I don't own and don't have an interface, awesome

they could add the val keyword and copy kotlin syntax

I wouldn't be surprised if they build up to something of that nature in a later release after they get feedback on this initial C# 13 implementation of it. I doubt they would put a boolean condition on the ability to cast to the explicit extension type itself. There isn't really a precedent for that, even with generic constraints. Doing so would hide the boolean condition from the calling code entirely (abstracted behind the cast operation). However, I could see there being a "best practice" of defining, in such explicit extension scenarios, a `TryCreateAdult(out Adult adult)` kind of method that does the boolean check and sets `adult` to `this` when true. That way people would be able to leverage pattern matching and naming conventions to achieve that goal. IF that became so commonplace as to be annoying, then they might discuss potential strategies for optimizing the syntax or at least standardizing it. Perhaps with a `TryExtend` magic method, similar to what they do for TryParse and Deconstruct, etc.

This. You hit the nail in the head

Yes, C# lang team calls it "shapes" AKA duck-typing

Great use case.

​@@ryan-heath Is there a proposal for this somewhere?

Just use functions. Life will be easier. No more class, static, interface, wrapper etc... (ps: it's good to use Interfaces in OOP or code that interact with OOP)

Well, MS decided on many classes to be sealed, so extensions it is. Hopefully we can extend static classes like Math.

Yeah, I don't understand why explicit is needed... then again, I have questioned a lot of c# changes the past few years.... IMO they keep borrowing good ideas with poor implementations.... (primary constructors for example)

Keep in mind that explicit extensions are competing with inheritance exactly as much as old-style extension methods already were, which really is not at all. If you already have inheritance as an option, then all types of extensions become unnecessary, except when you want to add functionality to e.g. an interface or base class you don't control (or where it would be inconvenient to do so e.g. identical functionality for many implementations of an interface where you can't add a class to hold said functionality). If you can add the functionality directly to the class you're working with, you don't need extensions. If you don't have control of the class, you can't add to it without extending or inheriting. And if you don't control how you get *instances* of the class, then extending is the only way. The real comparison is implicit extensions/extension methods vs explicit extensions, and at this stage it seems to be simply an organizational mechanism, but also there may be instances where a particular set of extension methods/properties would only make sense to be applied to objects in certain states.

You would be able to implement interfaces with extensions, according to the initial proposal

Wouldn't that be most properties then? In reality properties are just sugar for a field with Get and Set methods 🤷‍♂️

Not really. Most properties don't change value each time you get them. Those who do more often than not, should be methods, according to the Framework Design Guidelines.

@@viniciusvbf22 aah, I misunderstood you. I thought you meant "can change" not "changes every time". Edit: But in this case the Age property wouldn't change every time you called it 🤷‍♂️

Same.

Yeah, this is for me in this update.

Seems like the WPF team could have used this. Oh wait.

If, and that's a big if, you also get the ability to have fields to store.

@@McZsh This would not make any sense, so I don't think it is a possibility to consider.

To be fair even with the extensions, you would probably write it in a way that is on multiple lines i.e var even = arr .Where(x => x % 2 == 0) .Select(x => x * 3) .Select(x => $"Result is: {x}"); and you would probably write the latter as: var a= arr.Where( x=> x%2 ==0); var b = a.Select(x => x * 3); var even = b.Select(x => $"Result is {x}); The syntax is a bit more concise and readable. But I think the game changer is it makes writing more readable code the easier default. Whereas before it was kind of up to one programmers interpretation, with extensions you are pushed in the direction of writing good code. The only part that is a bit harder to read is that all of the lines eventually return a value that is stored in the variable at the top of the operation. I think if you wanted to go to the full 9s you could have a .StoreAs extension that you wrote at the end. That would make it read better in a left to write fashion, but would likely require more in depth changes to the language so it would become arr .Where(x => x % 2 == 0) .Select(x => x * 3) .Select(x => $"Result is: {x}") .StoreAs(IEnumerable even);

@@NickSteffen No? I don't often find people that would write the version with extensions using intermediate variables, this don't make any sense unless you are doing something very fishy. Also, I'm considering multiple lines, I generally use them as well and with extension methods it feels much natural, sequential and direct. And for the storage part, I think you are just not used to how programming languages work, I really don't think this is a problem per se and I recommend delving into studies to get better at it over time. With time you will be able to see how this all works. But for a brief explanation here, functions return values, and values in C# can be objects that have methods OR extension methods. When you write: var even = ar.Where(x => x % 2 == 0).Select(x => x * 3)...; You are just saying::: take this array, filter all the elements where 'element % 2 == 0'; then take the returned result and map each element on it as 'element * 3'; then take the returned result and map each element on it as 'Result is {element}'; then let the result be returned into the variable attribution. You can write the same thing without extension methods (althought it would take much more work to do so), take a look at the builder pattern and how it is implemented and I think it will be clearer for you how this generally works.

@@diadetediotedio6918 I think you completely misunderstood my answer… The example with intermediate variables with describing was you would do if extensions didn’t exist. It was a counterpoint to your second example on how unreadable it would be. A good programmer would never write it in that unreadable way. My last point was a completely theoretical what if, yes I understand program languages don’t work that way. They also didn’t work “that way” before extension methods were a thing. Fluent/ universal method style is just changing how programming languages work to bend the syntax to how human language works. So the fact that they don’t work that way now is irrelevant to the point. Also C# can in fact work this way in some very limited cases though, since you can declare variables in a dictionary’s TryGetValue method. So for example you can: arr .Where(x => x % 2 == 0) .Select(x => x * 3) .ToDictionary( ( x => x),(x => $“Result is {x}”)) .TryGetValue(6, out int result) Notice how at the end I’m both declaring a value and saving the result into it. You can do the is in some other places like type checks in if statements ex: if( x is string y) Console.WriteLine(y); This type of style is more easily readable for humans as we read continuously in one direction. You don’t have to jump back to the top to see where the variable is being saved. You could absolutely change c# to do this in more cases fairly easily. Now would it be a good idea to do that… I’m not sure, it would at least be interesting.

@@NickSteffen My second point was to highlight that writing in the same way you would write using extension methods would be uglier, I'm not saying that necessarily you would do that (althought I'm pretty sure many people would do). If this was your objection then read again my note on storing things as intermediate variables to improve clarity (implied from context). Next, it is not irrelevant. The fact that we can write fluent functions in that manner is precisely because they work in that way, it does not "change how programming languages work" even if it is to align it better with 'how human language works" (which I can partially concede). Your example with dictionary don't make sense as well, it is a very bizarre way of writting what would be much better written as just .First(...) or .FirstOrDefault(...), to create a dictionary you would already need to iterate through all items so there is no advantage on using it. Also, this works that way in this specific case because then you are fundamentally dealing with another resource of the language, a similar result could be achieved using 'ref' and the semantics are not the same, TryGetValue returns something (a boolean confirming the existence of the item) and it stores the result in the out pointer (because at the time C# had not fast and reliable booleans, many languages nowadays don't have an 'out' thing for example). As for the 'x is string y' example, it is another completely different mechanics of the language again, there is nothing to do with how 'out' works. The convenient 'x is string y' is a modern construct (in early C# versions you had to type manually 'x is string' and then '(string)x' or do 'x as string' and then 'x != null'). As of your question about this being more "easily readable" because it reads continuously in one direction, I don't think I necessarily agree with you absolutely on this. I can buy the point that this is better , but I wont that this is the step to follow for many reasons. I know you are not sure about if this is a good idea, but I'll argue as you held that position (so I can focus on responding anyone who is willing to defend it): First of all, because it is untrue, humans also write things in a name -> description fashion, for example when we respond to someone we can do: A. (responds to point A) B. (responds to point B) And when we want to describe something we have a resource in language that is ':', so we can say: something: this is something (explains) Even when I'm writting this response, and when you did wrote your response, you used attribution in this same sense (for example when giving the example, you said 'ex: (code)'). So it is untrue that this is a direction that should be followed by readability. Second, programming is for humans the same way mathematics is also for humans, the same way everything humans do is ultimately for humans, and in mathematics nobody is arguing of how f(x) = y is a terrible syntax and nobody understands it, you are removing the formal aspect of programming which is that makes it easily readable and generally predictable (human language is inherently noisy and ambiguous, this is why even when programming languages try to approximate to human language they keep a safe distance to what is actually reasonable). Third, because this would make a radical rupture between every single language out there that don't work that way. When you make a change that affects the entire way we reason about programs in a specific language, this should be EXTREMELY more justified than that, because then someone writing C# will arrive in another language (like C, C++, Rust, Go, Kotlin, etc) and suddenly everything he knew will not be valid here, this is one of the reasons of why even arguable that indexes in programming languages should start with 1 (because we usually start counting with 1 in human language) this is not necessarily a good idea as it would break many assumptions when moving from one language to another. As for the end, you can also use extension methods to achieve what you want, you can for example write a: public static void StoreAs(this T self, out T @in) => @in = self; And it would work like you wish.

Eh, yeah, I sorta agree, but I don't feel as strongly about it as I used to. You're right that a person can't be -1 years old, but they're extremely unlikely to be uint.MaxValue years old (or even (uint)int.MaxValue + 1 years old) either, so...?

It is because unsigned int is not CLS compliant, I think this had some influence.

@@diadetediotedio6918 Yeah I can see that. Some of the things I was reading was "why force a language that wants to run on the CLR to implement unsigned types if it doesn't have that concept?" Assuming it's a type-safe language why wouldn't you support unsigned types? I try to delegate as many decisions on what is correct to the compiler as I can. Supporting unsigned types seems like a good idea because you can express your intent a bit clearer (and not have to constantly check for < 0). Could be a phase I'm going through at the moment though too.

@@logank.70 I'm on board with you, and honestly surprised I've never considered this before.

I may be misunderstanding, but C# has unsigned int, but it's a bit cumbersome since C# defaults to signed integers, and you need to explicitly cast between int and uint.

I would see the benefits of explicit extensions if they were not tied to a specific type, like for example public explicit extension Named { public string Name { get; } } So you would be able to do structural typing and this would be extremely useful. But I'm not sure if this syntax allows it, as I didn't readed the docs of this yet.

I feel like explicit extensions are really missing some way to enforce whether it can be casted. Like in the example Nick gave, I'd want to actually be able to ensure that person is only an adult if person.Age >= 18.

@@normalmighty Well, for this you can use a new type pattern, I don't think this is the role of extensions on themselves.

I just don't see what's the supposed benefit of explicit extensions over simply encapsulating the type...

@@mbpoblet A. It is more ergonomic as "encapsulating the type" would require you to make a wrapping method for each property/method of that same type OR expose it through a property. B. You can use it over generics easily without needing to cast in some specific circumstances (which would allocate memory / this is solvable with wrappers but the friction would be even bigger).

Syntactic sugar is all it is (but, I like sugar, it's sweet). The Adult example is not a good one, precisely because not all Persons are Adults, so it's a bit misleading.

@@BittermanAndy Yes, but a way to define a compile time check to see if an instance of A is in fact, a specific subset, B would be super useful, and write now we have to write wrapper types, which means we need to manually expose A's original functionality. I want a way to say "In all ways, Adult is a Person, but in some cases, Person is Adult, and if we're in such a case (via branch analysis) you can call the Adult methods/properties"

Well, we use languages because they are literally pure syntatic sugar on top of something else (like MLIR or machine code), so I don't get it. But I also think they would be more useful with this kind of possibility, and in generic constraints as well.

@@SamFerree this sounds like a great idea to me. Maybe write up a proposal for the C# team?

@@diadetediotedio6918 languages aren't just syntactic sugar. Compile time checking is a very real, and very useful thing.

Hmmm. Yeah, I'd be interested to know how that works with reflection APIs. In order to REALLY be useful for dynamic situations, you'd need `typeof(Person).GetProperties()` to include stuff like `Age`, etc.

Everytime I wanted to create a smart enum, I ended creating a class with some default values and a parser. Every time I used it, I always figured out that I may need something more flexible than a fixed list of values, not mentionning that a bunch of procedures should be handled by a factory. I really think that there is fewer use cases for smart enums than originaly expected.

Bro finally C# is getting some good stuff

Records make a decent replacement for smart enums, right?

I wonder if this will be the case for sealed classes from other libraries and how the polymorphism would play in our own library would an adult be a person?

But its not. See Rust trait system to understand this much better.

@@rogeriobarretto but sealed classes are sealed for a reason. It's just stupid to provide a feature (inheritance), to provide the tools to control this feature (sealed classes), and then to provide ANOTHER feature to ignore the restrictions (explicit extensions). I believe explicit extensions were invented for anything else except inheriting sealed classes.

​@@rogeriobarrettoin terms of serialization, `Adult` does not exist.

@@ЕгорФедоренко-с2щ The problem of ignorance is that it is impossible to beat without the person wanting to learn. Try to understand first what is an extension method and what it solves before arguing on internet.

Why has it become cool to hate on inheritance now...

​​@@jonas9 code becomes non testable because of inheritance in most cases.

@@jonas9 I've hated inheritance since it was invented! ;-)

@@jonas9because when you change the parent you change all its children. This is very problematic.

@@jonas9 I don't get it either. If an existing class doesn't have all features you like, just make a new one that inherits from it. Why are there new fancy features required?

This Is the Way

Well, you can write an extension: IEnumerable.ForEachOrEmpty(Action itemAction, Action emptyAction)

@@theMagos Yeah, but I want syntactic sugar.

I'm not 100% sure, but I don't think you cane use extensions as type constraints, but you will be able to extend a type to implement an interface, so while the syntax in your example might not work, you will be able to do effectively the same.

Yeah... I can see why they wanted to add the explicit approach (to get around naming conflicts and complaints about polluting the namespace), but pretty sure I'll basically always use the implicit approach.

@@BittermanAndy I also plan to use the implicit one, because the explicit seems rather completely useless if it is targetted to a specific type, but I'll try it when it becomes ready.

There's going to be a presentation about extensions at Build on the 23rd (tomorrow at time of writing)

These are still just extension methods with a new syntax. The whole point is to allow for cleaner code.

I was wondering the exact same thing. It looks like it gets pretty close to a C-style typedef, but I suspect you couldn't actually use it as a type. Like, you couldn't write a method with a UserId argument. That would be my number 1 wished-for feature.

Exactly! but maybe a bit more flexible.. as it seems you could extend a class without needing a interface as the conttract...

@@noctavel well, using blanket implementation you can implement a trait in Rust for a bunch of types at once, so I wouldn't call C# more flexible

Wonder if they will have “orphan rules” here too

​@@noctavelthis is definitely less flexible than Rust traits, but it's a very good start. Implementing interfaces on behalf of other types - which is a part of the proposal, but is not coming in C# 13 ( and probably not 14, or even 15) - will make it much more flexible

He means birthday. Taking year - year gives the wrong answer by 1 after your birthday.

@@gbjbaanb thank you, that's what I thought it may be the case but better to be safe than sorry. Essentially the year subtraction could make you older by 1 year, if you haven't reached your birthday month yet, if I understand correctly.

It would be nice if it could work with pattern matching syntax. public explicit extension PersonExtensions for Person p when p.Age > 18 { }

@@MaxxDelusional Uh, this I think would be very bizarre to support, it is encoding runtime behavior into the type system which generally don't go well.

@@diadetediotedio6918 Ya, I thought about it more after I wrote my comment. It couldn't be a compile time error, so the best it could do is just not call the method if the condition is not met at runtime.

@@DaveNatalieTripArc I think this would need to be a different part of the language instead of being bundled here, like a 'precondition' system or something like this. I envisioned some ways this could work in the past, but not with this tight integration with extensions.

@@diadetediotedio6918 I don't think so. It only doubles the functionality of the 'is' keyword (or any other cast action). When applied to an explicit extension, it just performs the pattern matching. So instead adding an if check whenever you need to call one of those explicit extension methods if (person.Age >= 18) { Adult adult = person; var drink = adult.FavouritDrink(); } You write if (person is Adult adult) { var drink = adult.FavouritDrink(); } When the explicit extension looks like this so that the check is only written once. public explicit extension Adult for Person p when p.Age >= 18 { ... } When no pattern is defined, the is will always be true and can be compiled out. The advantage is that the precondition for the explicit extensions (a reason to make them explicit) is part of the definition of the explicit extension.

Yes, it's just a name for the extension (which is not a class any more, it's another "thing").

The compiler is already notifying you to account for both cases of Nullable if you use "#nullable enable"

Yes, basically. Also for devs who dabble in functional programming there's the ability to easily combine types into DUs which adds sort of virtual marker interfaces to the types. The need for this, most of the time, is negated by the design according to OOP principles though.

why?

@@TheOnlyDominik Cause it is amazing for structural parametric polymorphism

@@diadetediotedio6918 ok. I don't need any unnecessary theoretical features.

@@diadetediotedio6918 I only have 30 years of experience in software development, it's too complicated for me.

Bro some of us have been waiting since 2008

Explicit is kind of just a wrapper class with less formality.

@@evancombs5159 kind of... but is it really? I would think that you can't really do pattern matching on this

That's already been true for extension classes, and I feel like the clear majority of people consider that potential for confusion to be worth it for the flexibility it provides.

In some sense. You can have an extension that inherits another extension and use the new keyword to shadow the base extension's member.

This is useful when you use code that you don't own (libraries) and inheritance is impractical (having to re-implement functionality) or forbidden (sealed). In those cases you can act as if the code was yours within reason.

Regarding second red flag, the whole idea is that you don't own the type, so it can be sealed.

I agree. It looks like it's going to be a mess to me. Extension methods already solve 99% of use cases, and you can always write a helper or a proxy otherwise.

@@pagorbunov if something is sealed, then why introducing a way to circumvent that?

@@Velociapcior you do not circumvent anything as you do not introduce a new type. You just use someone's type and make the using of it more comfortable for you without breaking anything.

1) can happen with current extensions too. It's the fault of the developer, not C#. 2) The whole idea of extensions is to get rid of inheritance and use composition instead.

Not sure, but since you can add extension static methods, I'd be surprised if you couldn't. `Person.Create` could be created in terms of implicit extensions as of C# 13(.. maybe 14; unsure whether statics are coming in 13)