Beta D 2.069.0-b1

[Steven Schveighoffer via Digitalmars-d-announce]

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