<p>What if te compiler was allowed to optimist to larger types?  The only issue is if pulled rely on overflowing.  That could be fixed by add in a type with a minimum size specified.  This is kind of like C's fast int type.</p>

<div class="gmail_quote">On Feb 20, 2012 8:20 AM, "Regan Heath" <<a href="mailto:regan@netmail.co.nz">regan@netmail.co.nz</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, 20 Feb 2012 11:28:44 -0000, Manu <<a href="mailto:turkeyman@gmail.com" target="_blank">turkeyman@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 20 February 2012 13:16, Walter Bright <<a href="mailto:newshound2@digitalmars.com" target="_blank">newshound2@digitalmars.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2/20/2012 3:02 AM, Manu wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
? I must have misunderstood something... I've never seen a 64bit C<br>
compiler<br>
where 'int' is 64bits.<br>
<br>
</blockquote>
<br>
What are you using in C code for a most efficient integer type?<br>
<br>
</blockquote>
<br>
#ifdef. No 2 C compilers ever seem to agree.<br>
It's a major problem in C, hence bringing it up here. Even size_t is often<br>
broken in C. I have worked on 64bit systems with 32bit pointers where<br>
size_t was still 64bit, but ptrdiff_t was 32bit (I think PS3 is like this,<br>
but maybe my memory fails me)<br>
<br>
I want to be confident when I declare a numeric type that can interact with<br>
pointers, and also when I want the native type.<br>
</blockquote>
<br>
I can imagine situations where you want to explicitly have a numeric type that can hold/interact with pointers, or you need /more/ width than the native/efficient int type.<br>
<br>
But, in /all/ other cases surely we want the **compiler** to pick/use the native/most efficient int type/size.  Further, why should we state this explicitly, why shouldn't "int" just /be/ the native/most efficient type (as determined by the compiler during compilation of each/every block of code)... I know, I know, this goes in the face of one of D's initial design decisions - being sure of the width of your types without having to guess or dig in headers for defines etc.. but, remind me why this is a bad idea?<br>

<br>
Because, it just seems to me that we want "int" to be the native/most efficient type and we want fixed sized types for special/specific cases (like in struct definitions where alignment/size matters, etc), i.e.<br>

<br>
int a;   // native/efficient type<br>
int16 b; // 16 bit int<br>
int32 c; // 32 bit int<br>
int64 d; // 64 bit int<br>
..and so on..<br>
<br>
But.. assuming that's not going to change any time soon, we might be able to go the other way.  What if we had a built-in "nint" type, which we could use everywhere we didn't care about integer type width, which resulted in the compiler picking the most efficient/native int width on a case by case basis (code inspection, etc.. not sure of the limits of this).<br>

<br>
Regan<br>
<br>
-- <br>
Using Opera's revolutionary email client: <a href="http://www.opera.com/mail/" target="_blank">http://www.opera.com/mail/</a><br>
</blockquote></div>