On Saturday, 27 April 2013 at 23:38:53 UTC, Diggory wrote:
The keyword 'scope' is very well defined at the moment - it
means among other things that the value cannot be returned.
It's only defined very briefly in the "functions" section of the
documentation. And it's only implemented for 'scope' delegates,
because they get a clear benefit. Making 'ref' safe, despite how
important it is, is not yet encoded in stone. DIP25A has been
admitted by its author to be an aggressive solution. But there
are several possible approaches to dealing with that, IMO. The
most immediate is to simply force the author to mark any function
which violates the rules '@trusted'. In other words, sweep all
unsafe cases under the umbrella of the existing @safe-D
framework. Perhaps the only reason to consider anything else is
that the number of functions which will have to be marked
'@trusted' will be too high.
I think it's important to decide whether '@trusted' is adequate
to address 'ref' safety before getting to the next step. I even
think that a full implementation of DIP25A, as is, would help to
determine for people just how many functions they will be forced
to mark '@trusted'. Only if '@trusted' really ends up being too
blunt should attributes be considered, IMO.
That being said, 'scope' might be the right tool for the job. Or
'out' return values. I'm not under the impression that 'scope'
*must* be used to solve the problem. For example, there are even
more than one way to escape a parameter, and they're not all
equal.
ref T func(ref T a, ref T* b) {
return a; // Escape by return
static T* t;
t = &a; // Escape by global assign
b = &a; // Escape by parameter assign
}
'scope' is only one attribute, yet there are three different
types of escape here. That's why I don't want to jump in
completely on 'scope' banning all three.
