Integer conversions too pedantic in 64-bit

[Rainer Schuetze]

Steven Schveighoffer wrote:
> 
> In addition size_t isn't actually defined by the compiler.  So the 
> library controls the size of size_t, not the compiler.  This should make 
> it extremely portable.
> 

I do not consider the language and the runtime as completely seperate 
when it comes to writing code. BTW, though defined in object.di, size_t 
is tied to some compiler internals:

	alias typeof(int.sizeof) size_t;

and the compiler will make assumptions about this when creating array 
literals.

>> Consider saving an array to disk, trying to read it on another 
>> platform. How many bits should be written for the size of that array?
> 
> It depends on the protocol or file format definition.  It should be 
> irrelevant what platform/architecture you are on.  Any format or 
> protocol worth its salt will define what size integers you should store.

Agreed, the example probably was not the best one.

>> I don't have a perfect solution, but maybe builtin arrays could be 
>> limited to 2^^32-1 elements (or maybe 2^^31-1 to get rid of endless 
>> signed/unsigned conversions), so the normal type to be used is still 
>> "int". Ranges should adopt the type sizes of the underlying objects.
> 
> No, this is too limiting.  If I have 64GB of memory (not out of the 
> question), and I want to have a 5GB array, I think I should be allowed 
> to.  This is one of the main reasons to go to 64-bit in the first place.

Yes, that's the imperfect part of the proposal. An array of ints could 
still use up to 16 GB, though.

What bothers me is that you have to deal with these "portability issues" 
from the very moment you store the length of an array elsewhere. Not a 
really big deal, and I don't think it will change, but still feels a bit 
awkward.