Awesome new features! I will certainly be using all those right away! Allocation free `params`? Property declarations without having to worry about the backing field, once and for all? Extension types? Damn, this is huge! Well done, guys!
I'm surprised the audience didn't give a standing ovation for that one. I don't like adding crippled features so they don't break 0.002% of old code that could just not upgrade.
Do you know what's not great, saying we should var everywhere were it's possible for readability purposes...then few years down the line waking up choosing violence saying you're thinking of changing how var works.
Incredible features! Yes, PLEASE break things to make the language better! I rather have some (fixable) breaks, than having to re-adjust to legacy code all the time.
Excellent! Thanks guys. Love the excitement you have for the framework. One of us! I just wish JSON was a first class type safe dynamic/dictionary type thing that runs off schemas/annotations so all this stuff just happens.
Extension types as wrappers are an amazing concept. I will use those a lot in my libraries. For example, adding a position property to a string, to turn it into a cheaper string reader, instead of creating a new StringReader just for position tracking. I'm very curious to know where and how are the extension property values stored. Maybe weak references? Or, are extension properties read-only only?
I wish we will eventually be able to implement an interface "for" a sealed type or a value type, and use that implementation in generic context without additional overhead.
Implicit extension class syntax: we've now come full circle. The concept of "class helpers" was first created in Delphi. C# copied the idea, but not the syntax, and built upon it to make extension methods. And now for "extension everything" they're creating something that looks remarkably like the Delphi class helper syntax! 🤣
Is there anything I have to switch to enable extensions? I have latest VS Preview and .NET 9 Preview 4 but for some reason compiler doesn't recognize this feature.
So we have other features that complicate the answer to the question of which approach is IDIOMATIC. I can already see the endless and useless discussions with other seniors about which of the possible solutions to the problem most of them like. Let's just call it C#++
33:10 The feature is great but this is a bad use case. And it's funny to see how they're overhyped by it :D Parsing, typing and browsing json objects is already trivial using simple classes. It's the wrapper thing, kind of "soft inheritance" that is interesting. Unfortunately they failed to provide a compelling example...
The "field" does not bring anything, since the #1 reason to access the backing field is to do stuff like Interlocked.Increment or Exchange in a Method that is not the property accessor.
I don't know if that's really the #1 reason to use a backing field but it's definitely not the only one. A popular case where this will be very useful is to trigger an event when the property is set in an MVVM context, e.g. INotifyPropertyChanged in WPF.
Surely the metaphor we are using is paper, and as such it shouldn't be a super bright white, I prefer light mode, and I shouldn't have to lower the brightness of the monitor not to be blinded. I should be able to get nice bright sunshine in videos and vibrant computer games without having to lower it to not be blinded, so the white chosen for the editor should be the brightness of paper, rather than a blinding light.
According to the StackOverflow 2023 developer survey, C# is the 8th most popular language with ~27% of all developers having done extensive work in it in the past year. So yes.
So glad i left for golang, more nonsense in c#, now we have 2 ways of doing the thing that we already used to be able to do anyway. Also for the love of god, don't change var at all, you will break the internet.
There will be no code in the future. You will describe your problem with natural language and AI will create a computer code (mixed with assembly language)
Awesome new features! I will certainly be using all those right away!
Allocation free `params`? Property declarations without having to worry about the backing field, once and for all? Extension types? Damn, this is huge! Well done, guys!
That example with extension types with Json is so great! Really show how amazing is this feature.
Giving compiler warnings and hints when the language is added upon is great. Imo, not particularly disruptive and the language as a whole will benefit
I'm surprised the audience didn't give a standing ovation for that one.
I don't like adding crippled features so they don't break 0.002% of old code that could just not upgrade.
@@computer9764 They've done this several times before, people always like it
Do you know what's not great, saying we should var everywhere were it's possible for readability purposes...then few years down the line waking up choosing violence saying you're thinking of changing how var works.
@@justanaveragebalkan What are you talking about?
Incredible features! Yes, PLEASE break things to make the language better! I rather have some (fixable) breaks, than having to re-adjust to legacy code all the time.
Excited about Extensions 😍😍😍😍😍😍 and what a nifty side effect to use explicit extensions instead of using aliases. 👏👏👏👏
Wow! Finally got extension types! Exciting stuff!
He just casually throws in the possibility of extension operators in a future version near the end! What a tease!
You couldn't have picked better features for this next C# version. Very happy with what i am seeing here. Keep up the great work! :)
Excellent! Thanks guys. Love the excitement you have for the framework. One of us!
I just wish JSON was a first class type safe dynamic/dictionary type thing that runs off schemas/annotations so all this stuff just happens.
I should have attended this one while I was there and asked them about union types! ;D
you want to start an unending argument
Man I've been following extension everything for like 6 years now, since C# 8. Finally its getting added!
Extension types as wrappers are an amazing concept. I will use those a lot in my libraries. For example, adding a position property to a string, to turn it into a cheaper string reader, instead of creating a new StringReader just for position tracking. I'm very curious to know where and how are the extension property values stored. Maybe weak references? Or, are extension properties read-only only?
Those extensions seem very awesome!
I wish we will eventually be able to implement an interface "for" a sealed type or a value type, and use that implementation in generic context without additional overhead.
Yes, something like "implicit extension FooString for string : IFoo" would be awesome
Love this. Extension everything!
I really love the new Extensions
Breaking changes are ok!
I really hope this new Extensions implementation gets into the release.
Implicit extension class syntax: we've now come full circle. The concept of "class helpers" was first created in Delphi. C# copied the idea, but not the syntax, and built upon it to make extension methods. And now for "extension everything" they're creating something that looks remarkably like the Delphi class helper syntax! 🤣
Why does the *field* keyword not make auto fields *readonly* by default?
C# is *S* tier language
I just love these two presenters.
The breaking change caused by the field keyword is very minor. The benefit greatly outweighs the inconvenience.
Microsoft: breaks legacy code
me: wait, that's illegal
Would BE intresting to see that Windows IS written ENTIRELY in c#
Is there anything I have to switch to enable extensions? I have latest VS Preview and .NET 9 Preview 4 but for some reason compiler doesn't recognize this feature.
its not available in preview iirc
This feature isn't included in the latest preview (17.11.0 Preview 1.0)
They mentioned at the beginning of introducing the feature that they were using a version of Roslyn built from an open PR. It's not available yet.
Can I have a file scoped explicit extension to use as a using alias only in this file?
Sounds like normal private methods with extra sugar.
But that might be nice and relatively easy to bolt on!
If i extend multiple types with the same extension name how does it resolve in the caller?
Will it work kinda like a rust trait or will it be an error
Just thought it reminds me a bit of how Rust traits work
I imagine it will follow the normal type resolution rules - just like if you declare multiple types with the same name
By the way, is the explicit extension on 'object' an implementation of a 'shape' concept?
The killer app for me would be using an extension to add an interface to the class for testing with IoC and avoid writing a wrapper
DU's in C# is the ONLY major feature I'm still waiting for 🙃
Can we have extension for dynamic 🤔
Just do an extension for object, dynamic is nothing more than the object type with an added attribute 😊
very powerfull feature
So we have other features that complicate the answer to the question of which approach is IDIOMATIC. I can already see the endless and useless discussions with other seniors about which of the possible solutions to the problem most of them like.
Let's just call it C#++
Partial properties tho? 😢
I'm going to put @ in front of ALL of my variable names. You never exactly know...
Love that floral shirt
33:10 The feature is great but this is a bad use case. And it's funny to see how they're overhyped by it :D Parsing, typing and browsing json objects is already trivial using simple classes. It's the wrapper thing, kind of "soft inheritance" that is interesting. Unfortunately they failed to provide a compelling example...
🥰
hello saars i am devloper
Is it only me, or the extension syntax looks awfully like traits?
His shirt design is created by co-pilot
C# > java, any time of day ;-)
stop it! stop oppressing java people by having all the fun stuff!
boring is good. programming languages SHOULD be boring.
The "field" does not bring anything, since the #1 reason to access the backing field is to do stuff like Interlocked.Increment or Exchange in a Method that is not the property accessor.
I don't know if that's really the #1 reason to use a backing field but it's definitely not the only one. A popular case where this will be very useful is to trigger an event when the property is set in an MVVM context, e.g. INotifyPropertyChanged in WPF.
As hyped as i am, its absolute barbarism to use light mode in visual studio in 2024.
It is not.
Agree, but I kinda feel it works better with light mode when presenting.
Surely the metaphor we are using is paper, and as such it shouldn't be a super bright white, I prefer light mode, and I shouldn't have to lower the brightness of the monitor not to be blinded. I should be able to get nice bright sunshine in videos and vibrant computer games without having to lower it to not be blinded, so the white chosen for the editor should be the brightness of paper, rather than a blinding light.
We will collect your data more secretly and faster
Does anyone actually still use C#?
Do you use c# at work?
According to the StackOverflow 2023 developer survey, C# is the 8th most popular language with ~27% of all developers having done extensive work in it in the past year. So yes.
yes
Still my favourite language I can actually use at work
@@markusTegelane I think the job market for C# is good.
Please remove the linebreak before first {. Much more readable and see more.
So glad i left for golang, more nonsense in c#, now we have 2 ways of doing the thing that we already used to be able to do anyway. Also for the love of god, don't change var at all, you will break the internet.
There will be no code in the future.
You will describe your problem with natural language and AI will create a computer code (mixed with assembly language)
> i have this problem, AI is stealing my job, can you solve that for me?
> sure! i will write a simple code to delete every AI ever in the world
Isn't that code though? The language is no longer C# but English. You are still defining your problem, its operations etc but using English.
Natural language is too ambiguous.
@@LettersAndNumbers300 The IT language of the world is Sanskrit
@@jackwhitestripe7342 got examples?