Pure, Nothrow in Generic Programming

[dsimcha]

== Quote from Don (nospam at nospam.com)'s article
> Andrei Alexandrescu wrote:
> > Walter Bright wrote:
> >> dsimcha wrote:
> >>> I think you misunderstood the argument.  memcmp() could be @trusted
> >>> if functions
> >>> only need to be safe when passed valid parameters, though I don't
> >>> necessarily
> >>> agree that this makes sense.  I was thinking memcmp() shouldn't even
> >>> be marked
> >>> @trusted because it's so easy to invoke undefined behavior by passing
> >>> incorrect
> >>> parameters.  This would mean that, if opCmp() uses it, opCmp()
> >>> couldn't be marked
> >>> as @safe.
> >>
> >> memcmp() could be marked @trusted, but it should not be. This is
> >> because @trusted functions can be called by @safe ones, but there's no
> >> way that an @safe function can guarantee it sends memcmp() arguments
> >> that will work safely with memcmp().
> >>
> >> Whoever calls memcmp() can be marked @trusted.
> >
> > Hm, if we think of it, memcmp can be @safe no problem. This is beacuse
> > it oly reads stuff. There are three possible outcomes:
> >
> > a) valid addresses, all's fine
> >
> > b) incorrect addresses within the application, erroneous result returned
> >
> > c) incorrect addresses outside the application, segfault
> >
> > None of the above is unsafe. So memcmp is safe. (In contrast, memcpy is
> > not). Color me surprised but convinced.
> >
> >
> > Andrei
> Although Walter had previously talked about making @safe a little
> stronger than just memory safety -- with the goal of eliminating
> undefined behaviour. So (b) would be a problem. After all, you could you
> use the same argument to say that array bounds checking isn't required
> for reads, only for writes.

Quick question about the eliminating undefined behavior thing:  Isn't overflowing
a signed int undefined behavior?  If so, how would we eliminate undefined behavior
without very expensive runtime checks?