Revised RFC on range design for D2

[Christopher Wright]

Steven Schveighoffer wrote:
> "Andrei Alexandrescu" wrote
>>> P.S. If src.next() is too lengthy, why not just adopt ++src?
>> Because people (in wake of the recently introduced array operations) may 
>> legitimately expect that to mean "increment all elements of src".
> 
> So in one case, you believe people's assumptions aren't important, i.e. an 
> assumption that .next without parens will not change anything on the object, 
> yet in another case you believe people's assumptions are the main argument. 
> This doesn't sound consistent.

What if it were src.advance instead? Since it's a verb, it's easier to 
associate it with an action that might change state rather than simply 
reading the state of src.

As for ++src, I really dislike using that operator overload for an 
"advance" function. I'd sooner think that src was a fat reference of 
some sort and calling ++src would increment its value. That said, when 
I'm working with C or C++, I prefer indexing to pointer manipulation, 
and I don't use STL collections when I can avoid it, so it's largely a 
matter of experience.

> Not that I care too much :)  I am also in the camp of 'defined properties 
> should be a language feature,' but I admit to using D-properties quite 
> often.

Properties are good. For one thing, you can get better error messages, 
like "No set accessor for  Foo.Bar" rather than "Foo.Bar() does not 
match the given parameters (int)".

> The two things that bug me the most about D property syntax:
> 
> stuff like this:
> 
> x;
> 
> What the hell does this mean?  It looks like it does nothing.  But it could 
> be a function call.  If explicit properties were required, and x was defined 
> as a function, not a property, then x; would be a syntax error.

For me, I use the no-parentheses version in either of these cases:
1. I'm using the function as a property (auto name = field.name).
2. The function name is a verb (mocks.replay).

This seems reasonably unambiguous in my personal experience, though it 
helps that I have few locals in most of my methods and use a prefix for 
private members.