Am 24.01.2013 09:34, schrieb Walter Bright: > This has turned into a monster. We've taken 2 or 3 wrong turns somewhere. > > Perhaps we should revert to a simple set of rules.
I think Adam D. Ruppe has proposed this in the past and, although I don't really like omitting parentheses on ordinary function calls in general (apart from UFCS template functions), it's clear, simple and I think everyone could be happy with it: 1. Normal function calls _may_ omit parentheses, but "a = b" is _not_ interpreted as "a(b)" 2. @property functions can _not_ be called with parentheses and "a = b" _is_ interpreted as "a(b)" 3. Calling a normal function always returns its return value > > 1. Empty parens are optional. If there is an ambiguity with the return value > taking (), the () go on > the return value. This sounds like a recipe for disaster. Thinking about generic code calling functions... it would surely be very surprising to see how f() sometimes does not return ReturnType!f, but something completely different. It would also break all existing code that currently expects f() to simply return its return value. More importantly, adding or removing an opCall or changing the return type of a function would possibly silently change the meaning of code that calls the function. IMO it is also utterly unexpected/counter-intuitive for a seeming function call not to return its return value, but call it and return the result. > > 2. the: > f = g > rewrite to: > f(g) > only happens if f is a function that only has overloads for () and (one > argument). No variadics. I can live with omitted parentheses (*). However, what's really ugly is picking the unintended form in case of a setter (i.e. both, "obj.prop(value)" instead of "obj.prop = value;", or "countElements = obj;" instead of "obj.countElements()"). And in my experience, people /will/ mix the different forms all over the place. So although I know that some people have a different opinion, I still find it a very useful thing to be able to force correct usage up to a certain degree - stylistically and to avoid ambiguities (not only for the compiler, but also for a human reader). Adam's proposal solves this nicely and it's about as simple as it gets. (*) IMO they are kind of ugly semantically if they are omitted for anything else than properties or UFCS-template functions, but you may well call that a matter of taste > > 3. Parens are required for calling delegates or function pointers. > > 4. No more @property.
