Walter Bright Wrote: > On 11/9/2011 10:13 PM, Caligo wrote: > > Something like this would have been better, and if I recall this is how > > Chapel > > is doing it: > > > > int(32) a; // int > > int(64) b; // long > > I did consider something like that early on, but couldn't get past > > 1. how ugly it looks after a while > > 2. the implication that int(17) should work, or int(1), etc. > > 3. the reality that CPUs tend to have 32 as the optimal size, and 'int' being > a > natural thing to type, it tends to be the default one types in. Otherwise, > how > would you explain that one should use int(32) rather than int(16) for routine > integer use? It just seems (to me) that it would encourage the use of > inefficient integer types. > > 4. I bet the first thing programmers would do with such types is: > > alias int(32) myint; > > and then we're in a mismash of non-standard types (this happens too often in > C > where the sizeof(int) is unreliable). > > 5. I don't need constant reminding that ints are 32 bits.
1. This makes sense on 32bit platforms. What about 64bit platforms? 2. What about int(128), int(16), int(8)? for the non-default (!= 32) you do want to know the size. in what way short and byte better? 3. The default optimal size should indeed have an alias such as 'int'. A much better scheme IMO is to define as general type and predefine an easy to remember alias for the default (32). Wait a sec, that's what chapel did.. The problem isn't with "int" but rather with the proliferation of the other types for all the combinations of sign-ness and size.
