On 11 May 2013 21:12, Diggory <diggsey@googlemail.com> 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.

This is a very interesting idea.
It would also be a massive advantage when passing ownership between threads, which is a long-standing problem that's not solves at all.
There currently exists no good way to say "I now give ownership to you", which is what you basically always do when putting a job on a queue to be picked up by some foreign thread.
Using shared is cumbersome, and feels very inelegant, casts everywhere, and once the casts appear, any safety is immediately lost.

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?