On 1/10/14 10:05 PM, Daniel Micay wrote: > On Sat, Jan 11, 2014 at 12:48 AM, Patrick Walton <pcwal...@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@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: i.e., 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. -- Regards, Paul
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
