RFC: naming for FrontTransversal and Transversal ranges

[Robert Jacques]

On Wed, 29 Apr 2009 20:45:23 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:
>
> It has become increasingly clear we'll need to support arrays in
> addition to slices.

No, Andrei it hasn't. A detailed paragraph (or more) explaining we you  
think so should be included in the full RFC.

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

Here are some additional pros/cons:

1. Value semantics (arrays are like int)
  +  can return static arrays from functions
  -  can be emulated with slice assign and .dup, where needed
  -  requires arrays and slices to be separate types
  +- requires opImplicitCast from container to slice type
  +- requires template argument deduction to be opImplicitCast/alias this  
aware
  -  If you forget to pass by reference (when you meant to), logical bugs  
are produced (i.e. my mutation doesn't get published).
  -  Dis-allows inheritance from all containers (i.e. implemented as  
structs)

I think clarifying 2 as being copy-on-write is useful.
2. Copy-on-write (Value semantics with reference counting)
  +- The added trade-offs of value semantics
  -  arrays may no longer be passed in registers (performance reduction)

3. Reference semantics
  ++ Allows arrays and slices to be the same type
  +  How D's arrays/slices work today
  +  Familiar to C/C++ refugees (Similar to plain old arrays)
  +  Familiar to most OO language refugees: containers are objects
  +  Allows inheritance from most containers (i.e. implemented as objects,  
except for arrays)

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

All these issues also exist with objects, which people are familiar with.

> - Implementing fast/unsafe semantics with reference semantics
> effectively forces reference counting to be part of containers, which
> complicates implementation.

I'm drawing a blank on this. My thinking is this;
1) garbage-collected:   reference counting isn't needed
2) reference counted:   reference counting is expected and built into  
objects in general.
3) "unsafe" management: safety is explicitly not expected, so reference  
counting isn't needed

My vote is for reference semantics. It's fast, familiar, easy to reason  
about (i.e. like objects) and doesn't require seperate array and slice  
types.