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).
@Shamar int64_t is not allowed to overflow, so it is not a ring. If you rearrange/transform formulas according to rules of a ring you might break something that was carefully crafted to not overflow.
uint64_t however is a finite field.
Ring could be a useful concept (type requirement), but so many things can be rings that as a specific type it's meaningless.
@Shamar no wait, division breaks it, so unsigned integers aren't quite finite fields. Still rings I guess, better than nothing, but not sufficient for all use cases.
Assuming 2's complement ~(0LL) will be -1, and adding 1 will bring it back to 0, which is not a signed integer overflow (curiously this sequence of ~ +1 corresponds to negation in 2's complement).
Something like this would do it ~(1LL << 63) + 1, overflowing from maximum value to minimum.
This kind of overflow, from max to min (or back) is undefined behavior in C/C++ (the only languages that matter :P), which means if you do that your compiler may "optimize" your entire program away or do something else sinister. A more subtle side effect is that you're not allowed to negate the minimum value, as that produces a value that is one more than maximum, so even that simple unary operation is not safe. Historically this was to account for different implementations of signed integers, but it's maintained on latest standards as well, as such a type has proven to be useful for certain optimizations, in contexts where you can otherwise guarantee no overflow will occur.
Up until the latest standards you couldn't legally do 2's complement arithmetic in these languages. With the latest you can, but not directly, only by casting to unsigned type and then casting back.
That said, nobody but the nerdiest care about such things. Normal people most likely break the standards left and right in this regard, there are probably even compiler flags/settings to accommodate that.
The endianness and the sign bit are implementation details: the point of my insight (which could be wrong, btw) is that the working of fixed width integer types is that of a ring of bit sequences of such widyh, not that of N or Z (that's what people would expect from something called "integer").
This however is NOT a good objection: it takes 10 minutes to understand rings building on insight from primary school.
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.
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.
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)
Uhm.. I'm arguing that calling a bounded type as "int" is a design error.
Take Wirth's Oberon: it uses INTEGER. At compile time you can specify the actual size.
Yet, it's NOT really an integer because it's bounded.
So if it's not a integer why calling it so?
I'm a programmer. 😉
It's not an integer.
It's NOT a theoretical argument, indeed overflows happen.
There are three possible solutions to this: force people to rationalize that "it's not an integer, but... who cares?", making it an actual integer (whatever it costs computationally... but you know.. halting problem) or to name such in another way.
The first increase cognitive load for no reason: it's accidental complexity or, if you prefer, a global technical debt.
Another example: division should not be defined on types that include zero. You shouldn't be able to construct a type for which division is defined, with a zero.
But still... I think it's worth to imagine better worlds.
So why should we adopt such self-deception by calling something that is not an integer "integer" instead of building something that actually work as an integer?
Or maybe we think that programmers cannot properly handle rings (as they cannot handle overflow errors)?
I'd argue that such belief is a little "paternalist" and well... wrong.
So we know that people cannot properly handle such corner case... why not make their management mandatory from the start?
Full access to software sources and full right to hack it, just like writings and any other human expression, is the most fundamental human right.
Preventing such right to any human is preventing them to be human, a specie that defines itself as *homo sapiens sapiens*.
It's somewhat funny, but very incorrect.
Even MIT and BSD impose obligations on people builing on licensed code, just fewer than a #copyleft.
Actually, such swallow depiction of free software licenses is quite similar to calling int64_t as "integer". 😅
I must admit that I'm not yet happy with its formulation, but it can give an idea of what I hate in weaker copylefts like the #AGPLv3.
I'm going to remove the "organizations" thing. Making it shorter would be nice but apparently I can't without opening to corporate abuse one way or another.
In any case, if you want to give it a read and show me a way it could advantage big corps, I'll promise I'll study a fix for that.
BUT Google does not use or extend AGPL software. Why?
I'd argue that a strong copyleft is better than a permissive license against steer manpower.
And that against such big corporations not even keeping the software closed source provide an effective protection.
The Hacking License, instead, gives the original authors full (non exclusive) copyright and patent grants on any derived work.
Fine... but why?
I mean, is this a philosophical hate against common good and the commons or something you consider pragmatic, apolitical... such as profit in a capitalist world or something like that?
Even if we do not agree on this matter (mostly because we do not agree), I'd really like to learn your perspective.
QOTO: Question Others to Teach Ourselves. A STEM-oriented instance.
No hate, No censorship. Be kind, be respectful
We federate with all servers: we don't block any servers.