RFC: naming for FrontTransversal and Transversal ranges

[Michel Fortin]

On 2009-05-01 13:44:58 -0400, "Robert Jacques" <sandford at 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.fortin at michelf.com
http://michelf.com/