The weirdest C# 11 feature but also the best one

Check out my courses: dometrain.com
Become a Patreon and get source code access: / nickchapsas
Hello everybody I'm Nick and in this video I will introduce you to what is in my opinion the weirdest but also the best C# 11 feature and that is static abstract members in interfaces. The concept of having implementations in interfaces was weird enough in C# 8 and C# 11 introduces static members in them too, but it actually goes beyond that. Let's take a look at this new feature in this video.
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: bit.ly/ChapsasGitHub
Follow me on Twitter: bit.ly/ChapsasTwitter
Connect on LinkedIn: bit.ly/ChapsasLinkedIn
Keep coding merch: keepcoding.shop
#csharp #dotnet

[@KanashimiMusic]

I've been waiting for abstract static members for YEARS. Thank god.

[@dlhsnbrn1275]

Sooooo many use cases come to mind. In particular, I sometimes need something like a new() constraint, but with arguments. Now I can have a static abstract function that returns an instance. This is almost as powerful as Rust traits and I absolutely love it.

[@bogdanbara1496]

I've encountered a few situations at work where this would've helped me a lot and I was always wondering why this wasn't a thing. Glad to know they're adding it, I'll definitely make use of it once it hits general availability.

[@muhamedkarajic]

Thats not a thing in a lot of languages probably cause of the issues that it comes with but I'm also glad!

[@aossss100]

I must also agree with you :) The feature looks weird indeed. However, I've already started to use it in my projects. One practical use-case: reflection driven object instantiation for dynamically resolved types with non parameterless constructors now can be avoided by enforcing types to implement static factory methods.

[@Zashxq]

yes!!!

[@vertigosoft]

Yeah

[@co2boi]

Kickass. I'd love to see an example implementation

[@jackkendall6420]

Now I'm just waiting for them to implement extension interfaces so we can effectively have typeclasses and go full galaxy-brain Haskell mode.

[@Krimog]

One of the first things that comes to my mind is "clean" way to bypass the lack of a generic constraint for a constructor with parameters (and I still don't know why it doesn't already exist). You can create an ICreatable, which would have a static abstract TCurrent Create(T1, T2, T3) method, which itself would just return a new TCurrent(T1, T2, T3)

[@AlexBroitman]

Great feature! Two things I would like to know: 1. Why the word "abstract" is needed? Why just "static" is not enough? Everything in an interface is abstract. 2. Does it mean that boxing/unboxing will happen every time when I use INumber? One of disadvantages of using interfaces with structs is boxing.

[@saniel2748]

Static interface methods can only be used in generic methods. Therefore no, there will bo no boxing since your method will compile for exact used implementation of interface. Also no, methods in interfaces are not abstract, there are default interface methods in C#

[@TristanGoetz]

I am a HUGE fan of using generics and I have come across SEVERAL instances where I wished I had the ability to do abstract static methods. This will be a GREAT improvement for me in the future when it is fully released and I can convince my company to use it!

[@ZipADeeeDoooDaaa]

It might be wise to keep the static parts of a type in a separate interface called e.g. IEndPointStatic. If you do that, you kind of define a new "type" that represents the static aspect of the class. Then you can define the interface IEndPoint : IEndPointStatic { ... } to include the non static methods. Since static methods are not accessible from an instance anyway, you now effectively split the class in two. This gives you access to just the static part or both. At least for me this makes it easier to wrap my head around the "static abstract interface" concept.

[@fred.flintstone4099]

I agree, but then should it even be possible to have static members on a non-static class? Kotlin doesn't think so and disallows static members on non-static classes and instead introduces the concept of a "companion object" where all the static members are defined. Another thing to be beware of when separating interfaces is that in .NET you can only check for the presence of one interface, unlike PHP and TypeScript where you can declare that a method parameter accepts a class that must implement two interfaces.

[@DamienSawyer]

I love the speed at which you move through code. I checked if I was on 1.5x... but nope... you just move that quick.

[@jawwadalam]

The API endpoint example/use case was a great pick. It seems like some of us might have already been to the path where we always wished, if we could provide a default implementation with an interface.

