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