What's new in C# 13

[@robinlenaerts4439]

interesting and clear session! thanks. The word "field" has lost all meaning in my head tho 😅😅

[@DrollerTroller]

Where can I buy a shirt like Mads wears? Amazon link?

[@mAcCoLo666]

I'd have called the attribute "OverloadResolutionOrder". I find order to be more easily understood than priorities. So you would read it as "this is the first overload I wanna pick when resolving them".

[@logicaldistraction]

Are you telling me you added Lock instead of lock and it still does not support that I call my async methods via await keyword in there and I still have to use SemaphoreSlim? I wouldn't be proud of that and I really hope that I am wrong here...

[@dilanboskan2222]

These two fullfill fundamentally different usecases. How about you get into why it is not possible to use await inside a lock statement?

[@rich_in_paradise]

The lock statement and being able to treat every object as a lock was one of many things in C# 1.0 directly copied from Java. And it probably shouldn't have been because it never really made sense there either.

[@ugurarikan9492]

Such a nice feature but .. How come "allows ref struct" is not the default? Why would anyone want to box "T" as "IDisposable" inside a function which requires "T: IDisposable" as an argument, not a boxed "IDisposable"? What is the point? This choice of the default will lead to having "allows ref struct" repeated million times in the standard library. Next, library authors will have to add it everywhere.

[@jacobhuebert8298]

I would assume, that the decision was made to have it this way so that there isn't change in default functionality that would cause breaking changes. When your designing something for others to use, it's better to have them make all their updates when they choose to opt in, not force it upon them with default behavior changing unexpectedly. That's why they are so cautious with the new field keyword

[@mkwpaul]

if you allow ref structs on your type paramter, then you only can do things with instances of your generic type that are allowed for ref structs, i.e. no allocations of that type on the heap. If that were the default, 99% of existing generic methods and types would need to be annotated to not allow them. All common generic collections, nearly all LINQ methods all would need to specify that they don't allow it. And it wouldn't be much different for the code written by most .NET devs. It would also break nearly every existing .NET code base.

[@MaxiTB]

Too bad EE didn't make the cut, but I'm only half sad about it. Would have been need if we got the syntax with properties in the first iteration so that we can slowly phase out the old code and be future-ready. Yeah, I have to admit, I'm not a fan that the extension name is not optional in the syntax (in 99% you really don't care about the name of the class), but honestly a bit more verbosity for a clean syntax with a future first-class type inspires as much hope as an interface type constraint would do 🙂

[@evilsanta8585]

Are they even engineers if they’re not even using dark mode!

[@temp50]

I mean if you wanna see what is on the screen, you use the normal mode. If you wanna look like a hacker while don't have a clue what is happening in your code: you switch to dark mode. :)

[@EverRusting]

I initially agreed then I remembered that my most productive years were spent with light mode and Eclipse + Visual Studio around 2010 😩😩😩

[@PeterMatthews-j9x]

This is why private fields called "field" should be called "_field".

[@MaxiTB]

Yeah, the original style guide for C# requires m_ and s_ prefixes, personally I prefer an underscore by it's own as well, so people actually following best practices should have no issues at all.

[@anm3037]

With params Span as method parameter, yield does not work. Shameless

[@umutcelenli2219]

Please stop for 1-2 years. Projects can't keep up.

[@Guentieee]

No, please continue the great work. If you can't keep up that ok, none of these features break anything.

[@ryanmartin90]

It's okay, you can ignore it

[@MaxiTB]

The big features didn't arrive - all those improvements are perf related. In other words, you don't need to use them, you can still kill the environment with pollution by using excessive amounts of power with your long outdated code ;-)

[@Ayymoss]

It's all backwards compatible? Why would you dislike progress? Not only that, newer versions of .NET are faster, so upgrading without changing anything, should yield better performance (generally speaking). I can't think of any negatives to an annual STS, and biennial LTS release schedule.

[@modernkennnern]

There's barely anything in C# 13, so this ain't an issue anyways ^^