[@astralpowers]

I saw their video on Generic Math which uses this. Very powerful stuff.

[@billy65bob]

Interfaces requiring static members is something I've wanted for years; I've made do by having a runtime check to check for specific constants, and fetching it via Reflection. There's a lot of random things this would be very useful for in the old code base I manage too; the people who designed it 20 years ago defined interface methods to fetch specific items from the cache by key... and then implemented it both statically and as an instance method.

[@jimread2354]

I love that, there are a number of times i've had to instantiate a class for no better reason than to access some property like your Pattern property. I have a lot of autogenerated code in my codebase where a base class has maybe a script that it generates and inheriting classes will have properties that fill in that script madlibs style. This will prevent a lot of Reflection and / or switches if I can just have the static abstract method defined in an interface. Excited to start working this into the code, it will clean up a lot and make it much easier to maintain.

[@kaksisve4012]

Finally C# interfaces define behaviour for a type rather than type instance.

[@JacobNax]

for some people it might not look that useful but for us veterans it definitely is huge. static abstract methods are so huge cause not only they provide convenience in some scenarios, but in certain architectures (data orientation) you want the methods outside your object definition for memory reasons (some will get this)

[@ekeke7125]

Wow, this is absolutely awesome. This is a game changer for me in many little ways. Thank you for doing this video, I knew about it but kept postponing reading about it because it felt like MS was talking about this only in context of generic math.

[@fergazoid]

Yes!!! I'll have immediate use for this for program extensions, factories and replacing some singleton implementations.

[@antonmartyniuk]

I think it's one of the best features implemented in C# in the last few years besides records, init only properties and nullable reference types

[@co2boi]

Records rawk

[@stel.io-sev]

Another nice one Niko :). Keep it up. I like these ones more than the optimization ones.

[@warrenbuckley3267]

C# has needed a way to constrain a generic method to numeric types since generics were first introduced. This always bothered me that it was missing.. Glad to see that we can now, except we're still using the legacy framework at work so I won't be able to take advantage of this.

[@figloalds]

Amazing, I have needed this back in the day when writing my micro-orm and now it's going to exist, I love it.

[@brianwestfall8105]

A few months back I used this to clean up my Dapper repository. Much like your last example, I was having to new up an object just to get a stored procedure name from a string. Since Dapper always returns a new object anyways this was an un necessary instantiation. Not to mention the other overhead of constraints, new (T), and etc. Great video.

[@endofunk2174]

Very similar to how Swift protocols work; i.e. a very useful language addition. I suggest looking at how this is used in Swift for ideas on what potentially possible in C#.

[@MicheleMassari]

it's been year that i'm waiting for this feature! Thanks Nick! Precious as always

[@nanvlad]

I made something similar years ago and called it 'static inheritance'. It was needed for Dapper types registrations on app initialization. Here is the sample of code simplified public abstract class Base where T : Base, new() { public static T Zero = new(); } public class Derived1 : Base { } public class Derived2 : Base { } public void Method(T item) where T : Base, new() { // result will be a value from one of Derived classes T result = Base.Zero; } But it the code provided I'm not able to have different types for numbers (double, int etc.) However, for the List static initialization it worked perfectly

[@jingzheshan]

Too good, there are so many situations you have a T with parameters. Love it🍭

[@marcusmajarra]

An interesting feature. Allows for capabilities I usually find in C++ template programming.

[@kenbrady119]

Nice! I've run into the generics for numeric types blockade several times.

[@MegaJoka100]

I just recently hit exactly this problem in one of my projects. Very nice to see that they implement those now in interfaces.

[@paulkoopmans4620]

I agree with you Nick and everybody else. This is such a useful feature and should have existed for very long time IMHO as well. I like your example too. Thanks for your awesome content.

[@Papierkorb2292]

This. Is. Awesome! I think it would also be useful to enable those interfaces being automatically added (for example when overwriting an operator), so it can directly be used for such generics without further modifying the code of the type.

[@Sindrijo]

This is great, it makes the curiously-recurring-template-pattern not so crippled in C# anymore! I've been logging for a 'TSelf' in C# for a long time, because you can basically make traits with this!

[@SixTimesNine]

That’s great. Will definitely be using that. Thanks Nick!

[@MaxReble]

I want to use it in production for sensors. I have an ISensir interface with DeviceId etc and then classes with a DeviceType enum. Now I can only tell by the interface which device type the sensor is without using reflection - fantastic :) The first time I needed this feature was in the very beginning of my C# career and I was wondering why such an obvious handy thing was not in the language

