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.
