Quite profound that features like Networking and Reflection have been in some languages since their inception, but it takes all the stars to align to get it into c++.
If the language was born with it its much easier, here you have billions of lines of code already existing and not a single owner that can just make bad decisions like python objects.
"You don't have to worry about what is not important. That is the beauty of C++. It lets you concentrate on what you consider important" -- ChatGPT with the 10/10 troll.
So if we're lucky, we can even have this cool new thing called networking, which enables computers to talk to each other, and that quite soon! Like in 5-6 years! This is just in time since this internet of networks seems to be taking off!
There are other languages that do networking quite well, use them, C++ shouldn't be in a hurry to be able to do everything, we will regret it otherwise
It's just despressing everytime when I look at newer and newer C++ standards. Sure there are some good ones like static reflection which makes life "slightly" better, but many things are just over-engineering, over-complex things with terrible syntax like corountine and match. I personally think that C++ peaked at C++ 17 or even C++11 and then went down hill since then.
cmon features like concepts(instead of SFINAE), variadic templates, std::optional(and C++23 monadic pattern matching) and modules are quite appealing. The main problem with C++ is backward compatibility, the language would benefit with major versions, just like Rust.
@A5A5A5A5h Some of the things are nice to have like variadic indexing and concepts. (variadic templates is C++11 and optional is C++17) Some other ones like pattern matching and modules literally makes c++ feel like another language. We should have focused on things that we don't have at all such as network, encryption, etc... or so bad that it got deprecated but don't have a replacement like proper text encoding (codecvt and wchar_t). We should have gone for those instead of keep adding new ways to do existing things just try to be a language with "modern" syntax.
@@A5A5A5A5h Like if I developed a new OS and were to implement C++ into it, I would be screwed. Not only do I need to handle C use case, but also handle all the different ways we can do for the same thing from c++03 to c++23.
@@Someone-jf3mb Unfortunately we will never get a complete standard library such as those of Python, Java or Rust. If something as trivial as pattern matching gets introduced only ~8 years(!) after std::optional then it’s quite unrealistic to expect something as complex as a network library. Anyway, I don’t know about you, but in my job I don’t see any brand new C++ project since 10 years at least. C++ is mainly used to support old projects that works well and cannot be replaced so easily. In these environments, having these “little” features(pattern matching, etc.) is indeed helpful to make the job less dreadful. I can’t think of a single reason of why anyone would choose C++ for new projects though. Nowadays you can use any GC language or Rust/C when performances are critical and avoid C++ completely. I don’t even know how a young programmer is supposed to learn all the legacy crap C++ has accumulated over the years.
C++11 was the best one ever. Today's incompetent fool committee will never come close again. They think we want even more fancy generic types? Clueless.
Oh yeah new features left for the implementors because the implementors know betters so the committee have less time discussion them, like that worked in the past, and we didn’t get different implementations for the same feature.
This looks like since c++11 to now we overengineering almost everything with no reasons actually in context of oop and starting realizing this is not programming.
It is great to see this progress and all, but it is remarkable how C++ is now established for 39 years only to become a worse version of Haskell. Adapting the "auto" keyword and pattern matching like this along with a crazy templating system is quite far away from the original selling points of high performance combined with "no magic". C and C++ used to be very transparent, albeit a bit cumbersome at times but I can not see the reason of shifting it more and more to a functional programming language when plenty of those exist already.
as i see it, c++ is no longer really meant to start something new in it, except the eco system is really really compelling. but for all people working on legacy systems it is great to have the ability to write concise code. making the program logic more difficult to follow in favour for a better intuition what the assembly looks like is a tradeoff that should at least not be decided on a language level. if you don't want to use match that is fine by me. I however feel this is a minority position.
I think C++ just wants to stay competitive with things like Rust which is as much inspired by ML-family languages as it is by C-family languages. It’s really nice to be able to use pattern matching and enums with associated data. It’s hard to explain if you haven’t spent time programming in this way because while it doesn’t add anything new that you couldn’t do before, it’s just often so much nicer for writing concise, obviously correct code for so many real problems. Rust also is showing that a combination of low level control and high level features is really appealing for shipping high quality, high performance code quickly. A lot of code in most systems can afford to be less efficient if it means it’s done yesterday, it’s correct, it’s easy to maintain, and it’s easy to optimize when needed. C++ is already a language where your team has to pick a subset of the language if you want high quality code so I think we’re long past the point of complaining about feature creep: C++ is going to get every new feature.
" I can not see the reason of shifting it more and more to a functional programming language when plenty of those exist already." I don't see how these two points conflict - these are different languages with different toolchains, codebases, communities, domains of use etc.
while newer languages adopted some version of a package management system, it feels kinda strange to see c++ having a committee spending years deciding on incorporating some api into the standard for various areas
Yep it also feels weird that stuff is added to the standard which isn’t something everyone will need. Like how often do i do network requests on a microcontroller..
Reflection is really going to happen? They are probably going to blunder it to the point where you can't even make serialization layers, the trivial case of needing reflection.
Probably. IDEs already provide the values of constexpr variables to the user, even when that requires executing immediate functions on the fly behind the scenes. I imagine integrating reflected type information into auto-complete would be similar.
How does that stuff forced upon code work when i have to recompile the library anyways? Like it will probably require me to fix stuff of the past just because i use newer versions. This nodiscard stuff sounds bad.
16:37 It is interesting that they take this example to "promote" pattern matching. To me it seems much more direct to introduce something like "switch constexpr" into the language instead.
The fact we won't get pattern matching in C++26 is f####g infuriating. It would be so much better than some of this random stuff (like "is_debugger_present" - I mean holy cow, it's so simple for people to implement for themselves)
Well, sometimes I get very angry too, but going to the committee meetings and seeing how things work for yourself makes you really appreciate all the effort that goes into making C++ better. Not that many people are working on the language, and a lot of them are doing it in their spare time. For some of the features that's been in the works since forever it's simply a problem of a lack of people willing to dedicate weeks (or months) of their time to see the proposal through.
@@ElricD Last time I checked though, the proposal for Pattern matching was written in like 2017 and was done and came a long way until Herb Sutter had to let his pattern matching proposal in, making it now two different variants and because Herb Sutter is Herb Sutter, his proposal slowed things down substantially? That's what I got from it at least - it's not that I was trying to be derogatory about the community, but this particular issue seems to be struggling for above reasons. I find it a bit ironic that he also had a long 2 hr talk about bifurcation. Hopefully I misunderstood it though, but that's how it came across when reading and watching a lot of CppCon talks and seeing how 2026 is optimistic for one of the, if not the biggest quality of life feature, by far to ever hit c++, it being further delayed would be incredibly depressing.
56:11 This is not correct answer, `typename` have there very specific role here as array could use `^0` and reflection on value not type. Like `[: e :] * t;` this is value declaration or multiplication? C++ need to know this, and way to inform C++ is to use `typename`, `namespace` or couple of similar keyword to "force" correct syntax kind here.
My thoughts exactly. It's Q3 2024 and if I'm not mistaken I can't even use a lot of C++23 features yet. Just makes you care less and less about new or future language or library features if you cannot use them.
This isn't a problem really and this has been discussed in the committee on a couple occassions, e.g. when we were looking at standardizing boost.dll. You can also take a look at freestanding C++.
Well there is a ugly thing in match with doing e match one does a look ahead for no reason. Could we do match e to make it more similar to switch ? Even more ugly runtime performance is unpredictable great, well you know in C i would have done a switch over type id’s but guess this wasn’t something possible to think about.. Well here is a idea doing “match with { : { do something }; : { do something }; }”
1:01:44 Can we define_class without declaring the storage structure first? E.g. to inherit from it immediately? You mentioned that the API is not settled but maybe it was discussed somewhere?
This is a complex topic and I'm not the author of this proposal. My limited understanding of the issue is that if you let define_class create definitions w/o an existing forward declaration, then you'll need to pass in a reflection of scope where it'll be declared (a class or a namespace), and then there is a question of when this declaration actually becomes visible. Injecting new names into a scope while the compiler is processing some other scope doesn't look like a good idea.
@@ElricD Yes I guess it makes sense. But then again, it could act the same way anonymous structs act now... but yes, I guess, it's probably easier to just forward declare these things than have the committee discuss just this for another year and come to the solution that some people are going to be mad about anyway
Well already not a fan of anything that throws as i don’t throw. The invention of it as basically because multiple returns where not possible and that’s sort of a terrible excuse. + Throw is like i threw it away dunno what happens with it.
C++ is becoming incomprehensible and unlearnable. All that safety and stuff is nice but impossible to be learned and correctly used by a regular programmer. C++ has become a language for a very small niche of IQ 180+ genie. After some 10+ years of professional use of C++ I still feel I am not one of them. I just like simplicity in my life... I start to feel C++ is not a language for me. :(
Where are the standard package manager, standard build system, standard networking, standard linter, standard formatter, standard testing, ... c++ progress sucks
Lol. Trying to do what D did simply 20 years ago. The half of the other stuff is just library nonsense, which should not be a part of a language. This is just more ugly C++. I get it fits
1. let bindings and pattern matching were a thing in various languages long before rust existed 2. what do you even mean "steal"? These are features in programming languages, that's like saying a hammer stole it's handle design from an axe, the only sad thing here is that you're making up fake rivalries between programming languages in your head
Quite profound that features like Networking and Reflection have been in some languages since their inception, but it takes all the stars to align to get it into c++.
If the language was born with it its much easier, here you have billions of lines of code already existing and not a single owner that can just make bad decisions like python objects.
"You don't have to worry about what is not important. That is the beauty of C++. It lets you concentrate on what you consider important" -- ChatGPT with the 10/10 troll.
So if we're lucky, we can even have this cool new thing called networking, which enables computers to talk to each other, and that quite soon! Like in 5-6 years!
This is just in time since this internet of networks seems to be taking off!
There are other languages that do networking quite well, use them, C++ shouldn't be in a hurry to be able to do everything, we will regret it otherwise
@@Megalcristo2 Yeah, we should tackle it when this Internet of networks proves to be more than a fad!
It's just despressing everytime when I look at newer and newer C++ standards. Sure there are some good ones like static reflection which makes life "slightly" better, but many things are just over-engineering, over-complex things with terrible syntax like corountine and match.
I personally think that C++ peaked at C++ 17 or even C++11 and then went down hill since then.
cmon features like concepts(instead of SFINAE), variadic templates, std::optional(and C++23 monadic pattern matching) and modules are quite appealing.
The main problem with C++ is backward compatibility, the language would benefit with major versions, just like Rust.
@A5A5A5A5h Some of the things are nice to have like variadic indexing and concepts. (variadic templates is C++11 and optional is C++17)
Some other ones like pattern matching and modules literally makes c++ feel like another language. We should have focused on things that we don't have at all such as network, encryption, etc... or so bad that it got deprecated but don't have a replacement like proper text encoding (codecvt and wchar_t).
We should have gone for those instead of keep adding new ways to do existing things just try to be a language with "modern" syntax.
@@A5A5A5A5h Like if I developed a new OS and were to implement C++ into it, I would be screwed. Not only do I need to handle C use case, but also handle all the different ways we can do for the same thing from c++03 to c++23.
@@Someone-jf3mb Unfortunately we will never get a complete standard library such as those of Python, Java or Rust. If something as trivial as pattern matching gets introduced only ~8 years(!) after std::optional then it’s quite unrealistic to expect something as complex as a network library.
Anyway, I don’t know about you, but in my job I don’t see any brand new C++ project since 10 years at least. C++ is mainly used to support old projects that works well and cannot be replaced so easily. In these environments, having these “little” features(pattern matching, etc.) is indeed helpful to make the job less dreadful. I can’t think of a single reason of why anyone would choose C++ for new projects though. Nowadays you can use any GC language or Rust/C when performances are critical and avoid C++ completely. I don’t even know how a young programmer is supposed to learn all the legacy crap C++ has accumulated over the years.
C++11 was the best one ever. Today's incompetent fool committee will never come close again. They think we want even more fancy generic types? Clueless.
Oh yeah new features left for the implementors because the implementors know betters so the committee have less time discussion them, like that worked in the past, and we didn’t get different implementations for the same feature.
This looks like since c++11 to now we overengineering almost everything with no reasons actually in context of oop and starting realizing this is not programming.
It is great to see this progress and all, but it is remarkable how C++ is now established for 39 years only to become a worse version of Haskell. Adapting the "auto" keyword and pattern matching like this along with a crazy templating system is quite far away from the original selling points of high performance combined with "no magic". C and C++ used to be very transparent, albeit a bit cumbersome at times but I can not see the reason of shifting it more and more to a functional programming language when plenty of those exist already.
,,Any sufficiently complicated C++2x standard contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Haskell"
Eh?
as i see it, c++ is no longer really meant to start something new in it, except the eco system is really really compelling. but for all people working on legacy systems it is great to have the ability to write concise code.
making the program logic more difficult to follow in favour for a better intuition what the assembly looks like is a tradeoff that should at least not be decided on a language level. if you don't want to use match that is fine by me. I however feel this is a minority position.
I think C++ just wants to stay competitive with things like Rust which is as much inspired by ML-family languages as it is by C-family languages. It’s really nice to be able to use pattern matching and enums with associated data.
It’s hard to explain if you haven’t spent time programming in this way because while it doesn’t add anything new that you couldn’t do before, it’s just often so much nicer for writing concise, obviously correct code for so many real problems.
Rust also is showing that a combination of low level control and high level features is really appealing for shipping high quality, high performance code quickly. A lot of code in most systems can afford to be less efficient if it means it’s done yesterday, it’s correct, it’s easy to maintain, and it’s easy to optimize when needed.
C++ is already a language where your team has to pick a subset of the language if you want high quality code so I think we’re long past the point of complaining about feature creep: C++ is going to get every new feature.
" I can not see the reason of shifting it more and more to a functional programming language when plenty of those exist already."
I don't see how these two points conflict - these are different languages with different toolchains, codebases, communities, domains of use etc.
@@ilikeshiba you might wanna check out Lean 4 (not for the theorem proving aspects but for general programming).
Since when does data layout in memory not matter anymore?
C++20/23 is already awesome. Can't wait for reflection in C++26.
All programming languages starting to converge to be FPOOP.
The love child of functional and object oriented programming.
Come on we know nothing will be perfect until it's Dreamberd
@@user-pe7gf9rv4m Don't forget to use the word 'DreamBerd' in your code!
"fucking poop"
OCaml is already doing this for a long time.
while newer languages adopted some version of a package management system, it feels kinda strange to see c++ having a committee spending years deciding on incorporating some api into the standard for various areas
Yep it also feels weird that stuff is added to the standard which isn’t something everyone will need. Like how often do i do network requests on a microcontroller..
@@platin2148yooo you can do that in the standard ? What’s the syntax
Reflection is really going to happen? They are probably going to blunder it to the point where you can't even make serialization layers, the trivial case of needing reflection.
Will IDEs be smart enough to know the subtype of std::meta::info? Sounds like a pain if illegal operations show up as options.
In my opinion this is very unlikely. It's hard to do, and it's too niche of a use case.
Probably. IDEs already provide the values of constexpr variables to the user, even when that requires executing immediate functions on the fly behind the scenes. I imagine integrating reflected type information into auto-complete would be similar.
it's just bikeshedding, but I prefer they used "for constexpr" intead of "template for", at least it would be consistent with "if constexpr".
Why not have at this time now constexpr scopes and the rest being constexpr + keyword..
In D we just use `static for` or `static foreach`.
How does that stuff forced upon code work when i have to recompile the library anyways? Like it will probably require me to fix stuff of the past just because i use newer versions. This nodiscard stuff sounds bad.
16:37 It is interesting that they take this example to "promote" pattern matching. To me it seems much more direct to introduce something like "switch constexpr" into the language instead.
The fact we won't get pattern matching in C++26 is f####g infuriating. It would be so much better than some of this random stuff (like "is_debugger_present" - I mean holy cow, it's so simple for people to implement for themselves)
Well, sometimes I get very angry too, but going to the committee meetings and seeing how things work for yourself makes you really appreciate all the effort that goes into making C++ better.
Not that many people are working on the language, and a lot of them are doing it in their spare time. For some of the features that's been in the works since forever it's simply a problem of a lack of people willing to dedicate weeks (or months) of their time to see the proposal through.
@@ElricD Last time I checked though, the proposal for Pattern matching was written in like 2017 and was done and came a long way until Herb Sutter had to let his pattern matching proposal in, making it now two different variants and because Herb Sutter is Herb Sutter, his proposal slowed things down substantially?
That's what I got from it at least - it's not that I was trying to be derogatory about the community, but this particular issue seems to be struggling for above reasons.
I find it a bit ironic that he also had a long 2 hr talk about bifurcation. Hopefully I misunderstood it though, but that's how it came across when reading and watching a lot of CppCon talks and seeing how 2026 is optimistic for one of the, if not the biggest quality of life feature, by far to ever hit c++, it being further delayed would be incredibly depressing.
Wait we have let now ? are we trying todo full java script now? I suspect there shall be a new syntax proposed for the entire language.
56:11 This is not correct answer, `typename` have there very specific role here as array could use `^0` and reflection on value not type.
Like `[: e :] * t;` this is value declaration or multiplication? C++ need to know this, and way to inform C++ is to use `typename`, `namespace` or couple of similar keyword to "force" correct syntax kind here.
they gonna implement this in 2045
My thoughts exactly. It's Q3 2024 and if I'm not mistaken I can't even use a lot of C++23 features yet. Just makes you care less and less about new or future language or library features if you cannot use them.
Well Networking in the standard? How do we deal with that on devices that don’t have it? I think that’s a bit much to ask.
This isn't a problem really and this has been discussed in the committee on a couple occassions, e.g. when we were looking at standardizing boost.dll. You can also take a look at freestanding C++.
Well there is a ugly thing in match with doing e match one does a look ahead for no reason. Could we do match e to make it more similar to switch ? Even more ugly runtime performance is unpredictable great, well you know in C i would have done a switch over type id’s but guess this wasn’t something possible to think about..
Well here is a idea doing “match with { : { do something }; : { do something }; }”
Welp to simply state it: “Any sufficiently advanced programming language will have security issues at one point in time”
[[nodiscard]] in the standard is just bad. It should be the f-ing default.
We did it guys, we're regressing!
1:01:44 Can we define_class without declaring the storage structure first? E.g. to inherit from it immediately? You mentioned that the API is not settled but maybe it was discussed somewhere?
This is a complex topic and I'm not the author of this proposal. My limited understanding of the issue is that if you let define_class create definitions w/o an existing forward declaration, then you'll need to pass in a reflection of scope where it'll be declared (a class or a namespace), and then there is a question of when this declaration actually becomes visible. Injecting new names into a scope while the compiler is processing some other scope doesn't look like a good idea.
@@ElricD Yes I guess it makes sense. But then again, it could act the same way anonymous structs act now... but yes, I guess, it's probably easier to just forward declare these things than have the committee discuss just this for another year and come to the solution that some people are going to be mad about anyway
Well already not a fan of anything that throws as i don’t throw. The invention of it as basically because multiple returns where not possible and that’s sort of a terrible excuse. + Throw is like i threw it away dunno what happens with it.
C++ is becoming incomprehensible and unlearnable. All that safety and stuff is nice but impossible to be learned and correctly used by a regular programmer. C++ has become a language for a very small niche of IQ 180+ genie. After some 10+ years of professional use of C++ I still feel I am not one of them. I just like simplicity in my life... I start to feel C++ is not a language for me. :(
You dont have to use all the newest features…
exactly what we need!
Where are the standard package manager, standard build system, standard networking, standard linter, standard formatter, standard testing, ... c++ progress sucks
who allowed slide at 30:00 to happen?
idk I'll take this over a stuffy presentation if they're gonna be so lax at adding critical features in general
I Fokin hate c++
This guy is Fokin
all this just to implement javascript
it's not just about regular safety issues C++ had, curious how many backdoors FSB has already built-in there? shall we give it better name Ц++ ?
yoo thats sick we get a match statement and reflection? finally something that people want and not more useless crap
Lol. Trying to do what D did simply 20 years ago.
The half of the other stuff is just library nonsense, which should not be a part of a language.
This is just more ugly C++. I get it fits
RIP C++
alexander what?...
Java ❤
wow. mad resp
You Fokin wot mate????
Fokin Hell
????26???
They steal both let and match from rust... so sad.
No
1. let bindings and pattern matching were a thing in various languages long before rust existed
2. what do you even mean "steal"? These are features in programming languages, that's like saying a hammer stole it's handle design from an axe, the only sad thing here is that you're making up fake rivalries between programming languages in your head
Chill, please, its a joke:)
It's pronounced two-ple. People can't read anymore. It's not spelled "tupple", right? Can you spell supple? Geez.