On Friday, 4 January 2013 at 00:46:33 UTC, Araq wrote:
On Wednesday, 2 January 2013 at 23:33:16 UTC, Thiez wrote:
On Wednesday, 2 January 2013 at 22:53:04 UTC, Jonathan M Davis
wrote:
Then we're going to have to disagree, and I believe that
Walter and Andrei are
completely with me on this one. If all of the constructs that
you use are
@safe, then it should be _guaranteed_ that your program is
memory-safe. That's
what @safe is for. Yes, it can be gotten around if the
programmer marks
@system code as @trusted when it's not really memory-safe,
but that's the
programmer's problem. @safe is not doing it's job and is
completely pointless
if it has any holes in it beyond programmers mislabeling
functions as @trusted.
- Jonathan M Davis
Perhaps it is worth looking at Rust for this problem?
You can also look at how Algol solved this over 40 years ago:
Insert a runtime check that the escaping reference does not
point to the current stack frame which is about to be
destroyed. The check should be very cheap at runtime but it can
be deactivated in a release build for efficiency just like it
is done for array indexing.
FYI Nimrod has the same problem and it's planned to prevent
these cases statically with a type based alias analysis;
however at least the first versions will still keep the dynamic
check as these kind of static analyses cry for correctness
proofs IMO.
I did suggest something like that, and it may be a good idea to
implement as a debugging aid (like runtime range checking). I
wonder how difficult it would be to implement?
Unfortunately, it does not help solve the @safe compile time
checks.
--rt
