I think Herb’s point is that the combination of: 1. his cpp2 feature of “automatically std::move the last use of each variable” together + 2. the fact that rvalues can’t be passed to functions that take “mutable reference” (and cpp2 inout/out) = mean that a “mutable reference” (and inout/out) parameters will act as “nodiscard” (and will have to be manually discarded via the assignment to _). I guess Herb likes it because he likes nodiscard, and he is happy that he “got it for free” as a consequence of 1+2 above

It’s honestly pretty infuriating how often this group completely misunderstands the articles they read.

Like how for about 5 mins in discussing cppfront’s explicit data flow (33:02), they speculate the purpose of discarding 'x' has something to do with optimizations. And then when they finally continue reading, they realize it’s just about data flow, then misread the article again and somehow hallucinate that the discard statement must be modifying the behaviour of the previous function call.

This has happened many times in past videos. Does the presenter read the articles they talk about beforehand? It seems like something they should review beforehand instead of just…​ Guessing, without reading, during their meetup.

Programming languages such as C and C++ are examples of memory unsafe programming languages that can lead to memory unsafe code and are still among the most widely used languages today.

Safer Language Subsets

The C++ community has been contemplating the balance between backwards compatibility, memory-safety defaults, and other priorities for the base language. There are multiple targeted efforts to make C and C++ less vulnerable for existing code bases and products. For example, Apple has modified the C compiler toolchain used in the iBoot system16 to mitigate memory and type safety issues. <…​> Microsoft has developed “Checked C” that “adds static and dynamic checking to C to detect or prevent common programming errors such as buffer overruns and out-of-bounds memory accesses.” There are more general efforts to improve C++ memory safety for existing code, including efforts like Carbon.

Well, they are not wrong to point the finger at C/C++. ↑

As Stroustrup said: C/C++ is a mythical language. I know C and C++ and you write those quite different. ↑

They’ve been saying this for almost 10 years now. Most security issues are not the result of malevolence - they’re the result of human error. I’ve seen some of the code that contractors have delivered. A lot of it was appallingly bad. It’s cheaper and safer for them to get people off of C/C++ than it is for them to try to clean up and secure dangerously bad code. ↑

C++ is getting more and more complex. The Committee keeps adding new features based on its consensus. Let’s remove features based on Reddit’s consensus.

Everyone agrees that C++ is broken, but no one agrees precisely which parts need fixing …​which just goes to show that the language isn’t broken at all. It just has a very wide user base with very diverse needs. One coder’s boondoggle is another coder’s bedrock.

Gotta love how nearly everything suggested in the replies (save for std::vector<bool>?) is followed by a reply saying how that feature is actually useful sometimes :) It’s too late for C++ now, at this point everyone uses it on their own particular way and every obscure or weird feature has found its place for someone 😄

The only thing wrong with C++ is other users of C++. ↑