I love the Static members in Interface features. However I think that math focused example of application is way less required and useful than using it for common applications such as to centralize metadata like entity model info or behavior like business rules or so (i.e. require less or no extension methods or reflection).
Agreed, generic math is very cool (great for the BCL to include), but for end developers there are a lot of other opportunities to use static members on generics via interface constraints. Factories are one usecase (as mentioned). Personally I have usecases in EF Core where an interface returns a different Func depending on concrete type, which will in turn generate different SQL queries when EF gets to it. In this way I can significantly reduce the amount of duplicate code in the codebase by writing generic extension methods over an interface which in turn define a single LINQ query that organically changes based on which type is used. I already do this with reflection... I basically define the method on the interface as a normal interface method, but in the implementation I make sure to never touch the "this" reference. Then I use Delegate.CreateDelegate to create the delegate manually with a "null" this reference, allowing the method to be called as if it were a static method (without instantiating the object), even though it's really an instance method. Once I get C# 11, I can swap all of that code right out and it'll be beautiful ✨
I'm still stuck in .Net Framework land (I honestly hope Microsoft just fully ends support for it soon, so we _have_ to convert our projects, but that won't happen anytime soon unfortunately.. (Not that we'd swap even if they did >_>). Thankfully almost every feature added to C# since 8 (The first version of C# not officially suppported in Framework) does work. Practically only the interface-specific ones don't. That's a long pointless tangent. All to say; I had a scenario last week where an static abstract interface member would've been useful, but I couldn't use it, so I had to resort to instantiating each type just to get metadata, which feels so wrong.
While it's true most people won't need to make types that implement INumber, it's an easy example to show what's possible. Generic math has already been used to trim a lot of duplicate code in the BCL. E.g. LINQ's Sum method.
You seem to be missing some interpolation. $$$$$$$$$$$$$"""""""""""""""""""""""""""""""""""""""""{{{{{{{{{{{{{{{}}}}}}}}}}}}}}}}}}}}}{{}{}{{{{{{}}}}}}}}}{{{{{{}}}}}}""""""""""""""""""""""""""""""""""""""""""""""
I wanted to ask the same question: Why? If you need all that, why not use C++/CLI directly for that. But speaking of which, C++/CLI could support C++20 things like std::thread and stuff like C++ lambdas, which is about supported yet. It makes writing .net in C++ much harder not having these syntactic sugars. On the other hand, it is s great way to really understand what happens in C# under the hood, if you have to write it verbosely in C++. (Sorry, I think I drifted a little from the actual topic.)
@@sps014 You are probably right, I didn't thought of that. But I'm still not sure, that putting all those C++ concepts into C# is a good idea. Maybe instead it would be a better idea to improve C++/CLI to work on different platforms. Or create a possibility to create pure .net assemblies with C++ instead of mixed assemblies, like with C++/CLI.
@@martinprohn2433 it would be great if these features are available and are not enforced on existing users (so their workflow is not hampered) and yet benefiting Low level developers in achieving high end performance goals in C# itself rather than utilising rust or C++ code.
Why not instead of public required string FirstName {get; init} just have something like public string FirstName {get; required;} . it's more clean and required implies it should be initialized like init. am I missing something here?
Checked a bit of document and my guess is that because double[] isn't inheriting or implementing Span there's no way for the compiler to know which T to use. Not sure if it's possible to figure out generic types using implicit conversion (posible means that there's mathematical proof that it can always work), but it's reasonable that it isn't working yet.
@@FlameRat_YehLon True, they are different types, but I've passed double[] to methods that take Span lots of times before. Don't think there was anything special about them
@@b33j4y The only reason you can pass T[] to Span is that there's an implicit conversion being implemented. And this doesn't say anything about if you don't specify the T, would the compiler still be able to know which T it is.
There are new age languages like Rust, Go, Carbon and Zig etc which are much faster. Even Python, JavaScript, Java are also working to make the language/framework faster. Seems everybody working towards increasing performance. Can C# be made faster ?
People don't use languages based on how fast their are? Nobody uses rust, go, zig. C# is already 100x faster then python and yet python is more popular.
In .NET 7, you can compile your app with AOT (ahead of time). You end up with an app that is self-contained and that has been compiled to native code. The app will start up very quickly and use less memory. It would be nice if benchmarking sites like techempower would use test the AOT version of C# as well as the normal JIT (just in time) version to see how it stacks up against C++, GO and Rust
C# is rolling down to cloaca. Useless, half-baked, stupidly implemented features completely stop me from watching C# progress - I stopped at C# 8.0 and don't want to see your(Torgersen) work anymore.
Make a good video or blog post about what you mean and you will surely get a lot of attention. Ranting in a TH-cam comment and just claiming instead of showing is pointless. From your comment, you could just be a bad old grumpy programmer unwilling to learn anything new (there are definitely a few of those in the C# community).
The auto-trimed indented unescaped string is very creative. This pattern should be in every other language already.
kotlin has trimMargin() and trimIndent() to do this.
Java actually got it first :)
OHHHH, very exciting features, The INumber related is what I have been looking forward to for many years.
Mads, thank you for a great talk! Looking forward to use these great new language features when C# 11 and .NET 7 will be released.
I love the Static members in Interface features. However I think that math focused example of application is way less required and useful than using it for common applications such as to centralize metadata like entity model info or behavior like business rules or so (i.e. require less or no extension methods or reflection).
Agreed, generic math is very cool (great for the BCL to include), but for end developers there are a lot of other opportunities to use static members on generics via interface constraints. Factories are one usecase (as mentioned).
Personally I have usecases in EF Core where an interface returns a different Func depending on concrete type, which will in turn generate different SQL queries when EF gets to it. In this way I can significantly reduce the amount of duplicate code in the codebase by writing generic extension methods over an interface which in turn define a single LINQ query that organically changes based on which type is used.
I already do this with reflection... I basically define the method on the interface as a normal interface method, but in the implementation I make sure to never touch the "this" reference. Then I use Delegate.CreateDelegate to create the delegate manually with a "null" this reference, allowing the method to be called as if it were a static method (without instantiating the object), even though it's really an instance method. Once I get C# 11, I can swap all of that code right out and it'll be beautiful ✨
I'm still stuck in .Net Framework land (I honestly hope Microsoft just fully ends support for it soon, so we _have_ to convert our projects, but that won't happen anytime soon unfortunately.. (Not that we'd swap even if they did >_>). Thankfully almost every feature added to C# since 8 (The first version of C# not officially suppported in Framework) does work. Practically only the interface-specific ones don't.
That's a long pointless tangent. All to say; I had a scenario last week where an static abstract interface member would've been useful, but I couldn't use it, so I had to resort to instantiating each type just to get metadata, which feels so wrong.
While it's true most people won't need to make types that implement INumber, it's an easy example to show what's possible. Generic math has already been used to trim a lot of duplicate code in the BCL. E.g. LINQ's Sum method.
it is just an example
My nuget with a HUGE amount of generated extension methods is now obsolete :-(
What a video bro! Can't thank you enough! Thank you so much you made life so much easier!
" " " " " " " " " Nice presentation, thanks! " " " " " " " " " 🙂
You seem to be missing some interpolation. $$$$$$$$$$$$$"""""""""""""""""""""""""""""""""""""""""{{{{{{{{{{{{{{{}}}}}}}}}}}}}}}}}}}}}{{}{}{{{{{{}}}}}}}}}{{{{{{}}}}}}""""""""""""""""""""""""""""""""""""""""""""""
Oh cool, so C# interfaces can now be used as type classes, nice!
I don't even use C# yet here I am watching/listening this...
How about now?
“That was a joke.” 😂
It was funny even. 😀
I wanted this new string literal format for so long, so I could just slap an entire html page into my string. Also good for sql.
YaY! From Cape Town South Africa...great 😃...sea the sharp canon !!
Amazing presentation and features 👏👏
Given all this new cool stuff, I'm a little surprised to see just INumber and not IRing, IField, etc. Was that considered?
Yeah, number of dollar signs solves a lot of problems nowadays 😏
Too thin joke for C# team. ;]
I'm smelling a new version of Pegasus.
the new namespace System.Numerics :)
Dude, you're Norwegian enough for me. :)
Discriminated Unions,
Struct finalizers
Move semantics,
In C# please 🥺
Why?
I wanted to ask the same question: Why? If you need all that, why not use C++/CLI directly for that.
But speaking of which, C++/CLI could support C++20 things like std::thread and stuff like C++ lambdas, which is about supported yet. It makes writing .net in C++ much harder not having these syntactic sugars.
On the other hand, it is s great way to really understand what happens in C# under the hood, if you have to write it verbosely in C++.
(Sorry, I think I drifted a little from the actual topic.)
@@martinprohn2433 c++/cli is windows only
@@sps014 You are probably right, I didn't thought of that.
But I'm still not sure, that putting all those C++ concepts into C# is a good idea.
Maybe instead it would be a better idea to improve C++/CLI to work on different platforms. Or create a possibility to create pure .net assemblies with C++ instead of mixed assemblies, like with C++/CLI.
@@martinprohn2433 it would be great if these features are available and are not enforced on existing users (so their workflow is not hampered) and yet benefiting Low level developers in achieving high end performance goals in C# itself rather than utilising rust or C++ code.
everytNice tutorialng, I really would pay for a webclass
I wander why to not introduce backticks ` ` instead of multiple quotes " " ?
Like JavaScript does.
Because of languages that have like portuguese that have backticks like in à
@@fabioluizalvaresosti7115 But this code works perfectly in JS with backticks:
var a = `à`;
Did I get you wrong?
Why not instead of public required string FirstName {get; init} just have something like public string FirstName {get; required;} . it's more clean and required implies it should be initialized like init. am I missing something here?
32:00 - Why can't the compiler determine the type of T? (It's not because of a preview version - current VS2022 behaves the same)
Checked a bit of document and my guess is that because double[] isn't inheriting or implementing Span there's no way for the compiler to know which T to use.
Not sure if it's possible to figure out generic types using implicit conversion (posible means that there's mathematical proof that it can always work), but it's reasonable that it isn't working yet.
@@FlameRat_YehLon True, they are different types, but I've passed double[] to methods that take Span lots of times before. Don't think there was anything special about them
@@b33j4y The only reason you can pass T[] to Span is that there's an implicit conversion being implemented. And this doesn't say anything about if you don't specify the T, would the compiler still be able to know which T it is.
I struggle to see the obvious benefit I'd have with static interface members for factories... can anybody give me a simple example?
If you don't see the benefits it's because you never had a full tree hierarchy with 20+ classes and 20+ factories for each one of those classes 😂
What happens when your string literal starts or ends with a double quote? Can you still win?
You can always win
There are new age languages like Rust, Go, Carbon and Zig etc which are much faster. Even Python, JavaScript, Java are also working to make the language/framework faster. Seems everybody working towards increasing performance. Can C# be made faster ?
People don't use languages based on how fast their are? Nobody uses rust, go, zig. C# is already 100x faster then python and yet python is more popular.
In .NET 7, you can compile your app with AOT (ahead of time). You end up with an app that is self-contained and that has been compiled to native code. The app will start up very quickly and use less memory. It would be nice if benchmarking sites like techempower would use test the AOT version of C# as well as the normal JIT (just in time) version to see how it stacks up against C++, GO and Rust
😂🙏😀💥
C# is rolling down to cloaca. Useless, half-baked, stupidly implemented features completely stop me from watching C# progress - I stopped at C# 8.0 and don't want to see your(Torgersen) work anymore.
Make a good video or blog post about what you mean and you will surely get a lot of attention. Ranting in a TH-cam comment and just claiming instead of showing is pointless.
From your comment, you could just be a bad old grumpy programmer unwilling to learn anything new (there are definitely a few of those in the C# community).