On Tuesday, 5 February 2019 at 23:04:16 UTC, Walter Bright wrote:
> On 2/5/2019 1:14 PM, Rubn wrote:
>> WHAT. WHAT. Where do you see an assignment from size_t to int here?
>> 
>> int[] arr = someRandomArray();
>> for( int i = 0; i < arr.length; ++i ) {
>>     dg( i, arr[i] );
>> }
>> 
>> ???
>
> The ++i overflows and the loop never terminates.

In case you forgot what you said:

> It's irrelevant, as the semantics of the language have to be sound across the uses it supports.

This change to not allow int goes against the semantics of the language.

On Tuesday, 5 February 2019 at 21:14:17 UTC, Rubn wrote:
> On Tuesday, 5 February 2019 at 04:53:00 UTC, Walter Bright wrote:
>> [...]
>
>
> WHAT. WHAT. Where do you see an assignment from size_t to int here?
>
> [...]

Memory mapping archives and video files can easily get beyond 32 bits. It's not because you never noticed that there aren't people out there doing that every day.

>
> [...]

On Tuesday, 5 February 2019 at 21:51:41 UTC, Dukc wrote:
> If so, too bad. But it'll still help, because if I try to compile to 64-bit, the compiler will catch the error. Without the deprecation, there would be a bug (due to 32-bit overflow) that likely never manifests, but bites all the harder if it still does.

There's no limit to error checks, do you compile with warnings enabled? See https://dlang.org/articles/warnings.html

On Tuesday, 5 February 2019 at 21:14:17 UTC, Rubn wrote:
> On Tuesday, 5 February 2019 at 04:53:00 UTC, Walter Bright wrote:
>> I.e. where the array bounds are known at compile time, then it works, because:
>>
>>     enum long l = 3;
>>     uint i = l;
>>
>> also works.
>
>
> WHAT. WHAT. Where do you see an assignment from size_t to int here?
>
> int[] arr = someRandomArray();
> for( int i = 0; i < arr.length; ++i ) {
>    dg( i, arr[i] );
> }
>
> ???

Seems that the size_t would have to be a compiler variable we don't see, but would be nice to have this answered.

On Wednesday, 6 February 2019 at 06:27:27 UTC, Patrick Schluter wrote:
> On Tuesday, 5 February 2019 at 21:14:17 UTC, Rubn wrote:
>> On Tuesday, 5 February 2019 at 04:53:00 UTC, Walter Bright wrote:
>>> [...]
>>
>>
>> WHAT. WHAT. Where do you see an assignment from size_t to int here?
>>
>> [...]
>
> Memory mapping archives and video files can easily get beyond 32 bits. It's not because you never noticed that there aren't people out there doing that every day.
>
>>
>> [...]

I never knew arrays were files, thanks for the tip.

On Wed, Feb 06, 2019 at 08:59:14PM +0000, Rubn via Digitalmars-d wrote:
> On Wednesday, 6 February 2019 at 06:27:27 UTC, Patrick Schluter wrote:
[...]
> > Memory mapping archives and video files can easily get beyond 32 bits.  It's not because you never noticed that there aren't people out there doing that every day.
[...]
> I never knew arrays were files, thanks for the tip.

As you may know, mmap() turns files into arrays (see std.mmfile).  You
access it just like an array, and the OS maps it to the file for you.

You wouldn't want somebody to pass the array returned by an mmap() call to your code that assumes arrays cannot have length larger than 32-bits -- you'd run into wraparound bugs.

Just because the array has a huge size doesn't necessarily mean you need that much RAM to hold it. The OS pages parts of it in/out as you access it.


T

-- 
If blunt statements had a point, they wouldn't be blunt...

On Wednesday, 6 February 2019 at 21:23:20 UTC, H. S. Teoh wrote:
> [snip]
>
> As you may know, mmap() turns files into arrays (see std.mmfile).  You
> access it just like an array, and the OS maps it to the file for you.
>
> You wouldn't want somebody to pass the array returned by an mmap() call to your code that assumes arrays cannot have length larger than 32-bits -- you'd run into wraparound bugs.
>
> Just because the array has a huge size doesn't necessarily mean you need that much RAM to hold it. The OS pages parts of it in/out as you access it.
>
>
> T

mmap is something that I never really played around much with, but it seems like it would be useful for me in some cases. I've done some Monte Carlo simulations that end up causing me to run out of memory. Doing it as an mmap instead might be slower but at least I wouldn't run out of memory.

On Wed, Feb 06, 2019 at 10:00:35PM +0000, jmh530 via Digitalmars-d wrote: [...]
> mmap is something that I never really played around much with, but it seems like it would be useful for me in some cases. I've done some Monte Carlo simulations that end up causing me to run out of memory. Doing it as an mmap instead might be slower but at least I wouldn't run out of memory.

It depends on how big your resident set size is, and what your memory access patterns are.  If you're using the mmap'd memory in a random-access pattern, be prepared for your OS to slow down to a crawl as it begins thrashing on I/O swapping pages from disk only to evict them milliseconds later because there's no more memory to load in the page for the next random access.

There's no free lunch. :-P

That's why in this day and age people are moving away from hashtables, once hailed as the holy grail of data structure design, to structures based on linear access that have "worse" big-O complexity but better real-world performance, because linear access plays nicer with the cache hierarchy.


T

-- 
"How are you doing?" "Doing what?"

On Wednesday, 6 February 2019 at 22:29:11 UTC, H. S. Teoh wrote:
> [snip]

Very informative. Thanks.

On Wednesday, 6 February 2019 at 21:23:20 UTC, H. S. Teoh wrote:
> On Wed, Feb 06, 2019 at 08:59:14PM +0000, Rubn via Digitalmars-d wrote:
>> On Wednesday, 6 February 2019 at 06:27:27 UTC, Patrick Schluter wrote:
> [...]
>> > Memory mapping archives and video files can easily get beyond 32 bits.  It's not because you never noticed that there aren't people out there doing that every day.
> [...]
>> I never knew arrays were files, thanks for the tip.
>
> As you may know, mmap() turns files into arrays (see std.mmfile).  You
> access it just like an array, and the OS maps it to the file for you.
>
> You wouldn't want somebody to pass the array returned by an mmap() call to your code that assumes arrays cannot have length larger than 32-bits -- you'd run into wraparound bugs.

Not everyone is writing generic code. Especially in performance critical code.

Like I was saying, this is one those very rare use cases anyways. And AGAIN if you have a memory mapped file in a 32-bit executable, this will not function.

Lol man the implementation of mmfile. The interface all uses ulong but then it casts everything to size_t, that's a minefield on a 32-bit system. Good luck accessing a > 4GB file with that.

> Just because the array has a huge size doesn't necessarily mean you need that much RAM to hold it. The OS pages parts of it in/out as you access it.

Which will be extremely slow. That might be fine for testing something but you'll be better off writing your own code to handle processing that much data in a way that is most efficient for whatever it is you are doing.