Sergey Gromov wrote:
Fri, 31 Jul 2009 21:37:06 -0500, Andrei Alexandrescu wrote:
To clarify: if there was any extra checking by the compiler, any
guarantee that the feature would provide at all, I'd be glad to pay the
price of thinking more when putting together a design. But you want to
define a language feature that allows people to require "()" or not as
they please, and that's all. It's a frivolous detail to be spending time
on when designing an API. I simply don't believe that's good language
design.
That's not "all." To me it's mostly maintainability.
If there is a property 'foo' and you allow to set it both as 'foo = 5'
and 'foo(5)' then somebody *will* use the foo(5) form. Making it hard,
or even impossible for you, the maintainer, to switch from a property
back to a regular field for 'foo'.
If you allow to call function 'bar()' both with and without parentheses,
and a project is maintained by more than one person, they *will* call it
differently making the source look inconsistent.
Dropping the 'omittable parentheses' thing happens to solve these, and
the delegate return problem, and helps to disambiguate words with
overloaded meanings.
Thanks for these great points. As an additional example, most ranges
define the method
bool empty() { ... }
whereas infinite ranges define the enum
enum bool empty = false;
It follows that if a range user wants to be compatible with finite and
infinite ranges, they always must use no "()". It would be nice if the
range's definition could enforce that.
Andrei
