DIP 36: Rvalue References

[Namespace]

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