On: Comparing k-NN in Rust

[modeless]

What's the justification for having a variable size int as the default? That seems like a mistake to me.

[kibwen → modeless]

Variable-size as in C++, or variable-size as in Rust? Because they both seem like mistakes to me, but not everyone seems to agree. :)

[pcwalton → kibwen]

I don't think it's a mistake in Rust, because of array indices.

[kibwen → pcwalton]

I'm not convinced that array indexing is the primary use case of integral variables. And since this is the use case most often espoused for ints, they should probably be renamed to something more appropriate (intptr/uintptr? index/uindex? idx/uidx?). And heck, while we're at it, bare numeric literals should probably default to i32 rather than int (as gross as that feels, it's the least bad option that doesn't involve removing numeric literal type inference). But perhaps this is the wrong forum for this discussion. :P

[bjz_ → kibwen]

I agree it is weird too.

[pcwalton → modeless]

Because usually ints are used as array indices, and you want them to be the same size as a pointer in that case.

There is an issue to remove the notion of a "default" integer type.

[modeless → pcwalton]

Ah, I see. Personally I think that isn't a strong enough justification, since this choice introduces possible 32/64 bit portability issues and prevents optimizations in scenarios like this. Arrays with >4 billion elements are rare and it would be a shame to compromise the language design for them.

[dbaupp → modeless]

It would also be a shame to end up with an overly restrictively language in future, where large arrays/values need special `..._64` functions (taking 64 bit integers, rather than 32 bit ones).

[kazagistar → pcwalton]

I like that justification, assuming there are int8, int16, int 32, int64, etc, there is no need for another int anyways.