[rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

Paul Nathan pnathan at vandals.uidaho.edu
Fri Jan 10 22:21:16 PST 2014

On 1/10/14 10:05 PM, Daniel Micay wrote:
> On Sat, Jan 11, 2014 at 12:48 AM, Patrick Walton <pcwalton at mozilla.com> wrote:
>> On 1/10/14 9:41 PM, Corey Richardson wrote:
>>> The current consensus on this subject, afaik, is the rename int/uint
>>> to intptr/uintptr. They're awful names, but it frees up int for a
>>> *fast* bigint type. Fast here is key. We can't have a suboptimal
>>> numeric type be the recommended default. We need to perform at least
>>> as well as GMP for me to even consider it. Additionally we'd have
>>> generic numeric literals. I don't think anyone wants what we current
>>> have for *numerics*. Fixed-size integers are necessary for some tasks,
>>> but numerics is not one of them.
>> I wasn't aware of this consensus. I'm not sure what I think; int and uint as
>> they are is pretty nice for array indexing.
>> Patrick
> I think it's very important to remove the default fallback to `int` so
> Rust can leave this as an explicit choice for the programmer. It's too
> easy to accidentally fall back to a fixed-size signed integer and
> since the length varies based on the pointer-size, you may not run
> into the bugs on the platform you're developing on.
> It would be nice to name them based on what they are instead of making
> them out as good defaults, because this should really be an explicit
> choice. High-level logic will often (but not always) want a big
> integer type, and it's too easy to just use `int` because it's the
> "default".
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
> .

One of the common style rules in C/C++ codebases (IME and from what I've
read) is to have an explicit typedef'd int<intsize> type:


typedef unsigned char uint8;
typedef unsigned short uint16;
typedef unsigned long uint32;
// and so forth.

This way it's clearly seen what the width is in the code.

It would seem to me to be an obvious choice of "optimize for the correct
case" to remove "int" and require choosing the width as part of the type
declaration (much like has been done for floats).

Note - I have zero experience in numerical analysis; my experience here
largely lies in the embedded/low-level space. A numerical analyst may
disagree 100% and prefer a generic "bigint" type for correctness of
computation. No idea. Not my area so far.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 946 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140110/e15775fc/attachment.sig>

More information about the Rust-dev mailing list