RFC: naming for FrontTransversal and Transversal ranges

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Fri May 1 11:00:35 PDT 2009

Robert Jacques wrote:
> Lastly, what you're trying to fix is a bug in the implementation of 
> arrays (see my posts in this thread) and not a bug in the design.

I think your fix to the array-slice conflation is simply to make slices 
arrays by adding extra information. This approach is reasonable, but (1) 
will make slices bigger and slower, and (2) will port very poorly to 
most other containers.

Code using ad-hoc arrays in C often had to pass two words around 
(usually pointers+length). Similarly, code using iterators in C++ must 
pass two pointers/iterators around (begin+end). With D, we have a 1-1 
correspondence of that situation with slices, which makes for a great 
argument on why a slice that contains two boundaries is an awesome way 
to encapsulate a concept at no efficiency cost. Adding a third word to 
the slice would mark a step backwards in terms of data being trafficked 
around, and a questionable increase in expressiveness. An obese 
three-words slice would avoid stomping over other slices upon append, 
but would still exhibit a rather unpredictable append behavior: a 
function taking a slice and appending to it may or may not publish its 
changes to its caller.

A good design is to have containers and ranges, not container_ranges.


More information about the Digitalmars-d mailing list