RFC: naming for FrontTransversal and Transversal ranges

[Robert Jacques]

On Sat, 02 May 2009 06:23:46 -0400, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> 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.

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.