@property - take it behind the woodshed and shoot it?

Sönke Ludwig sludwig at outerproduct.org
Thu Jan 24 05:28:31 PST 2013


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.




More information about the Digitalmars-d mailing list