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
