On 2013-05-12, 05:16, Diggory wrote:
On Sunday, 12 May 2013 at 01:16:43 UTC, Simen Kjaeraas wrote:
I believe you're overthinking this. First, what is global unique
variable?
A unique value will per definition have to be thread-local (if not,
other
threads have a reference to it, and it's not unique). Thus, when passed
to
a function, the value is inaccessible outside of that function until it
returns. (I guess fibers might be an exception here?)
While in the function, that function can access a value both through the
global variable which is supposed to be "unique" and through the lent
parameter. This could cause problems because "unique" no longer means
"unique", although it's difficult to see how serious that might be.
Ah, like that. That's the same problem as passing the same unique value
twice as a parameter to a function, I believe. Let's try:
class A {}
unique A globalA;
A globalNonUnique;
void foo() {
bar( globalA );
}
void bar(lent A localA) {
globalNonUnique = globalA;
// Where the good stuff happens.
}
At the point of the comment, globalA is null, because of unique's rules.
localA is still what it was, because it's lent, which gives no uniqueness
guarantees, only that no new, escaping references be created.
If the parameter had been marked unique instead of lent, globalA would
have been cleared upon its value being passed to the function.
I believe the elephant in the room is lent return values:
lent A baz(lent A a) {
return a; // Obviously illegal - a new alias is created.
}
lent A qux(ref lent A a) {
return a; // Sets a to null and returns its old value?
}
--
Simen
