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

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.