foreach counter now must be size_t ?

[Rubn]

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?