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).
