On Monday, 22 April 2013 at 12:22:14 UTC, Diggory wrote:
I realise I'm new here but this seems to be suggesting a whole
load of changes and special cases for something that can be
done in (IMHO) a much simpler way:
Why not simply make escaping a "ref" pointer an unsafe
operation. The compiler should be able to detect this and
report it without any changes to the syntax.
This should cover 99% of cases with no extra attributes
required and no limitations on what you can do with a "ref"
within the function. In the 1% of cases that a pointer needs to
be escaped safely you can add an attribute (maybe "heap ref" or
something, although perhaps some existing syntax could be used)
that requires the input to have been allocated on the heap.
In the case that a stack variable is passed as a "heap ref"
parameter the compiler can automatically promote it where
possible, or if that's not possible, such as the variable being
marked "scope" (existing meaning) then it should complain.
All values (including literals and temporaries) should then be
able to be passed to a "ref const" parameter.
As far as I'm aware the only real purpose for R-value
references is to implement move semantics. This could already
be done using "ref in" syntax, as that makes no guarantees that
the value is not going to be destroyed, only says that the
value should be initialised prior to it being passed in. The
only change would be to allow passing temporaries as "ref in".
To promise that the variable is not going to be modified "ref
const" or "ref const in" can be used.
This DIP already suggest 'in ref' besides 'scope ref'. 'in' is a
shortcut for const scope.
And Andrei already reject variants which _only_ consist of
non-mutable rvalue ref's (like const ref), because the const
system in D is physical.
But this could be read on the wiki. You should read the DIP
before you write here. ;)
