RFC: naming for FrontTransversal and Transversal ranges

[Andrei Alexandrescu]

BLS wrote:
> Question is, how this fits into a collection/container package.
> 
> ..So frankly, I don't worry about naming  conventions. I am more 
> concerned about ranges within a let's say dynamic d e queue.
> Lock free ADTs  are a final proof of product , no ?
> 
> Maybe I miss something.
> But fact is : D2 (Phobos) still don't have (not even in it's brand new 
> incarnation ) support for simple humpty dumpty collections. So Proof of 
> product is where ?

You're not missing anything, except for perhaps a little patience :o).

There is vivid discussion about container support in D2. I was actually
thinking of posting a RFC sooner or later here.

It is very exciting to realize that with minimal (and actually
simplifying) changes to the language we can offer the option of
garbage-collected vs. reference counted vs. "unsafe" semi-automatically
managed memory. Moreover, I realized that the global allocation model
only affects the built-in literal types such as T[] and T[U], but still
allows using the other models as library types.

It has become increasingly clear we'll need to support arrays in
addition to slices. One big question mark for me is, should we define
for arrays (and associative arrays and containers in general) value
semantics, reference counted value semantics, or reference semantics? It
is not clear to me yet what the best option is. Think of arrays as an
archetypal example.

1. Value semantics (arrays are like int)

+ Simple to reason about
+ No long-distance sharing of state
+ Familiar to refugees coming from C++ with STL
- Unfamiliar to Java/C# refugees
+ Relatively simple to implement
+ Good behavior as members inside structs and classes
- Bad behavior as function parameters: if you forget to pass by
reference, performance will be harmed

2. Value semantics with reference counting

+- All tradeoffs of value semantics, except as noted below
- Difficult to implement
+ Cheap to copy around, will "divide" only upon mutation attempts
- Innocuous operations may throw/occasionally take a long time

3. Reference semantics

- Hard to reason about: squirrel an array into an object, and way later
and farther it modifies the array and effects a change at long distance
- Long-distance effects may as well be some of the toughest bugs after
memory errors
+ Cheap to copy
+ Familiar to Java/C# refugees
- Less familiar to C++ refugees
- Potentially inefficient as people might start sprinkling copies in the
hope the eliminate bugs or chances of bugs
+ const system helps: if a function doesn't change something just mark
it as const and you're home free
+ immutable also helps: immutable data can never change so it can be
shared no problem. Not sure how interesting immutable containers are though.
- Implementing fast/unsafe semantics with reference semantics
effectively forces reference counting to be part of containers, which
complicates implementation.

Any thoughts, just share! For the record, Walter has a bias in favor
of... I'll better don't bias you guys.

One thing: it would be relatively easy to switch among semantics by 
defining a wrapper such as Value!(T) or Ref!(T). So whatever choice we 
make, it won't paint us into a corner.


Andrei