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.
