What's wrong with constexpr?
post
I don't get it. What's wrong with constexpr? It's vastly preferable to macros due to type safety, and const due to compile-time optimization.
I don't get it either. OP might be angry at compile time (Couldn't be worse than rust)
Rust doesn't allow type inference in function signatures, c++ does with auto. IIRC, they recommended against using it, because of -you guessed it- compile time.
TBH I thought it was for refactoring type safety. Making sure that the type is understood and not ready to just change wildly accidentally.
Not fair to compare it to the very immature Rust.
I do love rust. But I do like making fun of it too.
Although I don't see how rust is immature? Unless I missed the joke?
It's very young for a programming language, and is still rapidly evolving.
It's more than 10 years old. It has stable syntax, big standard library, big library ecosystem, plenty of rust programs already in production.
If by "evolving" you mean "changing", I don't think that is an issue at all. At most, they add features. They don't change or remove. And with the editions system, it should be no issue.
If by "evolving" you mean "improving", then I don't see how that could ever be an issue.
Wdym? They're so good they even got backported to C in C23
You know how often C gets big features like that? I mean to get auto they had to basically deprecate a keyword (well, sort of)
I much prefer
for (auto map : hashMaps) ...
over
for(unordered_map<string, unordered_set<string>> map : hashMaps)
though. Shame they didn't name it "var" like in many other languages, auto just reminds me of cars.
all 10 comments