This seems to be just a syntax frontend for C++. The underlying semantics stay the same.
BTW, if you dropped C++ a decade ago, you should now look into the modern improvements (C++20).
That is very much not true. In fact the syntax simplification is of less interest to me than the clarification/simplification of semantics. Most of the dangerous / confusing parts of c++ come from the necessary c compatibility.
So for example, you don’t have to worry about the bug-inducing C integer promotion rules.
Fair. Still, the more recent C++ improvements tend to roll out slowly across the ecosystem and work environments.
1) malloc/new & free/delete are now solidly legacy territory of the "unless it's a placement `new`, you're likely doing it wrong". make_unique && make_shared all day long.
2) templates that are understandable by mortals thanks to `if constexpr` instead of SFINAE nightmares.
3) static_asserts
4) lambdas (which is going to get way more useful with https://en.cppreference.com/w/cpp/utility/functional/move_on... )
5) std::format
6) attributes like [[nodiscard]] being standard
7) std::move making passing std:vector & similar containers around not being terrifying (this is what also really helps #1 be possible)
I'm sure I missed some stuff, but I reach for all of those regularly.
2) in light of that your comment is unintentionally hilarious. C++ became a syntax swamp 15 years ago and it is getting worse every release. I anticipate it getting worse as rust, a hilarious syntax soup in its own right, continues to march forward.
This is awfully wrong. C++ might be convenient to express ownership and manage object lifetimes, but they are not the only way to express ownership by far.
Take for instance Qt, which relies heavily on new-ing up objects still up to this day, as it has its own ownership and object lifetime management system.
New/delete are still basically deprecated territory. Qt isn't any different here, other than it seems they are behind the curve with make() variants of their pointer containers. So you'd want to make your own of that, and then go back to the world of "new/delete are deprecated"
Move-only values are very used for common situations of unique resources that should not be duplicated.
But, what if you want to enclose a move-only value in a std::function? Are you simply out of luck and must give up on your dreams? A move-only function lets you get that work done.
- just the ability of doing
if constexpr(requires { T::some_member; }) { ... }
- coroutines finally enable to properly abstract the data structures used by a type's implementation, e.g. you don't need to spill out anymore that your type stores stuff in std::vector or std::array or boost::small_vector or std::list etc etc to client code, and they simplify async code very well. for instance with Qt: https://qcoro.dvratil.cz/reference/core/qprocess/#examples
- three-way comparison and automtic generation of comparison / equality function is really great for removing needless boilerplate
- void f(auto arg) { ... } instead of template<typename T> void f(T arg) { ... }
- foo{.designated = 123, .init = "456" }; (although it was already more or less supported on every relevant compiler for years
There is a way, but it's cursed:
C# is going the route of allowing required/optional fields in designated initializers, and from my point of view it is just a mess for what should be a constructor call.
C++ 20 gets a format feature that's basically a weaker {fmt} library but as part of the standard library. A string formatting feature with reasonable performance and safety as you might be used to from other modern languages.
Concepts is nice, that's basically way to express duck typing, it is often described like you're getting more than duck typing but that's all you actually get - but hey, duck typing is useful, and Concepts should have decent error messages whereas doing the equivalent with SFINAE is a recipe for awful diagnostic output.
In fact, C++ Concepts can be used for early enforcement of compile-time duck typing, just for better error messages. In the Standard library they are commonly used that way, for backward compatibility.
But Concepts can also implement named-property matching. It is entirely up to the designer of a library how much of each to present.
You have repeatedly (across numerous HN threads) insisted that Concepts aren't just duck typing but that doesn't make it so.
> But Concepts can also implement named-property matching.
That's still just duck typing (and it's awkward to do properly). Contrast with the (eventually abandoned) C++ 0x Concepts, which actually has semantic weight to it. Concept Maps allow C++ 0x Concepts to have some sort of chance in a language that's already in widespread use, because you can adapt an existing type to the Concept using a Map.
But C++ 20 Concepts doesn't offer any of that, after about a decade it's just duck typing.
Concepts are just the equivalent of if instanceof.