Pure, Nothrow in Generic Programming

[Don]

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.