On Sat, 02 May 2009 06:23:46 -0400, Michel Fortin
<[email protected]> wrote:
On 2009-05-01 13:44:58 -0400, "Robert Jacques" <[email protected]> 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.
By the way, the canonical system with a unique/mobile type (CSP) doesn't
have a lent flag. It lets you circumvent uniqueness instead. Scope/lent's
definitely better :)
Hmm... lent functions are a fairly restrictive subset, if you consider
unique T[] to be long lived. However, in the more common string builder
style of programming, it works just fine. (Though people will still want a
capacity field). So maybe an array type with unique semantics and a
capacity field is what's warranted (either language or library type).
Would you also allow T[] ~=? i.e. x~=y; => x = x~y; which is less
efficient but still valid.
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.
The whole point of unique is that it lacks any sharing protection
mechanisms. Instead the object is protected by the fact that only one
thread has access to it at a time. You could design the system so that
uniques could be casted to local objects (I don't think it's a good idea,
but you could), but casting them to shared objects is a recipe for
disaster, due to races, etc.
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?
Nope, the implication comes from the standard use case of cheaply passing
data between threads.
