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

[Diggory]

On Saturday, 11 May 2013 at 22:24:38 UTC, Simen Kjaeraas wrote:
> 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.

OK, I see that we need a way to accept unique values without 
enforcing them.

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

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.

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.

> Can you detail the process involved in assignment from one 
> unique to
> another unique? Would the original unique be destroyed? Leaving 
> only the
> 'copy' remaining?
Yep, it would just be standard "move" semantics, same as if you 
initialise a variable with an rvalue.

> It's been brought up quite a few times (it might have even have 
> been brought
> up by Bartoz ages ago - I don't recall for sure). The problem 
> is that it
> complicates the type system yet further. We'd have to find a 
> way to introduce
> it without impacting the rest of the type system much or 
> complicating it much
> further. And that's a tall order. Not to mention, we already 
> have a lot of
> attributes, and every new one adds to the complexity and 
> cognitive load of the
> language. So, we have to be very careful about what we do and 
> don't add at
> this point.
>
> - Jonathan M Davis

The main change to existing code would seem to be adding "scope" 
or "lent" to parameters where relevant so that unique values can 
be accepted. It only makes sense to use it for ref parameters, 
classes and slices, so it's not like it would need to be added 
everywhere. Interestingly that's yet another optimisation that 
can be done - if a slice is unique it can freely be appended to 
without some of the usual checks.

With regard to lots of attributes, I think a language which tries 
to be as much as D tries to be is going to end up with a lot of 
attributes in the end anyway. With a combination of better IDE 
and compiler support for inferring attributes, it shouldn't cause 
too much of a problem - attributes are generally very simple to 
understand, the hard part is always knowing which one to apply 
when writing library code.

It's not just for the benefit of the compiler either - attributes 
help get across the intent of the code rather than just what it 
does and can be very powerful in ensuring correct code.