ref is unsafe

[Zach the Mystic]

On Sunday, 30 December 2012 at 22:02:16 UTC, Jonathan M Davis 
wrote:
> The closest that we could get to what you suggest would be to 
> add a new
> attribute similar to nothrow but which guarantees that the 
> function does not
> return a ref to a parameter. So, you'd have to mark your 
> functions that way
> (e.g. with @norefparamreturn). Maybe the compiler could infer 
> it for templated
> ones, but this attribute would basically have to work like 
> other inferred
> attributes and be marked manually in all other cases. 
> Certainly, you can't
> have the compiler figuring it out for you in general, because 
> D's compilation
> model allows the function being called to be compiled 
> separately from (and
> potentially after) the function calling it.
>
> And when you think about what this attribute would be needed 
> for, it gets a
> bit bizarre to have it. The _only_ time that it's applicable is 
> when a
> function takes an argument by ref and returns the same type by 
> ref. In all
> other cases, the compiler can guarantee it just based on the 
> type system.

I realized just now that it's also applicable to member functions:
struct F
{
   int _i;
   ref int ser() { return _i; } // Needs to be marked as well
}

A struct's fields are implicit parameters in anything it returns.

> Honestly though, I'm inclined to argue that functions which 
> return by ref and
> have a ref parameter of that same type just be considered 
> @system.

Structs mess that up as well:
struct S { int i; }
ref int d(ref S s)
{
   return s.i;
}