On 2/6/2019 2:00 PM, jmh530 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.

Executables are not loaded into memory before running them, they are mmap'ed into memory. Digital Mars C++ used mmap for precompiled headers. There are all kinds of uses, it's a very effective tool.

On Thursday, 7 February 2019 at 03:20:03 UTC, Walter Bright wrote:
> On 2/6/2019 2:00 PM, jmh530 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.
>
> Executables are not loaded into memory before running them, they are mmap'ed into memory. Digital Mars C++ used mmap for precompiled headers. There are all kinds of uses, it's a very effective tool.

I'll take that to mean you don't think this is a bug:

@safe void foo(int[] a) {
    for(int i = 0; i < a.length; ++i ) {
       writeln( i );
    }
}

Fucking classic.

On Thursday, February 7, 2019 4:02:14 PM MST Rubn via Digitalmars-d wrote:
> On Thursday, 7 February 2019 at 03:20:03 UTC, Walter Bright wrote:
> > On 2/6/2019 2:00 PM, jmh530 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.
> >
> > Executables are not loaded into memory before running them, they are mmap'ed into memory. Digital Mars C++ used mmap for precompiled headers. There are all kinds of uses, it's a very effective tool.
>
> I'll take that to mean you don't think this is a bug:
>
> @safe void foo(int[] a) {
>      for(int i = 0; i < a.length; ++i ) {
>         writeln( i );
>      }
> }
>
> Fucking classic.

If you're trying to say that you think that that's a compiler bug, then you misunderstand @safe. @safe code cannot access invalid memory. It cannot have undefined behavior. But it can have plenty of logic bugs, and what that code has is a logic bug. It's at zero risk of accessing invalid memory. It's just going to do the wrong thing if the array is sufficiently large. The only way that array size issues are an @safe-related bug is if you have code that somehow manages to access the array out-of-bounds in spite of the code being @safe.

It's been argued before that comparing integer types of different size or signedness should not be legal, because it's a source of bugs, and maybe it shouldn't be legal, but even if that's true, it's still not an issue with @safe.

- Jonathan M Davis

On 2/7/2019 3:02 PM, Rubn wrote:
> [...] classic.

Use of such words will result in deletion of the posts. Please use professional demeanor on these forums.

On Thursday, 7 February 2019 at 23:02:14 UTC, Rubn wrote:
> I'll take that to mean you don't think this is a bug:
>
> @safe void foo(int[] a) {
>     for(int i = 0; i < a.length; ++i ) {
>        writeln( i );
>     }
> }
>
> Fucking classic.

Its not a bug. In the case that a.length > int.max, the loop will not terminate and only print indices. If the loop was

     for(int i = 0; i < a.length; ++i ) {
        writeln( a[i] );
     }

it would still be @safe, but the program would crash because the index would (eventually) be OOB. If a.length > uint.max and the loop was

     for(uint i = 0; i < a.length; ++i ) {
        writeln( a[i] );
     }

then the loop fail to terminate, and it would still be @safe. All the above problems are avoided using size_t as the index.

On Thursday, 7 February 2019 at 23:02:14 UTC, Rubn wrote:
> Fucking classic.

Specific language aside, there's a proper way to bring bugs to a maintainer's attention, and telling them "Oh, so you don't think [this bug I hate] is important enough for you? Typical..." out of nowhere is not it.

The maintainers have a responsibility to the community, not to you personally. Acting passive-aggressive because they haven't yet fixed your pet issue is incredibly entitled and unprofessional.

Please don't. That kind of behavior is common, but it's *not* acceptable.

On Thursday, 7 February 2019 at 23:37:06 UTC, Jonathan M Davis wrote:
> On Thursday, February 7, 2019 4:02:14 PM MST Rubn via Digitalmars-d wrote:
>> On Thursday, 7 February 2019 at 03:20:03 UTC, Walter Bright wrote:
>> > On 2/6/2019 2:00 PM, jmh530 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.
>> >
>> > Executables are not loaded into memory before running them, they are mmap'ed into memory. Digital Mars C++ used mmap for precompiled headers. There are all kinds of uses, it's a very effective tool.
>>
>> I'll take that to mean you don't think this is a bug:
>>
>> @safe void foo(int[] a) {
>>      for(int i = 0; i < a.length; ++i ) {
>>         writeln( i );
>>      }
>> }
>>
>> Fucking classic.
>
> If you're trying to say that you think that that's a compiler bug, then you misunderstand @safe. @safe code cannot access invalid memory. It cannot have undefined behavior. But it can have plenty of logic bugs, and what that code has is a logic bug. It's at zero risk of accessing invalid memory. It's just going to do the wrong thing if the array is sufficiently large. The only way that array size issues are an @safe-related bug is if you have code that somehow manages to access the array out-of-bounds in spite of the code being @safe.
>
> It's been argued before that comparing integer types of different size or signedness should not be legal, because it's a source of bugs, and maybe it shouldn't be legal, but even if that's true, it's still not an issue with @safe.
>
> - Jonathan M Davis

Good you agree it isn't a bug. Then we should remove this deprecation right?

On Friday, 8 February 2019 at 06:33:00 UTC, Walter Bright wrote:
> On 2/7/2019 3:02 PM, Rubn wrote:
>> [...] classic.
>
> Use of such words will result in deletion of the posts. Please use professional demeanor on these forums.

You can go ahead and delete the post if you want. It'd be no different than not answer a valid question :), thought maybe mildly better.

On Friday, 8 February 2019 at 20:22:29 UTC, Olivier FAURE wrote:
> The maintainers have a responsibility to the community, not to you personally.

Guess you weren't around, Walter's opinion on the matter is they have responsibility to ducking no one.

On Friday, 8 February 2019 at 08:06:39 UTC, Nicholas Wilson wrote:
> On Thursday, 7 February 2019 at 23:02:14 UTC, Rubn wrote:
>> I'll take that to mean you don't think this is a bug:
>>
>> @safe void foo(int[] a) {
>>     for(int i = 0; i < a.length; ++i ) {
>>        writeln( i );
>>     }
>> }
>>
>> Fucking classic.
>
> Its not a bug. In the case that a.length > int.max, the loop will not terminate and only print indices. If the loop was
>
>      for(int i = 0; i < a.length; ++i ) {
>         writeln( a[i] );
>      }
>
> it would still be @safe, but the program would crash because the index would (eventually) be OOB. If a.length > uint.max and the loop was
>
>      for(uint i = 0; i < a.length; ++i ) {
>         writeln( a[i] );
>      }
>
> then the loop fail to terminate, and it would still be @safe. All the above problems are avoided using size_t as the index.

TIL infinite loop that freezes program isn't a bug.