Revised RFC on range design for D2

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> "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.

I have stated my assumption and its basis. What is the basis of yours?

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

I understand your argument, but it hinges on its own definitions and 
assumptions. You define "accessor" and then complain that something 
looks like one unexpectedly. Well in some languages a.b does not change 
anything. In others it does. What gives?

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

So that further weakens your argument.

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

I agree that ++array may not be easily confused with ++array[]. The 
situation I am trying to help is improve on a mistake in the C language 
design that we got so used to, we actually think it's the right thing.

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

Aside from just saying it, do you have any substantive argument?

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

To what benefit? You seem to be using it today, and that makes your own 
style incongruent with your argument, yet surely you'd change the style 
in an iffy if you thought it has serious drawbacks.

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

I am not sure.


Andrei