On Sunday, 28 April 2013 at 16:56:26 UTC, Diggory wrote:
It's quite clear to me that no mathematical model for ref
safety will be able to cover every possible case without
seriously degrading performance. Therefore the best we can do
is come up with a model which covers as many of the common
situations as possible and rely on "@trusted" to handle the
(hopefully small) number of cases which cannot be handled by
the model.
This is my thinking also.
One rather bad thing about the '@trusted' method is that it's not
the called function itself which is unsafe, but only escaping the
*returned ref*, and so '@trusted' would most accurately have to
attach to the *calling* function, which I think will become
untenable rather quickly.
ref T func(ref T a); // Safe in and of itself
@trusted ref T fun2() {
T b, c;
b = func(c); // safe
return func(c); // not safe!!
}
Since func() has no additional attributes and is invisible,
there's no way at all for the compiler to know what it returns.
Yet the actual unsafe action only occurs in fun2(), which makes
it easy to see how unwieldy the system could get, having to mark
the calling function just because it does something which *could*
be unsafe.
Looking at the above case makes it seem like at least one
additional attribute, located in the function signature, must be
accessible to the compiler in to order to reduce the number of
functions which must otherwise rather gratuitously be marked
'@trusted'. Even with a single new attribute, 'out', which
attaches to the function (and does not specify precisely to which
parameters it refers) I suspect a huge number of frustrating
cases would be taken care of. 'out', of course, simply assigns
'@noreturn' to all its parameters, even if '@noreturn' itself is
not allowed!
