On 10/9/15 10:37 PM, Adam D. Ruppe wrote:
On Saturday, 10 October 2015 at 02:31:51 UTC, Martin Nowak wrote:
nothing to warrant the invasive language feature @property is.
There's no reason for @property to be invasive. ALL it needs to do is
handle that one case, it shouldn't even be used anywhere else.
Everything else is trivial or irrelevant.
And the beauty of this is it won't even break any code.
I honestly couldn't care less about this.
What I don't like is arbitrary setter property abuse. e.g.
somerange.find = needle;
My opinion:
Empty parens can always be omitted on functions, but need to be present
in order to call delegates/function pointers.
@property function on struct/class method enables the instance.method =
value; syntax. Otherwise, it's rejected (you must use
instance.method(value); syntax). If I were defining it from scratch, I'd
say you HAVE to use first syntax if it's marked @property, but I'm OK
with allowing the normal syntax on @property methods.
Since we have @property, slapping it on a getter that returns a
delegate/function pointer enables the behavior you want (why not?).
&instance.prop I'm unsure what it should mean. I'm leaning towards that
it means get a delegate to the property method itself, not the result of
calling the property. This makes it behave differently than a field, but
it already does this today.
@property on module level functions operate like methods, but allow UFCS
calls. So:
0 params -> Obviously, like a getter (see above).
1 params -> Allow func = val syntax. Other syntaxes still allowed.
Calling val.func syntax, if returning a delegate, I think should require
the double parens, since IMO @property is for the setter syntax, not a
description of a UFCS call.
2 params -> Allow firstParam.func = secondParam syntax. Other syntaxes
still allowed.
-Steve
