foreach counter now must be size_t ?

[Jonathan M Davis]

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