Revised RFC on range design for D2

[Andrei Alexandrescu]

Sergey Gromov wrote:
> In article <gbgpak$2q10$1 at digitalmars.com>, 
> brunodomedeiros+spam at com.gmail says...
>> 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.
>> So "src.next" would be must better as "src.next()" as "src.next" really 
>> just makes me cringe.
> 
> I think that property function call feature in general adds an 
> unnecessary ambiguity to the language.  I'd prefer functions to be 
> callable only with regular function call syntax, and properties be 
> usable only with member access syntax.  The same stands for 'unified 
> function call' feature: if you want to inject a method into an 'array of 
> chars' class you do so explicitly, and only the member call syntax is 
> allowed on that method.  Otherwise code tends to become ambiguous and 
> unreadable.

Experience with other languages has shown that using identical syntax 
for genuine member access and member function access helps 
maintainability because it allows a type implementer to switch back and 
forth between implementing a property as a direct member or as a 
function, transparently to that type's use.

Two nice examples of the undesirability of distinct notation are the 
std::pair first and second members in the STL, which made what seemed 
like an innocuous decision turn into a catastrophe, and also 
std::numeric_limits<T>::min and max, which partially prompted creation 
of an entire language feature(!).


Andrei