A tale of two's complement

[jfager]

fail! to panic! and namespaced enums both landed recently, both broke the world, and both seemed less necessary to me than renaming int. Add me as one more person asking to please not use breaking the world as an excuse not to do the right thing.

[CloudiDust]

IMHO, fallbacking to i32/u32 without renaming int/uint will give the wrong impression that int/uint are synonyms of i32/u32, because that’s what some popular languages are doing. (In practice that means at least C/C++ on 32/64 bit systems, and C#.) And yes, int/uint are too “default looking” anyway.

I don’t see how giving wrong impressions is beginner friendly. If it is different, it should look so.

Another +1 to renaming. FWIW, I now prefer imem/umem.

[iopq]

I’ll accept that criticism. iadr / uadr? For “address-width”

[CloudiDust]

I agree with OP that iptr/iaddr/ioffset/index etc are all too specific. C/C++ have specialized types like intptr_t/offset_t/size_t, even though some may be aliases of each other. But Rust has only two arch-dependent integer types, and they are used in many different contexts, so we should use names that are generic enough, but still different from int/uint.

That’s why I am now for imem/umem.

[dhardy]

Talking about index types brings a question to mind: can we have vectors with custom index types, e.g.

let mut v = vec<f64, index_t = MyTime>::new();
...
v[MyTime::mod(time + offset, lag_length)] = x;

I have used a similar mechanism in a C++ project to good effect (increased type safety), unfortunately requiring a bit of hackery.

[liigo]

If we must rename int/uint, I’d prefer iptr/uptr or ix/ux (here x means non-fix-sized bits, maybe 8/16/32/64, depends on platforms/machines. think how we named i8/i16/i32/i64 and u8/u16/u32/u64).

[jerrym]

I want to thank the core team for giving these integer proposals in-depth consideration, experimenting with names, and deciding! I’m not thrilled with the int/uint names, but such is life. (Would the names ix/ux or i/u have fared better?)

On the topic of breaking changes, note that this was not a risk-reduction choice. (It’s more risky than having to revisit all uses of int/uint to find those that should become WrappingInt or int32.)

… but if we have LLVM undef-s, you could easily get a divide-by-zero. While this isn’t undefined behaviour by LLVM semantics, memcpy-ing a carefully crafted ROP payload into the stack isn’t undefined behaviour by x86 semantics either, but it is not desirably safe behaviour for a high-level language.

@arielb1 could you please add background for those of us who’re unfamiliar with LLVM and x86 internals? ROP = Raster Operations Pipeline?

[CloudiDust]

ix/ux are interesting and logical and better than imem/umem in isolation, but I am afraid they may be too short and may collide with variable names. How about intx/uintx, with suffixes ix/ux?

[theme]

I find it surprising that nobody mentioned C/C++'s ptrdiff_t (which is the signed version of size_t) ptrdiff_t documentation size_t documentation

I would like int to be renamed as idiff and uint to be renamed as usize. I think that these 2 names are suggestive of their uses. This should also encourage using unsigned types where appropriate.

[CloudiDust]

Actually size_t etc are discussed in the various RFCs. (See the most recent RFC 464 as a starting point.)

Also, I think ssize_t is the signed version of size_t. C/C++ give their int type names semantics other than their sizes. Just because ptrdiff_t and ssize_t may be aliases of each other, doesn’t mean they should be treated as the same thing.

But we have only one arch-dependent signed/unsigned integer type pair in Rust, so we should avoid using “non-generic” names.

[theme]

@CloudiDust

I did not say that size_t wasn’t mentioned before, but I said that ptrdiff_t wasn’t.

AFAIK ssize_t is not in the C/C++ standard.

I am not sure what are you trying to tell me.

[CloudiDust]

So I read the doc on size_t and ptrdiff_t and did a bit googling and found that, I misunderstood both ptrdiff_t and ssize_t, and -1 is the only negative value that ssize_t is required to be able to represent according to the standard. Seems that when I did C/C++ back then, I was using the wrong type.

Because of misleading names. And many tutorials I read back then contained misinformation.

All the more reason to rename int/uint.

[theme]

If ssize_t actually can’t represent negative values other than -1 (to signal an error), I’d use Option<usize> in rust. My proposed name should discourage such misuse.

[CloudiDust]

@theme, my point about ssize_t is that, I always assumed that it is for storing “index offsets for containers”, but actually the standard doesn’t agree with me. I was misguided by the tutorials I read. So, we should prevent the same thing from happening to Rust. (I was actually making this point clear to the OP, not arguing with you, sorry for the confusion.)

But I don’t agree with the names idiff/usize. As the OP said:

“Ultimately, pointer-sized integers are used for many purposes (indices, sizes, offsets, pointers), and we don’t want to favor one of those uses over the others in the name.”

I agree with that. And idiff/usize is too specific.

The only semantic meaning of int/uint in Rust is that they are pointer-sized. Just like i32/u32 are 32bit-sized. But they are different from intptr_t/uintptr_t in that they are not only used for “intergers casted from pointers”.

imem/umem are better in this regard, they mean “integers for memory-related things”, but not too specific.

Still they are not ideal because some would think that “int memory”/“unsigned int memory” don’t seem right and don’t look like integer types at all. Personally I don’t find this a problem, but still …

Inspired by @liigo, I now think intx/uintx are better than imem/umem.

Because:

1. It is clear that they are integer types.
2. They are consistent with the other interger types in that they follow the signed-ness + size pattern.
3. x signifies the fact that their exact size is in a sense “unknown” or “varies”, or, platform-dependent.
4. for better or worse, intx/uintx somewhat look like index/uindex.
5. Newcomers will ask the question: “why is there an x?” And they’ll actually read the manual.

[lifthrasiir]

Okay, I had enough time understanding the consequence of this change, in particular the undefinedness of overflows. (I personally don’t care about uint and int, given that the implied changes to the “undefined behavior” are actually more important. I’ll refrain from such bikeshedding for now.) Huon in IRC had clarified the intention of this change, so I’d like to rephrase his words to clear things up. Any mistake in rephrasing is my mistake.

Overflow is unspecified but defined. This is not same to C/C++'s Undefined Behavior (UB), nor LLVM’s Undefined Value (UV) which is represented as undef in IR. It is unfortunate that Niko used a term “undefined value” for this behavior, since LLVM UV can actually trigger UB (for example, by using it in the conditional branch). The important distinction between UB/UV and the unspecified behavior is that the optimizer cannot take advantage of such unspecified behavior. The compiler can silently wrap integers or insert a panic on overflow, but once it got fixed (in rustc jargon: after trans) this behavior should not be changed. This implies that…

Non-debug builds will be (hopefully) same to the current builds under the same set of flags. The compiler will prefer the fastest option on the non-debug builds. Modern architectures (okay, barring from Mill) strongly prefer the wrapping behavior, which matches the current Rust behavior, so the actual compiled code won’t change (hopeefully). In fact the presence of Mill justifies this choice: if the future architecture has a good support of hardware overflow check, the unspecified behavior can be changed to match that.

Dynamic overflow checks are here to stay, even in non-debug builds. It is the essential part of memory safety, so it won’t go away. The optimizer can remove redundant checks but it should not change the meaning of the program. This one is already explained above, in the “Can’t overflow sometimes cause crashes?” section.

You should be always careful in testing overflows. Mandatory overflow checks make testing somewhat more robust, but only when the test is explicitly designed to trigger overflow. (This was the final disagreement between I and Huon after the clarification. I’m glad this one is relatively minor.) Rust will only prevent the worst-case scenario in the case of overflow, as it is now. The importance of implicit and explicit testing doesn’t change even after this change.

[CloudiDust]

The new renaming proposal (int/uint -> intx/uintx) has been filed as RFC PR 544.

[naicode]

I too think that renaming int/uint is a good idea. Because umem might be a little bit confusing for beginners and names like idiff are too specific I think the intx and uintx suggested by @CloudiDust are a good idea. Through maybe intp/uintp would be bether with p standing for platform and also sounding a little bit like pointer

[CloudiDust]

@naicode, IMHO, intp/uintp have the same problem as iptr/uptr, that is they may also be mistaken for “integer types that should store casted pointer values”, ie. intptr_t/uintptr_t. Some may think that they suggest a specific use case, and this is not desirable.

[petrochenkov]

Unspecified values are still fun. With unspecified values a compiler in each particular case can assume an overflow/underflow result to be any specific value it finds convenient. For example, in this snippet

// x has type int
if x + 1 < x {
    /*...*/
}

a compiler can choose saturating behavior, i.e. INT_MAX as the overflow result, and completely eliminate the if block based on this choice. This is quite similar to what C compilers currently do with “undefinedly behaving” overflows.

I guess, to completely prohibit such optimizations overflow still have to be partially specified. For example it can be defined as “wrapped value or no value at all (panic, signal, abort, whatever)”. With this definition user will never be able to assume wrapping behavior and compiler will not be able to perform dangerous optimizations.

P.S. It would be useful to somehow separate this thread into two parts - bikeshedding about renaming int/uint (hopeless, imho) and everything else.

[jerrym]

defined as “wrapped value or no value at all (panic, signal, abort, whatever)”

+1 for this totally clear and specific definition for the result of integer overflow.