foreach counter now must be size_t ?

[Rubn]

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.