Unpopular opinion: i64, int64_t, Int64 and similar types should be named according to their actual meaning, Ring64.
Even better, all programming languages should have a Ring[N] type that provides unit, zero addition and multiplication over a domain of N-bit strings, with the compiler applying proper optimizations when available (and requested).
It IS a ring on most implementations, but there were good flexibility (and portability) reasons behind all behaviours left undefined in C.
Yet this is a good objection... for standard C.
They are both right, btw.
Never trust non-GPL code... 🤣
You are technically right, but i think they SHOULD be rings (and named accordingly). So that programmers would learn from the beginning to live with the clear semantics of rings, always aware of the risk of overflow.
If you want rings, make them as separate types with different semantics.
Also also, if you deliberately write code assuming signed overflow is well defined, I'll personally find you and kick you in the nuts
Uhm... no. You are not "right".
You are technically right because you narrowed the discourse on standard C. Then, speaking of one specific language (standard C), you are right that int64_t is not a ring.
(And I do the worst possible things with computers... things you can't even imagine... so start looking if you dare to know... 😉).
But I'd argue that the Rust choice is... arguable.
I mean, it's a choice, legitimate for its authors. BUT calling the same time Ring64 AND giving it ring semantics would be an equivalent design choice.
The point: is it better as a bade type in a language, a limited integer that throw an exception in some conditions, or a ring that consistently works as a ring and let people build on top of its clear and predictable semantics?
I'd say the second.
It's a simpler solution, faster to learn and predictable.
(It's worth noticing that I'm wondering about an hypothetical language that is as simple and consistent as possible)
