On 06/15/2014 08:44 PM, Walter Bright wrote:
On 6/15/2014 2:48 AM, Timon Gehr wrote:
On 06/15/2014 10:33 AM, Walter Bright wrote:
What Timon is saying is that not all memory safe code is verifiably
@safe.
In D, they are defined to be the same thing,
Since when?
http://dlang.org/function
...
so the statement makes no sense.
Then please indicate how to fix the documentation. If you are going to
claim the
Humpty Dumpty privilege, I'll back off. Thanks.
I don't know why the documentation says that. D's @safe is about memory
safety, not undefined behavior.
...
Note that this is frustratingly unhelpful for deciphering your point
about "memory safe" <=> "verifiably @safe" by definition. Are you
defining "memory safe" or "verifiably @safe"?
Note that the list of eschewed behaviors are possibly memory corrupting.
It is an incomplete list. I'd rather see an incomplete list of _allowed_
behaviours instead of an incomplete list of eschewed behaviours. In any
case, I don't see how any list of (syntactic) verifiable properties of
the code is supposed to be equivalent to the (non-trivial semantic)
memory safety property. Are you assuming @trusted as an oracle for
memory safety and saying @trusted code is 'verifiably @safe' code?
(That's not the intended reading.)
Signed integer overflow, for example, is not listed.
Are you trying to say that signed integer overflow is undefined
behaviour in D? (This would again contradict the documentation.)
