On Friday, 4 January 2013 at 20:20:08 UTC, Jonathan M Davis wrote:
On Friday, January 04, 2013 17:26:59 Zach the Mystic wrote:
> 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;
}
Yes. That's a function which takes a ref and returns by ref
just like I said.
It's just that in this case, the ref returned isn't the full
object that was
passed by ref but just a portion of it. What that means is that
you can't
assume that the ref being returned is safe just because the
type of the
parameter and the return type aren't the same. But it doesn't
change the
statement that a function which takes a parameter by ref and
returns by ref
can't be considered @safe without additional constraints of
some kind. It just
shows why you don't have an easy way out to make many of them
@safe based on
the differing types involved.
- Jonathan M Davis
Why this won't work?
1. If the function code is available at ct, we can check for
escaping locals.
2. Otherwise, we want to statically say to the compiler that the
returned ref is safe exactly in these lines in which the
particular function argument, from which the ref has been
extracted, has not yet gone out of scope. So the returned ref
safety guarantee tracks the argument safety guarantee.
Something like this:
ref int f(@infer_safe_from ref int a);
With such an annotation on an argument, the compiler will be able
to infer the safety of a function when used in cases in which a
is in scope whenever the returned ref is referenced.
Now, if f is used in this manner:
{
