Pop Quiz what is wrong with this code?

[Patrick Schluter]

On Sunday, 21 June 2020 at 13:17:54 UTC, Avrina wrote:
> On Sunday, 21 June 2020 at 10:12:22 UTC, Patrick Schluter wrote:
>> On Saturday, 20 June 2020 at 23:36:25 UTC, Avrina wrote:
>>> On Saturday, 20 June 2020 at 18:15:27 UTC, Steven 
>>> Schveighoffer wrote:
>>>> On 6/20/20 12:00 PM, Danni Coy wrote:
>>>>
>>>>> I tried explicitly making x and y ints and I got a 
>>>>> depreciation warning.
>>>>
>>>> foreach(ptrdiff_t y, ref row; offsetMap)
>>>>
>>>> is that what you wanted?
>>>>
>>>> ptrdiff_t is the signed version of size_t. The complaint is 
>>>> not that you are converting from unsigned to signed, but 
>>>> that you are converting from 64-bit to 32-bit.
>>>>
>>>> -Steve
>>>
>>> Why isn't that deprecated as well? implicitly converting from 
>>> ulong to long is an error as much as ulong to uint.
>>
>> No. conversion of ulong to uint loses 32 times more data than 
>> conversion to long does.
>
> Lol, it's not linear friend.

losing 1 bit vs losing 32 bits. The exponentiation is irrelevant.

>
> You lose around 18446744069414584319 values from ulong to uint, 
> you lose 9223372032559808512 from ulong to long. Which is about 
> 2 times less data. Which makes sense as it is basically 2^64 - 
> 2^63, so of course it would only be x2 -- not x32.

> Not that it should matter how much, it's a problem either way.

But a much less severe one.
Overflowing a 32 bit index on a 64 bit machine with the data 
sizes that exist today (files of more than 4GiB are not rare, 
zips, videos and databases).
9 223 372 032 559 808 512  is still 32768x bigger than 
281 474 976 710 656, the biggest addressable range on x86_64.