Revised RFC on range design for D2

[Andrei Alexandrescu]

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?

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