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

[Simen Kjaeraas]

On 2013-05-11, 13:12, Diggory wrote:

> Just listened to this talk and it made me think about the various type  
> qualifiers. Has there ever been any thought of introducing a new type  
> qualifier/attribute, "unique"? I know it already exists as a standard  
> library class but I think there are several advantages to having it as a  
> language feature:
>
> - "unique" objects can be moved into default, const, unique or immutable  
> variables, but can never be copied.
>
> - "new"/constructors always returns a "unique" object, which can then be  
> moved into any type, completely eliminating the need for different types  
> of constructors.
>
> - Functions which create new objects can also return a "unique" object  
> solving the problem mentioned in this talk of whether or not to return  
> immutable values.
>
> - "assumeUnique" would actually return a "unique" type, but would be  
> unnecessary in most cases.
>
> - Strings can be efficiently built in "unique" character arrays and then  
> safely returned as immutable without a cast.
>
> - The compiler can actually provide strong guarantees about uniqueness  
> compared to the rather weak guarantees possible in std.typecons.Unique.
>
> - It can be extremely useful for optimisation if the compiler can know  
> that there are no other references to an object. There are countless  
> times when this knowledge would make otherwise unsafe optimisations safe.

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.

-- 
Simen