On Saturday, 9 February 2019 at 00:15:41 UTC, Rubn wrote:
> 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:
>>> [...]
>>
>> 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.

It is a bug in your code, not the @safe.

On Friday, February 8, 2019 5:05:09 PM MST Rubn via Digitalmars-d wrote:
> 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?

It's not a compiler bug, but the code is still buggy. Using int for indexing is wrong in the general case. It works for smaller arrays, but it's just a bug waiting to happen. I see no problem with the deprecation. Quite the opposite. Using int when size_t should be used is an incredibly common bug, and this helps combat that.

- Jonathan M Davis

On Saturday, 9 February 2019 at 02:13:13 UTC, Jonathan M Davis wrote:
> On Friday, February 8, 2019 5:05:09 PM MST Rubn via Digitalmars-d wrote:
>> 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?
>
> It's not a compiler bug, but the code is still buggy. Using int for indexing is wrong in the general case. It works for smaller arrays, but it's just a bug waiting to happen. I see no problem with the deprecation. Quite the opposite. Using int when size_t should be used is an incredibly common bug, and this helps combat that.
>
> - Jonathan M Davis

It's a bandaid, the larger problem is allowing the comparison between int and size_t. Which my bet is how it is implemented internally, which is why foreach_reverse doesn't work cause it actually has to assign the counter a size_t.

On Saturday, 9 February 2019 at 02:13:13 UTC, Jonathan M Davis wrote:
> On Friday, February 8, 2019 5:05:09 PM MST Rubn via Digitalmars-d wrote:
>> 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?
>
> It's not a compiler bug, but the code is still buggy. Using int for indexing is wrong in the general case. It works for smaller arrays, but it's just a bug waiting to happen. I see no problem with the deprecation. Quite the opposite. Using int when size_t should be used is an incredibly common bug, and this helps combat that.
>
> - Jonathan M Davis

The point was, if you don't see the for() being an issue that has to be fixed. Then there's no reason to see foreach() as an issue to fix. You either fix them both or don't, it doesn't make sense to fix one but not the other. foreach()'s implementation is literally just a for() statement which is where the bug originates from.

On Wednesday, 13 February 2019 at 01:54:35 UTC, Rubn wrote:
> On Saturday, 9 February 2019 at 02:13:13 UTC, Jonathan M Davis
>> It's not a compiler bug, but the code is still buggy. Using int for indexing is wrong in the general case. It works for smaller arrays, but it's just a bug waiting to happen. I see no problem with the deprecation. Quite the opposite. Using int when size_t should be used is an incredibly common bug, and this helps combat that.
>>
>> - Jonathan M Davis
>
> It's a bandaid, the larger problem is allowing the comparison between
> int and size_t. Which my bet is how it is implemented internally, which is why foreach_reverse doesn't work cause it actually has to assign the counter a size_t.
>
> The point was, if you don't see the for() being an issue that has to be fixed. Then there's no reason to see foreach() as an issue to fix. You either fix them both or don't, it doesn't make sense to fix one but not the other. foreach()'s implementation is literally just a for() statement which is where the bug originates from.

The `for` is an issue, but one that is much harder to reason about. With `foreach` over arrays, the index is going to be used for indexing. With for, the counter (if any) is assigned separately and _may_ be used in an arbitrary stopping condition and the indexing (if any) is in the loop.

On Saturday, 9 February 2019 at 00:12:47 UTC, Rubn wrote:
> 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.

Regardless.

Your answers in this thread don't need to be this aggressive. Just because people don't agree with you on how to address an issue doesn't mean you have to patronize them.

On Saturday, 9 February 2019 at 00:05:09 UTC, Rubn wrote:
> Good you agree it isn't a bug. Then we should remove this deprecation right?

The entire ecosystem is locked on unsigned integers, you can't just pull them out.

On Monday, 18 February 2019 at 11:43:11 UTC, Kagamin wrote:
> On Saturday, 9 February 2019 at 00:05:09 UTC, Rubn wrote:
>> Good you agree it isn't a bug. Then we should remove this deprecation right?
>
> The entire ecosystem is locked on unsigned integers, you can't just pull them out.

This feature is currently in DMD, and they are breaking code to change the behavior to not include it. I have no idea what you are talking about.