What’s New in C++26 - Alexander Fokin 

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.

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..

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.

Why not have at this time now constexpr scopes and the rest being constexpr + keyword..

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, 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.

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++.

,,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).

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.

idk I'll take this over a stuffy presentation if they're gonna be so lax at adding critical features in general

Fokin Hell

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:)