DConf 2013 Day 1 Talk 2 (Copy and Move Semantics)

[Simen Kjaeraas]

On 2013-05-12, 02:36, Diggory wrote:

>> Temporary copies are fine. Only those that escape the function are
>> problematic.
>
> The problem I had with this is that it temporarily breaks the invariant  
> on the calling code's "unique" variable. For the duration of the  
> function it is no longer unique.

This is basically the same as with D's @pure. You may break purity as
much as you like, as long as no side effects are visible *outside* the
function.


> One way to not break the invariant would be to imagine it as first  
> moving the value into the function when it is called, and then moving it  
> back out when it returns.
>
> Obviously it may not be good to actually implement it this way, but all  
> that is necessary is to make accessing the original variable before the  
> function has returned, undefined. In most cases the only limit this  
> imposes is not passing a "unique" variable for more than one argument to  
> a function.

Hm. I didn't think of that. I believe passing the same unique value twice
should be fine, as long as both are lent. Obviously, in the case of
non-lent, passing it twice should be an error (probably not possible to
statically determine in all cases, so a runtime error occasionally, or
just go conservative and outlaw some valid uses).


> The problem is when there is a global "unique" variable being passed to  
> a function. Perhaps in this case the compiler could actually emulate the  
> move operation in and out of the function by temporarily clearing the  
> global for the duration of the call so that it can't then be accessed by  
> the function, thus maintaining the unique invariant.

I believe you're overthinking this. First, what is global unique variable?
A unique value will per definition have to be thread-local (if not, other
threads have a reference to it, and it's not unique). Thus, when passed to
a function, the value is inaccessible outside of that function until it
returns. (I guess fibers might be an exception here?)

-- 
Simen