Revised RFC on range design for D2

[Bruno Medeiros]

Agh, got busy in these last days, so I was missing the discussion.


Andrei Alexandrescu wrote:
> Bruno Medeiros wrote:
>> Andrei Alexandrescu wrote:
>>> Bruno Medeiros wrote:
>>>> Andrei Alexandrescu wrote:
>>>>> In wake of the many excellent comments and suggestions made here, I 
>>>>> made one more pass through the draft proposal for ranges.
>>>>>
>>>>> http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
>>>>>
>>>>> There are some comments in red illustrating some uncertainties (not 
>>>>> all), and the names of the primitives have been updated. Bicycle 
>>>>> shed galore! But don't forget to comment on the reactor as well :o).
>>>>>
>>>>>
>>>>> Andrei
>>>>
>>>> """
>>>> All ranges satisfy certain invariants outlined below. (r is an 
>>>> object of a range type R.)
>>>> """
>>>>
>>>> By "object" you actually mean struct no? Struct instance to be even 
>>>> more precise.
>>>>
>>>>
>>>> Also, some more on important bike shed issues:
>>>>     for (; !src.done; src.next)
>>>>     {
>>>>         tgt.put(src.head);
>>>>     }
>>>>
>>>> As a matter of coding style conventions, I would say that using the 
>>>> implicit property function call feature on a function that changes 
>>>> state is *bad* style, and surely hope the community would agree on 
>>>> that.
>>>
>>> I sure hope they won't agree to an unsupported assertion.
>>>
>>
>> It's unsupported because it is not an assertion, but more of a 
>> subjective opinion, like most coding style conventions (indentation, 
>> bracing, etc.). I don't like seeing "src.next" if 'next' isn't either 
>> a field, or a function which doesn't change any significant state.
> 
> I also don't like broccoli, but I eat it because there are reasons to do 
> so. Would you agree that given reason, you'd use it even if you 
> subjectively disliked it?
> 

Yes, if there where good reasons, I'd use it. But what are those reasons?

>>>> So "src.next" would be must better as "src.next()" as "src.next" 
>>>> really just makes me cringe.
>>>
>>> With me it's the opposite, particularly after I've written and stared 
>>> at a few hundreds of "()"s due to a compiler bug.
>>>
>>>
>>> Andrei
>>
>> I'm not imagining what that situation would be, could you explain a 
>> bit more?
> 
> I phrased things poorly. The compiler bug is that parens for array 
> functions in the postfix notation are required in some places and not in 
> others. So I was forced to write much more parens than were strictly 
> necessary, and all over the place. It gets really jarring. I've always 
> thought required parens were a big annoyance in C++, and I can't believe 
> people want to bring that back in D.
> 
> 
> Andrei


What I was trying to understand here, is that if the consistent usage of 
  '()' for function calling, instead of omitting them, had lead you to 
bugs. (bugs in your code, not bugs in the compiler)
In other words, were you presenting a reason for not consistently using 
parenthesis for function calling?

The only reasons I've so far seen you present in favor of omitting 
parenthesis where this ones:

"""
I _believe_ a language should obey the principles 1 and 2 (economy of 
syntax and giving syntactic priority to frequent use cases). Based on 
that belief, I _think_ D should drop the trailing parens.

I agree that somebody could _believe_ in some other principles that 
replace or override mine and then _think_ that keeping trailing parens 
is a good thing. Sergey did just that by showing us some very good 
examples when absence of trailing parens leads to ambiguity. Then there 
is room for meaningful discussion.

It is also possible that somebody simply _believes_ the trailing parens 
should be kept because they make code clearer to them. That's fair too, 
as long as there is understanding that that belief comes to a certain 
extent at odds with principles 1 and 2 (which anyone is free to simply 
not believe).

The only place that needs work is when the connection between belief and 
thought is unclear, or when the belief is simply wrong.
"""

I will reply in that respective post.


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D