ref is unsafe

[comco]

On Sunday, 30 December 2012 at 22:02:16 UTC, Jonathan M Davis 
wrote:
>  But that's
> very different from any attribute that we currently have. It 
> would be like
> having a throw attribute instead of a nothrow attribute. I 
> suppose that it is
> a possible solution though. I could also see an argument that 
> the attribute
> should go on the parameter rather than the function, in which 
> case you could
> have more fine-grained control over it, but it does complicate 
> things further.

I think this is the most reasonable thing to do and I can argue 
that the complications are not a valid argument against this. 
I've came out with roughly the same idea some days ago. Comparing 
this with nothrow is a nice point, but I don't see it as an 
argument against it. This is the most logical thing to do, and 
solves problems.

So, the general notion that we want to (statically) express is 
that the ref result of a function __can__ depend on one (or more 
- depending on a condition for example) ref function parameters. 
Now, if the result is used when all the annotated arguments are 
still in scope, that usage can be considered @safe.

So a function declaration will (conceptually) look like this:
ref int min(@result_tracks_scope_of ref int a, 
@result_tracks_scope_of ref int b) {
     return a < b ? a : b;
}

Now the interface provides enough information for itself to infer 
when the usage is safe and when not.

This will work equally well when we refer to members of the ref 
parameters.

ref int a(@result_tracks_scope_of A a) {
     return a.la.bala;
}

The crucial thing is that the compiler can simply infer these 
attributes when the implementation is available, so we won't have 
to issue errors when the user has not added them (if the code is 
available).