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

[deadalnix]

On Friday, 25 January 2013 at 15:32:13 UTC, mist wrote:
> 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.
>

No adress because :
  - it would now be impossible to ensure transition using & as 
NOOP.
  - this address is useless anyway. That'd be a pointer to a 
pointer to instructions.

I played with that using modified version of SDC, and this is 
clearly what does work best.

If you really need an address, you can do :
immutable f = function void() {};

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

funName is not a getter and don't return a delegate. How a getter 
behave is explained below. Mixing everything together is the 
perfect way to create a mess.

>> 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 ;)
>

You didn't addressed why @property. Answer you gave to point 5 
and 6 make me think you aren't aware of the ambiguities @property 
causes with UFCS. Please note that :
[1, 2].front and front = [1, 2] are semantically 100% equivalent.

I do agree that a getter returning void is weird, but that wasn't 
really important here.

>> 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".
>

The above code is rewritten ad funName()(t) . That is why you get 
that error message. The error message goes out before the 
compiler has even considered funName was used in a call 
expression.

Your proposal may be an improvement for that very case, but isn't 
in general the error presented above.

>> 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.
>

7a is required for 7b to work. That is not complication, that is 
simplification.

>> 7b. @property is deprecated and redefined as @setter *and* 
>> @getter for a transitional period.
>> 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!
>

Many people here disagree. I tend to be amongst thoses people. 
This specific case imply no ambiguity, and is similar to other 
simplification D already make like . dereferencing pointers.