DIP23 Counter Proposal
deadalnix
deadalnix at gmail.com
Thu Feb 7 20:22:45 PST 2013
On Thursday, 7 February 2013 at 13:56:17 UTC, Steven
Schveighoffer wrote:
> On Wed, 06 Feb 2013 21:53:25 -0500, deadalnix
> <deadalnix at gmail.com> wrote:
>
>> On Wednesday, 6 February 2013 at 21:30:10 UTC, Timon Gehr
>> wrote:
>>>> &(fun, fun)
>>>>
>>>
>>> Agh, comma strikes again. It should be handled analogous to
>>> the ternary expression. i.e. the expression above evaluates
>>> fun and then returns the function pointer. The DIP now states
>>> this. (the second fun is in address-taken position.) This is
>>> in agreement to how lvalue positions propagate into comma
>>> expressions.
>>>
>>
>> Adding more special cases are not gonna create a good DIP.
>
> I don't they are so much a special case, as they are a
> clarification.
>
> The two "exceptions" are simply explaining that because ternary
> operator and comma operators evaluate to an lvalue, it is
> equivalent to putting the & on the resulting lvalue.
>
You have the following behavior :
- & take the address of what is before.
- foo is call to function foo.
- special case : &foo is the first class function foo. (here
expression foo have a new meaning).
- In a comma expression, if the last item is a function, it is
evaluated, unless the comma expression is in an address of
context, in which case the function pointer is returned.
- Same goes for ternary, except that both branches are evaluated
in that context.
This is exactly how special case (3) turtle down to definition of
many other languages constructs. For instance,
int a;
int foo() { return a }
static assert(is(typeof(foo) == typeof(a))); // Pass
condition ? foo : a; // OK.
&(condition ? foo : a); // Type error between foo of
unexpressible type (static array of instructions) and a of type
int.
More information about the Digitalmars-d
mailing list