Function call without parentheses?

[Rainer]

== Quote from Jonathan M Davis (jmdavisProg at gmx.com)'s article
> On 2011-05-09 12:33, Rainer wrote:
> > Hi,
> >
> > why is it possible to leave out parentheses when you call a function?
> >
> > This is pretty error prone :(
> >
> > class Dummy {
> >     private bool isValid;
> >
> >     ...
> >     bool isValid() {
> >         return this.isValid;
> >     }
> > }
> Originally, any function could be treated as a property function if it had the
> right signature for it. That's primarily functions which return something but
> take nothing (which are treated as getters) and functions which return nothing
> and take one argument (which are treated as setters) - though there are a few
> valide variations. As such, a function such as isValid is treated as a
> property function and can be called without parens. This behavior is rather
> messy and does cause certain problems (such as issues when a getter returns a
> delegate), so @property was introduced.
> Per TDPL, any function marked with @property is treated as a property function
> and _must_ be called with the property syntax (so, no parens), and any
> function which is _not_ marked with @property is _not_ a property function and
> _cannot_ use the property syntax (so, it must use parens). dmd has not yet
> fully implemented everything in TDPL - including this. dmd has @property, but
> it's not enforced. The old rules still apply.
> Now, some folks have been complaining about this strict enforcement of
> @property and want it to be laxer (enforcing property syntax for property
> functions but not requiring parens for non-property functions), which would
> still allow for isValid to be called without parens. So, it's not entirely
> clear what's going to happen with the enforcement of @property, but I expect
> that strict enforcement will eventually be put in place. Regardless, various
> compiler bugs will need to be addressed before @property can be enforced.
> So, for now, you can use property syntax with functions not marked with
> @property, because that's how property syntax was initially implemented.
> - Jonathan M Davis

Thanks for the explanation.  I'm new to D and I haven't learned the @property syntax yet.

The problem is that it took me hours to find this simple bug.  I wouldn't have named
the variable and method both isValid myself, but this piece of code is coming from Java
where variables and methods can have the same name since method invocations always require parentheses.

In C++ this wouldn't compile since all members--be they variables or methods--have to be named uniquely.

Here you can't tell from looking at the code what isValid actually refers to.  It doesn't look like a clean design.
I would never have thought that this method actually calls itself.  How would I access the variable isValid here?

Debugging doesn't work all that well under Linux which made it even more difficult to find the error.
Add to that the fact that the stack probably had been corrupted from the recursive method call (stacktrace pointing to
something unrelated) and you're this close to giving up on this language.

I'd rather have the compiler issue an error or warning when you have a variable and method with the same name since you
can't access the variable anyway.

If property will be enforced I reckon that plenty of code is going to break.  IMHO it doesn't look like a feature which is
worth the trouble and confusion it causes.

Cheers,
Rainer