On 2013-05-11, 13:12, Diggory 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.
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.
--
Simen
