RFC: naming for FrontTransversal and Transversal ranges

[Andrei Alexandrescu]

Robert Jacques wrote:
> Now, back on topic. I actually make heavy use of what amounts to structs 
> containing arrays and don't want a deep copy >90% of the time. In fact, 
> I haven't used any of the (my array-my array) deep copy functions and I 
> only do copying when I have to convert my arrays to D style arrays or 
> other container types. Also, D arrays are structs that contain C style 
> arrays and I almost never dup them in final code. When I debug/prototype 
> I do tend to use []= and dup more often. So I'd disagree that you'd 
> almost always want to make a copy. Second, I don't think we should 
> simplify the most common use case, but instead the majority of use 
> cases. This is partly semantics, but partly not: everybody uses 
> containers differently.

It must be a matter of style. Having used both semantics extensively, I 
personally think one never looks back after using value containers. When 
you fail to pass by reference there's a performance hit and a logic bug 
(changes are not effected). Both are local issues that manifest 
immediately, close to the place of the mistake, and are trivial to fix. 
But undue sharing is a global, long-distance issue - one much harder to 
tackle.

I agree that reference semantics is what people got used to in Java and 
other languages. For entity types, reference semantics make a ton of 
sense, but I think containers are not entity classes most of the time. 
But I also agree that through experience one can design around undue 
sharing. But it should be remembered that it took years to shake off 
security bugs in the JDK caused by undue sharing. (One that comes to 
mind was a sensitive linked list returned by a system API. User code 
could maliciously change it to mess with the system's security manager. 
Solution? They returned a compulsory copy of the list.)

So I'm not sure where this leaves us. I hear two good arguments:

* Some aren't bothered by reference semantics
* We are used to reference semantics from other languages

These are good arguments, but don't quite end the discussion.

> Also, Andrei, I would had preferred it if you had separated the 
> discussion on arrays from Phobos containers. Many languages have arrays 
> and a separate container library and I feel the decision of whether D's 
> arrays should behave like Phobos' containers would be best left to after 
> the best decision for Phobos is made.

*If* we add a new array built-in type, that will fundamentally affect 
Phobos because Phobos will design all containers to be like the pair 
array-slice. If we don't add a new built-in type, then I only have 
Phobos to discuss.

Also something that wasn't discussed that much is the connection of 
whatever design we devise, with the GC. I am mightily excited by the 
possibility to operate without GC or with tight reference counting, and 
I thought many around here would share that excitement. If we go for 
non-gc ways of memory management, that will probably affect container 
design.


Andrei