[@LukeVilent]

Omg, I needed this feature so much a few years ago! That time, iirc, I've been using unsafe code like to overcome the issue of needing to sum generics. Finally INumber is there, and it look so, so much better from a viewpoint of a mathematician than Java and Python alternatives.

[@henrikcarlsen1881]

An analogy came to me while watching: C# is like the Stutz Blackhawk (a car). It's impressive but still ugly. There are so many "let's do this because it solves a particular problem"-fixes. A static in an interface is tampering a well-defined concept.

[@carlitoz450]

Thats a nice improvement ! Thanks for sharing

[@seangwright]

Static abstract interface properties combined with generic attributes makes meta programming sooo much more elegant and removes lots of noisy boilerplate.

[@Robert-G]

reminds me of virtual class members in Delphi. (one of Hejlsberg’s previous languages) You could get an instance of the class itself, and every static became an instance member on the class reference. Allowed for heat things like polymorphic factories that were build by the compiler.

[@QwDragon]

Very cool! Used such thing in typescript.

[@PeacefulMindss]

Simply beautiful practical addition 👍.

[@imurashka]

One more cool feature in C# that I won't be able to use for a long time. Unity.

[@MrNotour]

It fix one of the differences between c++ template and generic c# => to be able to pass values. It could be interesting to see the optimization the compiler make bellow, Allocation size, prevent allocation, flattern loop intead of iteration ...

[@muhamedkarajic]

This is just great, interfaces are becomming more and more like real abstract clases without the issues.

[@alfonsosuarez9317]

I watched the .NET standup about static interfaces last week and was so excited!

[@PetrVejchoda]

I just needed this in my work!!!

[@vorontsovru270895]

This is an incredibly necessary functionality. Now, finally, you can oblige to contractually implement Parse/TryParse, for example. It's been a big pain for me over the years.

[@KibbleWhite]

If I think I can use it in the way that I hope, this will be very very useful in code reduction. I have a class which contains a model, where some of the methods handle each class sometimes in the same way, but occasionally it will need to handle things in a different way. This will change the code maintenance completely and make thing far easier for our team to read and understand, I hope...

[@SebGruch]

Oh, finally, I'd already encountered several times situations, when I would gladly welcome both of these features. Good job!

[@zbaktube]

About the first example, technically there is a concept for generic zero: default(T). But, to call the op_Addition would more challenging 🙂

[@Eddyi0202]

Suprisingly in this scenario presented by you for example, it's not possible to register all endpoints by doing assembly scanning for all classes that implements IEndpoint interface. So a little bit dissapointing but still really good feature.

[@MasterNinjaFighter]

Wow, it looks extremely useful, not only for math (which looks very useful too). I was looking for something like this in order to clean generic code for game development modules.

[@wknight8111]

There are two features I've been asking for, regularly, since .NET 3.5: Specifying non-default constructors in generic type constraints, and the ability to have these "static abstract" methods on interfaces. This one is probably better for my purposes, because we can use interfaces to specify static factory methods instead of having to specify custom constructor signatures in the already-cramped generic constraints list of each type that uses it. I'm not entirely thrilled with the syntax (I wish the "abstract" keyword could be omitted, but I understand why they did it this way) but it's a good feature overall

[@udeapi2185]

Hi Nick! Can you add your key presses on top of your videos? You use a lot of shortcuts and I want to use them like you do. Keep up the good work!

[@dvldev]

Great! A couple week ago I try to do something like this feature and I wrote two tons of code to make it as much generic as I could but in this feature it is so simple and clean. Let's wait .NET Core 7!!!

[@ciberman]

