← Back to context Comment by xigoi 6 hours ago If you need wraparound, you should not use signed integers anyway, as that leads to undefined behavior. 9 comments xigoi Reply ratmice 6 hours ago Presumably since this language isn't C they can define it however they want to, for instance in rust std::i32::MIN.wrapping_sub(1) is a perfectly valid number. xigoi 6 hours ago Nim (the original one, not Nimony) compiles to C, so making basic types work differently from C would involve major performance costs. beagle3 3 minutes ago And yet, Nim does overflow checking by default. umanwizard 6 hours ago Signed overflow being UB (while unsigned is defined to wrap) is a quirk of C and C++ specifically, not some fundamental property of computing. xigoi 6 hours ago Nim (the original one, not Nimony) compiles to C, so making basic types work differently from C would involve major performance costs. ratmice 5 hours ago Presumably unsigned want to return errors too?Edit: I guess they could get rid of a few numbers... Anyhow it isn't a philosophy that is going to get me to consider nimony for anything. umanwizard 5 hours ago > making basic types work differently from C would involve major performance costs.Not if you compile with optimizations on. This C code: int wrapping_add_ints(int x, int y) { return (int)((unsigned)x + (unsigned)y); } Compiles to this x86-64 assembly (with clang -O2): wrapping_add_ints: lea eax, [rdi + rsi] ret Which, for those who aren't familiar with x86 assembly, is just the normal instruction for adding two numbers with wrapping semantics. Symmetry 5 hours ago Specifically, C comes form a world where allowing for machines that didn't use 2's compliment (or 8 bit bytes) was an active concern. aw1621107 4 hours ago Interestingly, C23 and C++20 standardized 2's complement representation for signed integers but kept UB on signed overflow.
ratmice 6 hours ago Presumably since this language isn't C they can define it however they want to, for instance in rust std::i32::MIN.wrapping_sub(1) is a perfectly valid number. xigoi 6 hours ago Nim (the original one, not Nimony) compiles to C, so making basic types work differently from C would involve major performance costs. beagle3 3 minutes ago And yet, Nim does overflow checking by default.
xigoi 6 hours ago Nim (the original one, not Nimony) compiles to C, so making basic types work differently from C would involve major performance costs. beagle3 3 minutes ago And yet, Nim does overflow checking by default.
umanwizard 6 hours ago Signed overflow being UB (while unsigned is defined to wrap) is a quirk of C and C++ specifically, not some fundamental property of computing. xigoi 6 hours ago Nim (the original one, not Nimony) compiles to C, so making basic types work differently from C would involve major performance costs. ratmice 5 hours ago Presumably unsigned want to return errors too?Edit: I guess they could get rid of a few numbers... Anyhow it isn't a philosophy that is going to get me to consider nimony for anything. umanwizard 5 hours ago > making basic types work differently from C would involve major performance costs.Not if you compile with optimizations on. This C code: int wrapping_add_ints(int x, int y) { return (int)((unsigned)x + (unsigned)y); } Compiles to this x86-64 assembly (with clang -O2): wrapping_add_ints: lea eax, [rdi + rsi] ret Which, for those who aren't familiar with x86 assembly, is just the normal instruction for adding two numbers with wrapping semantics. Symmetry 5 hours ago Specifically, C comes form a world where allowing for machines that didn't use 2's compliment (or 8 bit bytes) was an active concern. aw1621107 4 hours ago Interestingly, C23 and C++20 standardized 2's complement representation for signed integers but kept UB on signed overflow.
xigoi 6 hours ago Nim (the original one, not Nimony) compiles to C, so making basic types work differently from C would involve major performance costs. ratmice 5 hours ago Presumably unsigned want to return errors too?Edit: I guess they could get rid of a few numbers... Anyhow it isn't a philosophy that is going to get me to consider nimony for anything. umanwizard 5 hours ago > making basic types work differently from C would involve major performance costs.Not if you compile with optimizations on. This C code: int wrapping_add_ints(int x, int y) { return (int)((unsigned)x + (unsigned)y); } Compiles to this x86-64 assembly (with clang -O2): wrapping_add_ints: lea eax, [rdi + rsi] ret Which, for those who aren't familiar with x86 assembly, is just the normal instruction for adding two numbers with wrapping semantics.
ratmice 5 hours ago Presumably unsigned want to return errors too?Edit: I guess they could get rid of a few numbers... Anyhow it isn't a philosophy that is going to get me to consider nimony for anything.
umanwizard 5 hours ago > making basic types work differently from C would involve major performance costs.Not if you compile with optimizations on. This C code: int wrapping_add_ints(int x, int y) { return (int)((unsigned)x + (unsigned)y); } Compiles to this x86-64 assembly (with clang -O2): wrapping_add_ints: lea eax, [rdi + rsi] ret Which, for those who aren't familiar with x86 assembly, is just the normal instruction for adding two numbers with wrapping semantics.
Symmetry 5 hours ago Specifically, C comes form a world where allowing for machines that didn't use 2's compliment (or 8 bit bytes) was an active concern. aw1621107 4 hours ago Interestingly, C23 and C++20 standardized 2's complement representation for signed integers but kept UB on signed overflow.
aw1621107 4 hours ago Interestingly, C23 and C++20 standardized 2's complement representation for signed integers but kept UB on signed overflow.
Presumably since this language isn't C they can define it however they want to, for instance in rust std::i32::MIN.wrapping_sub(1) is a perfectly valid number.
Nim (the original one, not Nimony) compiles to C, so making basic types work differently from C would involve major performance costs.
And yet, Nim does overflow checking by default.
Signed overflow being UB (while unsigned is defined to wrap) is a quirk of C and C++ specifically, not some fundamental property of computing.
Nim (the original one, not Nimony) compiles to C, so making basic types work differently from C would involve major performance costs.
Presumably unsigned want to return errors too?
Edit: I guess they could get rid of a few numbers... Anyhow it isn't a philosophy that is going to get me to consider nimony for anything.
> making basic types work differently from C would involve major performance costs.
Not if you compile with optimizations on. This C code:
Compiles to this x86-64 assembly (with clang -O2):
Which, for those who aren't familiar with x86 assembly, is just the normal instruction for adding two numbers with wrapping semantics.
Specifically, C comes form a world where allowing for machines that didn't use 2's compliment (or 8 bit bytes) was an active concern.
Interestingly, C23 and C++20 standardized 2's complement representation for signed integers but kept UB on signed overflow.