RFC: naming for FrontTransversal and Transversal ranges

[Andrei Alexandrescu]

Robert Jacques wrote:
> Also, in a value semantics world, refs are third class citizens, but in 
> a reference semantic world, value semantics get their own assignment 
> operator ( []= ), and by convention, their own property ( .dup )

The major problem is not assignment. That can be taken care of. The 
problem is:

1. Passing an object into a function

2. Making the object as a member of another object

3. Yes, assigning to the object (which ought to be congruent with 1 and 2).

I have perused some more searches and documentation, and things don't 
bode well for references. Consider the PyNum library. I have searched

pynum pass by reference

and found some interesting links. The first reveals differences between 
numpy and matlab (notably reference semantics). The second is a 
discussion entitled "beginner confused with numpy". Guess what the 
confusion was about? Congratulations, you have won a 40'' LCD TV. 
Reference semantics!

Third hit: 
https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-March/011509.html

says:

 >> Octave's pass-by-value mechanism (with lazy copy-on-write) is
 >> something that is *far* more simple to grasp than NumPy's inherited
 >> everything-is-a-reference semantics. I do regard myself as moderately
 >> experienced Python programmer, yet every now and then I get shot in
 >> the foot by the reference semantics in Python.

I swear I didn't pay that guy.

Also, getting back to Perl's Data language (http://tinyurl.com/derlrh) I 
see the mention to references is clearly a WARNING, not an INTERESTING 
AND DESIRABLE FEATURE.

"It is important to keep the ``reference nature'' of piddles in mind 
when passing piddles into subroutines. If you modify the input pdls you 
modify the original argument,  not a copy of it. This is different from 
some other array processing languages but makes for very efficient 
passing of piddles between subroutines."

So what I'm seeing is that reference semantics is not desirable and not 
natural but was chosen for efficiency reasons. But you know, I don't 
want to "keep in mind" extra stuff when coding, I have enough to worry 
about. If I can get away with ref and/or refcounting, then I have taken 
care of the efficiency issue and I don't need to keep in mind a weird quirk.

============

About undue copying of data: maybe that could be avoided by having 
functions manipulate ranges (which are cheap to copy), not the 
containers that use them. In C++ you need to pass the container more 
often than not mostly because passing two iterators is amazingly 
burdensome. In D we can pass ranges easily, so I think much D code that 
wants to do stuff will just take ranges.


Andrei