ref is unsafe

[Rob T]

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