Revised RFC on range design for D2

[Yigal Chripun]

Andrei Alexandrescu wrote:
> 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

I've got a few questions regarding this:
suppose D gets a specific syntax for properties like C# has:
for example:
class MyClass {
private int x;
public int X {
  get {
    return x;
  }
  set {
    x = value;
  }
}
}

wouldn't it solve the problem of the implementer switching between a
direct member and a function, transparently to that type's use?
In the above you could remove the data member and re-implement the
get/set by calling suitable functions.

my main question is of style:
is it better in your opinion to allow all functions with no parameters
to be called as "function_name;" (i.e. no parens) and if you need to
refer to the function identifier itself you need to do &func (for
example if you want to pass it as a parameter to a different function)
OR
require an operator such as parens to signify you call the function and
the name without parens will just signify the function itself (so no
need to use &func when func is a parameter) ?