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

[Simen Kjaeraas]

On 2013-05-11, 23:40, Diggory wrote:

>>
>> unique is interesting, and holds many promises. However, its effects may
>> be wide-spanning and have many corner case.
>>
>> In addition to mutability, unique applies to shared/unshared - a unique
>> value may safely be moved to another thread.
>>
>> Pure functions whose parameters are all unique or value types will  
>> always
>> return a unique result. (Note that this is similar to how pure function
>> results are now implicitly castable to immutable, but unique is  
>> stricter)
>>
>> For unique values not to lose unicity when passed to functions, there
>> must be ways to specify that the function will not create new aliases to
>> the passed value. scope might fit the bill here, otherwise something  
>> like
>> lent must be added.
>
> That's solved by the rule that "unique" values can only be moved not  
> copied.

What is? The last part?


> To pass a "unique" parameter by value to a function the original must be  
> invalidated in the process. The only other way would be to pass by  
> reference, in which case the function argument must also be declared  
> "unique".

In which case we end up with duplicates of all functions to support both
unique and non-unique parameters. Hence we'd need scope or lent.


> The rule about pure functions returning "unique" is not in general true  
> - if it returns a class which has a pointer to itself, or a pointer to  
> another class which has a pointer to itself then the return value is not  
> unique. The return value must specifically be declared unique.

I'm not convinced. unique, like const or immutable, is transitive. If foo
is unique, then so is foo.bar.


> The only problem I can see is with the "this" pointer:
> - If we have unique and non-unique functions it means duplicating  
> everything, or at least remembering to add the "unique" attribute.
> - Unique would then be both a type modifier and a function attribute
> - It's not immediately obvious what operations can be performed by a  
> "unique" member function.
> - It is not simply equivalent to marking the "this" parameter as unique  
> because that would mean erasing the argument passed in for that  
> parameter, ie. invalidating the object!

Look above again. With 'lent', the function guarantees not to create new,
escaping aliases. Thus, a unique value may be passed by ref (e.g. the
'this' pointer) without erasing the value.

The syntax would thus be:

class A {
     void forble() lent {
         globalValue = this; // Compile-time error.
     }
}


> But I think that can also be solved satisfactorily:
> - Make the unique-ness of a member function something which is  
> implicitly determined by the compiler based on its content.

Won't work. The function body is not always available.


> - Any function which only dereferences the "this" pointer can safely be  
> marked "unique" internally, and therefore can be called on a unique  
> variable. If it copies the "this" pointer (auto x = this) then it is not  
> "unique".

Temporary copies are fine. Only those that escape the function are
problematic.

-- 
Simen