RFC: naming for FrontTransversal and Transversal ranges

[Jason House]

Andrei Alexandrescu Wrote:

> 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

I'm a C++ refugee and value semantics make no sense to me. I always declared classes (as part of function declaration) in C++ with a &... Either T& or const T&. There were plenty of bugs where I messed up and forgot the &. D is nice in that it tries to simplify that. You yourself had issues with remembering ref parameters when implementing ranges!