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.
