Array Indexing

[kris]

James Dunne wrote:
> kris wrote:
> 
>> James Dunne wrote:
>>
>>> Agreed.  Byte isn't really an integer, it's more for storage.  
>>> Storage should not care about signedness, it should just be used for 
>>> read, write, comparison, and bit-flipping operations.
>>
>>
>> Woah ... byte isn't really an integer? I guess long is not really an 
>> integer either, and should only be used for bit flipping too :)
>>
> 
> Of course not.  I simply meant that bytes shouldn't be used for 
> calculations.  None of our integral types are literal mathematical types 
> if that's what you're trying to point out.  I meant the word 'byte' 
> implies storage.  Would you prefer octet instead?
> 

I'm not trying to piss on your shoes, James :)

But, what you noted is kinda' nonsense. Each of those common terms 
represent 'storage'; not just "byte". And what's this about byte "should 
just be used for read, write, comparison, and bit-flipping"? That's 
plain rubbish :)

How about a "tiny int"?

The point is, you /appear/ to be making a totally arbitrary distinction. 
Eight-bit values make perfectly good "integers" for a number of CPU 
designs and applications. It may not suit the type of apps you happen to 
be thinking of, but that's beside the point.

Just because the natural comfort-spot for hardware architectures 
currently targeted by D happen to have 32-bit registers, that doesn't 
make "int" the only road to travel. Does it? What about 64-bit 
architectures, where the comfort-spot can be a 64-bit "long" instead? 
(depending on how you compile your app). At that point, does "int" get 
relegated to the place where "byte" used to be? For 'read', 'write', 
'comparison', and 'bit flipping' only?

This is daft. And I wouldn't bother to say anything other than someone 
might take you literally :)

*shrug*