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.

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)

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 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.

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.

they could add the val keyword and copy kotlin syntax

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.

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.

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

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.

@@user-qp8bt7gq4b 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.

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.

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 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).

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

They cannot, extension methods in general are only normal methods with a nicer syntax. The thing interesting me here is both the possibility of having some niceties (like .dp/.sp/.rem of Kotlin for UI) and a possible structural parametric polymorphism.

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.

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

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.

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

They are just extension methods, so public members only.

Partial class needs to be defined in the same assembly. So it won't work for types you don't own (that are in libraries/other assemblies). Child class - first requires the base class to not be sealed, but also if you do create a child class - you then have to allocate it, on top of already allocated Person object. Let's say your Person object comes from external (not owned by you) repository - You call var person=repository.GetPerson(...); and get that. To then cast it to an Adult you have to call new Adult(person); and have that constructed, since you cannot just cast to a child class from a base class, if it's not that to begin with. That will end up allocating a whole new object on a heap. Meanwhile the extension is just a facade over the type, masquarading it as a child type. It does not re-allocate it, it only "pretends" it's an Adult type by exteding it's capabilities. You can then create methods, in your own code, that will accept Adult type and use it as if it was an inherited object, and then return it to not owned part of the codebase, as it's still "just" a Person.

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

@@theMagos Yeah, but I want syntactic sugar.

Because it's not out yet

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

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.

Fields - definitely not. That would require inheritance.

Yeah, fields are impossible in this sense without modifying the CLR, and this I think would not be good anyway (because it would be a mess, literally, because serialization and many assumptions about data layout we need to make when developing programs). But you can simulate this explicitly if you want with a weak hash map.