> memory_order::relaxed < cv_status::timeout is true
No it isn't. https://godbolt.org/z/bz7EhMhMT
Re:Swift is a more convenient Rust
by tialaramex on Friday September 06, 2024 @03:12PM
(#41468884)
I knew I should have checked that in Godbolt before posting it. You're correct, the types don't coerce and so this actually doesn't work.
Oh come on now, everyone who programs in C++ knows operators don't work like that. Operators are tied to types, those enums don't have operator < defined.
You also can't add them, or subtract them.
Yes behind the scenes their integers, but almost certainly this is the case in Rust too. You can SOMETIMES coerce an enum class instance back to an int if you do unsafe casts (on purpose).
Re:Swift is a more convenient Rust
by tialaramex on Friday September 06, 2024 @03:32PM
(#41469038)
Both those scoped enums do in fact have operator< but, as your sibling comment points out, they insist on type matching and so my example won't actually compile because it uses dissimilar types. The analogous Rust types implement only Eq not PartialOrd, so we can't make this error.
However whether you can add or subtract them is harder to guess than you seem to have assumed
https://godbolt.org/z/3vdazcr7E
Of course the bit pattern representation is the same in Rust. The point isn't the representation or we'd be talking about machine code. The point is the ergonomics.
These types aren't (shouldn't be) integers, but in C and C++ they are anyway.
Their notional status as "strict types" means nothing in a language which doesn't really care anyway, that's why memory_order::relaxed < cv_status::timeout is true
In Rust if you write nonsense like that it doesn't compile, these aren't comparable things. In C++ they're just integers, so of course you can see that relaxed (the integer zero) is less than timeout (the integer one) ...
They are just integers wearing funny hats.