On 2009-05-01 13:44:58 -0400, "Robert Jacques" <sandf...@jhu.edu> said:
I think you might of misunderstood the concept of a unique/mobile type. If you take a slice or a reference of an unique, you null the source. Which makes using unique T logically invalid as a container.
Take note: I'm not expecting it to copy automatically, "unique T[]" isn't a value-type container. I'm solving the problem of slices detaching from one another when you grow them, which I don't think is a problem addressed by value-type containers either. If you grow the slice or container, previously-taken slices of it may or may not be left dangling. Allowing grow only on "unique T[]" makes sure there are no slice to be invalidated when you grow.
Also, generally type systems featuring unique also have that "lent" flag allowing you to pass the unique reference to functions which are required to not keep it anywhere after the function returns. So you could pass lent slices of your unique T[] to functions without breaking uniqueness of the reference.
Also, shared unique T can't be converted to shared T. This incompatibility is the whole point of having a unique type in the first place, and negates your concept of using unique T as containers.
Why couldn't it? You just lose (forever) the uniqueness of the reference when you copy it to a non-unique one.
And generally, unique T implies shared storage, and can not be used for thread-local arrays.
Generally, but not necessarily. Any problem for unique be applicable to thread-local arrays?
-- Michel Fortin michel.for...@michelf.com http://michelf.com/