I love it. This would make easier to have more declarative approach in some cases where OOP is cumbersome.

[@slopopter]

I think will be good to develop events using observer pattern with this static abstract feature.

[@GlobusUA]

Great feature. Thanks for presenting.

[@gdargdar91]

This opens a path to Typeclasses, which is a better and more performant way to do interfaces and polymorphism.

[@Anishin1]

The more I learn about all these new features of C# and understand the direction it is developing, the more I think that new reference point of C# is Rust.

[@AlanDarkworld]

The "static abstract" part is very interesting, I've never seen that one before. Seems very useful. The INumber interface is a good idea as well, I wonder why it took them so long. What bugs me a little is the self-curious generic on INumber. While I can totally see where they're coming from (the idea isn't new), the generic could be avoided if the language and typesystem supported an actual "self" type...

[@Andrew90046zero]

I'm honestly not sure where I would use this, but this is one of those things where FEEL like there has to be a bunch of different ways it can be used. If I understand correctly. This feature allows you to have static members in a class, but when you inherit (or implement) that base class (or interface) from another, you are required to implement the static stuff. But that requirement means that static member functions could have their own unique implementations, but still be static. Hence no heap allocations! Again, this is one of those features that FEELS like it could be used in a ton of ways, but im not sure how.

[@reecenoone3113]

I had to wait for this feature do any sort of scientific computing in C#. Now it’s here, I don’t know how I lived without it

[@pagorbunov]

Finally I can use and then mock static classes without creating proxy-classes.

[@alirezanet]

Looks great, but I hope it also supports the default implementation.

[@MidnightSt]

oh. well, now I understood why I had so much trouble when I tried to implement generic N-dimensional numbers.

[@kemsekov6331]

There was a plenty of situations where I would use this. I remember when I had to do this exactly weird thing as adding new() constraint and doing this stuff, which is pain in the ass

[@agsystems8220]

Oh thank god. Bugged me no end that particular limitation. One of those "why didn't this exist already" things. Classes have no business having any functionality that interfaces do not. Now we just need tests attached to interfaces so that implementations can automatically be tested to see if they do what people using the interfaces expect, as well as being the documentation that defines the contract between implementers and consumers. Basic stuff, like x+0 is expected to be x, and x+y is expected to be the same as y+x, or that if you try to unsaveDivide by zero you are walking into undefined behaviour and it is a caller side bug. We are so close to separating implementation from specification, and I really wish they would just make it a deliberate effort, rather than sauntering in that direction.

[@frankhaugen]

The work done to get "generic math" to us is crazy awesome and so useful. And the huge number of interfaces that is available to be used by library maintainers for a lot of QoL functionality is awesome 👍

[@co2boi]

Ok, Charles ;-)

[@JosephTX89]

My first thought was that this is super weird. My second thought was that this is less weird than `where T : new()`. I like it

[@alexandruchirita5780]

Hi, The improvement would be in case the object has many properties and allocates memory in constructor (like a form with child components with an InitializeComponent method), but in your last example it didn't improve much. The first example was better in my opinion, with generic numbers calculating sum in case both implementations were required, to stop repeating code (following the "Don't repeat yourself" principle). Keep up the good work!

[@phizc]

Even if the constructor doesn't allocate/do work, the object would be put on the heap for no reason. Yeah, it's only a few bytes, but is another thing the GC have to clean up. The generic math examples are great and it can remove a lot of redundant code, but they haven't showed examples of how you can use statics in interfaces for your own purposes. I.e. Microsoft's examples have been more about INumber and Co than the underlying technology. I watched Mads' video a few months back, and the dot net stand up with Tanner Gooding and Co last week, and it wouldn't surprise me if some people who watched them didn't know afterwards that you could make your own interfaces the same way.

[@alexandruchirita5780]

​@@phizc I agree, in case these objects were big this would be an improvement, but I wouldn't stress to do these changes for small objects (if I really search for improvements, maybe other stuff might improve more).

[@coolmn786]

I’ve made a discord template using activator and reflection to handle different actions a bot can handle. Having this will be a game changer

[@Zashxq]

