Integer fallback still somewhat present?

[alexcrichton]

fn foo(_: *const ()) {}

fn bar() {
    let a = 3;
    foo(&a as *const _ as *const ());
}

The type of a is never mentioned, so it seems to be assuming int?

Nominating.

[alexcrichton]

cc @pcwalton

[pnkfelix]

Assigning 1.0, P-backcompat-lang.

[japaric]

Another (simpler) example:

fn main() {
    println!("{}", std::mem::size_of_val(&1));  // prints 8 (assumes `int`?)
    println!("{}", std::mem::size_of_val(&1.0));  // prints 8 (assumes `f64`?)
}

[alexchandel]

Why is this desirable? Sorry, I'm new to Rust, and I like everything I've learned so far, but this comes off as a severe antifeature to me. Adding "i" to all my int literals makes me sad. Adding "f64" to all my float literals just uglifies my code beyond belief. And I can't even use float anymore when I don't care about size, unlike int and uint, even though there are so cases where I just want the native word size, and where I am in provably zero danger of overflowing.

[thestinger]

@alexchandel: rust-lang/rfcs#115

And I can't even use float anymore when I don't care about size, unlike int and uint, even though there are so cases where I just want the native word size, and where I am in provably zero danger of overflowing.

The int and uint types are not defined as "native word size" (which isn't clearly defined), but rather as pointer size. A pointer size integer is guaranteed to be enough for array indexing, object sizes, etc. but it's bad practice to use it elsewhere.

[alexchandel]

My mistake, I forgot about cases like x32 and was assuming equal widths for integer and addressing registers. But the points remains, no? There are cases where a programmer may want the size of the floating point or integer registers of the target platform (and no larger) for speed considerations, or where it's reasonable to assume a signedness, or where one simply doesn't care about the size. Why force a minimal cruft-level when there is a reasonable, defined, default case?

[thestinger]

You can't avoid thinking about the size if you're writing correct code. If you're not using a big integer, you need to verify that it's not going to overflow.

[alexchandel]

What about for cases where overflow can't occur? Alternatively, the compiler could have a lint check that warns whenever int is assumed (or uint or float/f64).

[thestinger]

What about for cases where overflow can't occur?

The type that's chosen needs to be large enough for the use case. As I said, if you're not using a big integer, you need to verify that it's not going to overflow.

[alexchandel]

Right, so for any target, the size of int is known at compile time, and may be provably large enough. If we're really never supposed to use int and uint unless they contain an address, shouldn't they be called intptr and uintptr, or even ptr and uptr? Are there even signed pointers?

[thestinger]

Right, so for any target, the size of int is known at compile time, and may be provably large enough.

I don't understand the point you're trying to make.

If we're really never supposed to use int and uint unless they contain an address, shouldn't they be called intptr and uintptr, or even ptr and uptr?

I didn't say the only use case was for storing addresses:

A pointer size integer is guaranteed to be enough for array indexing, object sizes, etc. but it's bad practice to use it elsewhere.

It's unlikely to be the right choice for other use cases. If you're sure that a 32-bit integer is the minimum requirement, that's what you should use.

[alexchandel]

@thestinger Hmm I think you've convinced me, thanks.