DIP 36: Rvalue References

[Zach the Mystic]

On Monday, 22 April 2013 at 12:22:14 UTC, Diggory wrote:
> 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.

In other words, 'scope' would be the default and require no 
explicit attribute. The first thing about this is the question of 
how much code it would break. I don't know the answer. Maybe a 
mockup of this idea could be used to create a sense of how badly 
it breaks existing code. The second question is how desirable is 
it as a feature. I think it may be quite desirable to have all 
refs be 'scope' by default, because the most common case will be 
the default, that refs will not be assigned to globals. Since 
there is a difference between the safety of returning by ref and 
the safety of assigning to heap or global addresses, there may 
need to be a distinction made between these two types of 'escape'.

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

'@noscope ref' has also been suggested, since the reference in 
question would also need to include static global data.

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

This is interesting to me. The only drawback I can think of is 
the aversion people have to introducing code which could secretly 
allocate, since many people want to avoid the garbage collector. 
It would only be an issue if the automatic promotion looked so 
much like a normal function call that it was extraordinarily 
difficult to distinguish it.

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

The only existing definition of 'in' is that it means 'const 
scope', so it already means scope. I don't know if that is a good 
definition or not. I think that there remains a significant fear 
in this community of introducing changes which will break 
existing code. I don't myself know how justified this fear is, 
but it is nonetheless something to take very seriously when 
proposing new ideas.

> I realise I'm new here

I'm new too. I'm glad to be able to have this discussion with you 
despite both of our being new. :-)