i have a usecase similar to the one in the video, where i have a bunch of similar classes in a library of mine that share similar "shapes" on their types and are used in all of the same places, but those static members can't be made generic, making it impossible to use a single interface for all of them. it forced me to create a bunch of ConvertTo() methods or elect to work with instances (but the constructors are NOT parameterless and cannot be without introducing situations where i'll have to deal with invalid/missing data). static abstract interfaces immediately solve this problem for me

[@nickpalladinos]

It looks like Haskell's type classes! addAll :: Num a => [a] -> a

[@SimonClarkstone]

I thought that too. Or Rust traits.

[@nickpalladinos]

@@SimonClarkstone I need to study the implementation details... because in Haskell one technique of implementing type classes is dictionary passing.

[@calvinwilson3617]

So glad they are adding this

[@5cover]

Seems useful for factory interfaces.

[@sealsharp]

Great feature!

[@SandeepSharma-SSA]

@Nick Chapsas Curious to know why you made .net 6 startup video private? or is it coming back in better way?

[@nickchapsas]

It is yes

[@TinusBruins]

I wonder if it would allow to only enforce the subclass of a abstract class generic class (that of course implements the static interface) to implement the abstract static methods/properties. Because then in theory the abstract parent class can access a static property of it's child. And if that's the case I wonder if you can access a static method defined in the parent through the child. Like ChildClass.StaticMethod(); and if the generic type available in StaticMethod() would be that of the child. The reason: This would allow to have a bulk of the code in the parent class. Where the child only has to fill in a few a blanks. Example Parent has a static Find() method defined and child has property Table and Fields and the parent could build the whole query and return instances of child :)

[@yuGesreveR]

The most useful feature for libraries that introduce a concept of units!

[@anonimxwz]

It looks very useful with strategy pattern or command pattern

[@ztBlackGad]

Great feature. Waiting :)

[@uncommonbg]

Holy moly, what a sick feature.

[@bradoestreicher3476]

This seems awfully close to static methods in interfaces which I would love to see

[@BrentBatch]

What about DI for that endpoint? you made the method static.

[@jonathh14]

Hi, are the project example's available for download?

[@FireDragon91245]

good stuff

[@proviste]

It's going to halve the complexity of my DI bootstrap in many projects. Finally.

[@jernmon]

I guess this might have been covered in a video about Minimal APIs, but how would you deal with dependency injection if the Handler and the HelloMethod are static?

[@nickchapsas]

Absolutely normally. You just inject the service in the method and the lifetime is respected. The method can be static but it doesn't mean that it's the same invocation. It just means that it needs nothing from the class it lives in

[@kostasgkoutis8534]

The fact that Microsoft goes lowkey on this doesn't surprise me. Not with all the (unnecessary) controversy going on lately about expanding the language or the paradigm (no main method, minimal apis etc). Better to let others blog about it, rediscovering all of its use cases, than touting for it yourself. I for one will certainly use this.

[@p4xx07]

Such a good feature!

[@CrapE_DM]

I've been wanting this for ages! Why did it have to end up in a language I don't use?

[@patfre]

I accidentally stumbled upon this feature as I made it and visual studio then told me that this feature was in preview and should be avoided

[@erikgook598]

Reminds me of Haskell Typeclasses.

[@alfonsosuarez9317]

Nick, can you take a look at roles and extensions for C#? It's a proposal in the csharplang specification repo for extending types similarly to Rust traits. Probably you won't make a video about it now, because it is only a champion proposal. And it doesn't have a working prototype and may be cancelled anyways. I am trying to make a very simple prototype of them, but compiling Roslyn is a pain in the *ss for my computer :c

[@alfonsosuarez9317]

Your opinion on the proposal might be great!

[@drewkillion2812]

I really want static extension methods

[@swedishprogrammer]

Wow, interesting!

[@TheOneAnOnlyGuy]

I'm a bit confused about the naming: Why wasn't static enough, why do we need the abstract keyword? 'Instance properties' which also have to be implemented by all implementers are also not called abstract. Does anybody know?

[@goodoleme747]

Did the field keyword get released with c# 11 ?