Revised RFC on range design for D2

[Steven Schveighoffer]

"Andrei Alexandrescu" wrote
> 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.
>
> Of course it is. One expectation has to do with operational consistency 
> (albeit a tad far-fetched), the other has to do with being used to a 
> mistaken decision in the C language design.

You are assuming that the C language decision to require parentheses for all 
functions was a design mistake.  I would argue that the design was on 
purpose and correctly served that purpose.  The purpose was to remove 
ambiguity when faced with understanding code without all the context.

But that isn't even the questioned practice here.  C designers didn't even 
come across the question of whether an accessor-property should imply no 
changes to the object, because they don't have properties.  The real problem 
is that no matter how you define next(), you can use it in a way which makes 
it appear like an accessor, not a function which modifies the object.  The 
source of the problem is D's lack of expressiveness, where I cannot define 
whether a function cannot be used as a property.

Even with a true property definition syntax, you cannot prevent someone from 
changing an object while inside an accessor, that should be defined by the 
constancy of the object in question.  But indicating that it is preferred to 
use the property-style means to access the next() member function seems to 
be misleading to some people.

The problem I have with your argument is how you used one case to say 'this 
is misleading to people, so it's not a valid solution', and in another case 
say 'it's only misleading because you are used to it, that doesn't matter.' 
The assumption of which people are important to please is the issue.  I 
understand you can't please everyone, but you shouldn't use the 'people 
won't like it' argument without real evidence or proof.

>> 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.
>>
>> 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.
>
> And what would be the advantage? I routinely use writeln; without feeling 
> it makes for inferior style.

The advantage is not to you, it is to the reader of your code.  writeln; is 
a complete misuse of property syntax, and IMO should not be allowed. 
writeln is not a property, and shouldn't be used like a property.  I 
routinely use Tango's Stdout.newline; which I admit goes against what I am 
saying, but it's because I know what Stdout.newline does, and that it is a 
function.  I would gladly change everything to Stdout.newline() if it was 
required.

The problem is not that you or anyone might forget that writeln is a 
function and not a property, the problem is when you start using the 
property syntax to call functions that aren't so standard, someone reading 
the code will be confused as to what the code is supposed to do.

The advantage is, you are able to define how a symbol behaves, what the 
rules are for using it.  It makes for clearer code.

-Steve