I could have written it as x = bit_cast<bool>(char{2}), but does it really make a difference?
I don't know enough rust to know what's the difference between its const and c++ constexpr. It might not be a meaningful difference in C++.
> So this is an impedance mismatch, you've got Roman numerals and you can't see why metric units are a good idea, and I've got the positional notation and so it's obvious to me. I am not going to be able to explain why this is a good idea in your notation, the brilliance vanishes during translation.
There are plenty of rust users on HN that are capable of kind, constructive, and technically interesting conversations. Unfortunately there are a small few that will destroy any goodwill the rest of the community works hard to generate.
Not really, that's also a variable. We're running into concrete differences here, which is what I was gesturing at. In C++ you've got two different things, one old and one new, and the new one does some transmutations (and is usually constexpr) while the old one does others but isn't constexpr. It's not correct to say that reinterpret_cast isn't a transmutation, for example it's the recognised way to do the "I want either a pointer or an integer of the same size" trick in C++ which is exactly that. Let me briefly explain, as much to ensure it's clear in my head as yours:
In C++ we have an integer but sometimes we're hiding a pointer in there using reinterpret_cast, in Rust we have a pointer but sometimes we're hiding an integer in there using transmute [actually core::ptr::without_provenance but that's just a transmute with a safe API]. Of course the machine code emitted is identical, because types evaporate at compile time the CPU doesn't care whether this value in a register "is" a pointer or not.
Anyway, yes the issues are the same because ultimately the machines are the same, but it's not true that C++ solved these issues the only way they could be addressed, better is possible. And in fact it would surely be a disappointment if we couldn't do any better decades later. I hope that in twenty years the Rust successor is as much better.
I don't know a way to express actual constants in C++ either. If there isn't one yet maybe C++ 29 can introduce a stuttering type qualifier co_co_const to signify that they really mean constant this time. Because constexpr is a way to get an immutable variable (with guaranteed compile time initialization and some other constraints) and in C++ we're allowed to "cast away" the immutability, we can actually just modify that variable, something like this: https://cpp.godbolt.org/z/EYnWET8sT
In contrast it doesn't mean anything to modify a constant in either language, it's not a surprise that 5 += 2 doesn't compile and so likewise Rust's core::f32::consts::PI *= 2; won't compile, and if we made our own constants we can't change those either. We can write expressions where we call into existence a temporary with our constant value, and then we mutate the temporary, but the constant itself is of course unaffected if we do this.
This can be a perf footgun, you will see newcomers write Rust where they've got a huge constant (e.g a table of 1000 32-bit floating point numbers) and they write code which just indexes into the constant in various parts of their program, if the index values are known at compile time this just optimises to the relevant 32-bit floating point number, because duh, but if they aren't it's going to shove that entire table on your stack everywhere you do this, and that's almost certainly not what you intended. It's similar to how newcomers might accidentally incur copies they didn't mean in C++ because they forgot a reference.
I'm afraid that just C++ being C++ and you are deep into UB; you can't really modify a constexpr value at runtime, and if you cast away its constness with what is effectively a const cast you are on your own. This will print "0 3" which is obviously nonsense:
constexpr int x = 3;
((int&)x) = 0;
char y[x];
std::print("{}, {}",x, sizeof(y));
You can also move the problematic sequence into a constexpr function and invoke it in a constexpr context: the compiler will reject the cast now.
Enum constants can't become lvalues, so the following also won't compile:
enum : int { x = 3};
((int&)x) = 0;
FWIW, notoriously you could modify numeric literals in early Fortrans and get into similar nonsense UB.
edit: in the end[1] it seems that you take exception with constexpr not being prvalues in C++. I guess it was found more convenient for them to have an address [1]. That doesn't make them less constant.
[1] or at least I think you do, it is not clear to me what you have been trying to claim in this discussion.
[2] C++ will materialize prvalues into temporaries when their address is needed (and give them an unique address), I guess it was thought to be wasteful for large constexpr objects, and avoids the rust pitfall you mentioned.
Of course, but the reason to even do this is only to illustrate that it's just another variable, nothing more. As much for myself as for you.
I've heard the stories about older languages but I assume that's not a thing on a modern Fortran and I'm sure we agree it's a bad idea.
The main thrust of this sub-thread was that languages can, and I believe Rust did, choose to solve the same issues but in a better way and so "This is too complicated in C++" doesn't translate to "It will be too complicated in every language". I think some C++ people have a version of the "End of History" nonsense, which is a nineteenth century idea. If you think noteworthy change happened after that and so history didn't end then hopefully you agree that makes no sense for general world history, and perhaps you can agree likewise C++ isn't the final apex of programming languages.
const SOUP: [f32; 1000] = [ /* whatever */ ];
let foo = something(blah_blah, blah) * SOUP[4];
// The optimiser will see that SOUP[4] is exactly say 1.5_f32 so it'll just do
// the same as if we'd calculated something(blah_blah, blah) * 1.5_f32
let foo = something(blah_blah, blah) * SOUP[blah];
let tmp = SOUP;
let foo = something(blah_blah, blah) * tmp[blah];
Now if you know what you're doing you would of course have one single place in your program where you do this:
static SOUP: [f32; 1000] = [ /* whatever */ ];
"Sufficiently smart compilers" are a very gradual miracle. In theory a compiler could realise this is a good idea, in practice today I doubt you will find such a compiler, so just write explicitly that you want a single variable if that's what you want.