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

mist none at none.none
Fri Jan 25 07:32:12 PST 2013


On Thursday, 24 January 2013 at 13:41:42 UTC, deadalnix wrote:
> For regular functions :
> 1. funName is the function itself :
>   void funName() {}
>   static assert(is(typeof(funName) == void function())); // 
> Pass.
>   funName has no address, it is equivalent to enum function 
> void() funName = {};
>   &funName become a NOOP and is deprecated, for compatibility 
> reasons. It is not ambiguous as funName has no address anyway.
Agree with differentiation but why no address? For me funName 
looks like function pointer variable, why prohibiting to cast 
this to raw address? &funName is legacy, agree.

> 2. funName() call the function.
And if funName is a getter returning delegate?

> 3. @getter is an attribute. A function marked @getter is 
> automatically executed : () is added automatically :
>     @getter void funName() {}
>     funName; // function get executed.
>     funName(); // Error, void is not callable.
Agree, but @property is enough. I ll insist below that ambiguous 
cases should be simply an error. And I'd also like to prohibit 
getters returning void ;)

> 4. @getter can be used as UFCS.
>    @getter void funName(T t) {}
>    T t; t.funName; // function gets executed.
>    funName(t); // Error, funName require 1 argument, 0 given.
Fine by me, but error message is weird. Better "Error, funName is 
not usable with free-from syntax".

> 5. @setter is an attribute. A setter method can *only* be used 
> in rhs of an expression. The assigned value is used as argument.
>    @setter void funName(T t) {}
>    T t; funName = t; // function gets executed.
>    funName(t); // Error, funName must be used in an assign 
> expression.
Disagree, it is inconsistent with getter.  @property ... 
funName(T t ... ) should always behave as t.funName property. It 
is unnecessary complication.

> 6. @setter can as well be used as UFCS :
>    @getter void funName(T t, U u) {}
>    T t; U u; t.funName = u; // function gets executed.
>    t.funName(u); // Error, funName must be used in an assign 
> expression.
And this is exactly the syntax I'd like to see. Again, as void 
return should be disallowed for getters, no ambiguity here and 
same @property suits just fine.

> 7a. A function can be defined as both @setter and @getter, and 
> cumulate both behavior.
Feels like unnecessary complication. But if you want to, simply 
having both return type and 2 parameters is enough.

> 7b. @property is deprecated and redefined as @setter *and* 
> @getter for a transitional period.
;)

> 8. method behave as functions :
>     class A { void foo() {} }
>     A a;
>     static assert(is(typeof(a.foo) : void delegate())); // Pass.
>     &a.foo; // deprecated NOOP for compatibility.
>     a.foo(); // call a.foo
Agree;

> 9. UFCS without () are delegate like construct :
> 10. To allow chain of UFCS calls without () everywhere, an 
> opDispatch is defined in object.d
Very complicated for no real gain. Just prohibit function call 
without (), including (). Profit!

> Waiting for the shitstorm . . .
Welcome ;)


More information about the Digitalmars-d mailing list