Properties no longer work?
BCS
BCS at pathlink.com
Thu Jul 27 15:56:06 PDT 2006
Jarrett Billingsley wrote:
> Actually, thinking about it, the & wouldn't even be necessary. The overload
> resolution expression would simply return a function pointer.
I'd leave it. It would be more consistant.
FunctionPointer ::= "&" FunctionSpecifier;
FunctionSpecifier ::= FunctionIdentifier [ OverloadResolver ]
OverloadResolver ::= ["." "(" TypeList ")" ]
vs.
// "&" befor OR resolver after, Hmmm.
FunctionPointer ::=
"&" FunctionIdentifier |
FunctionIdentifier OverloadResolver;
OverloadResolver ::= ["." "(" TypeList ")" ]
(I don't think that the type of a ID is known at the syntax pass, but
this illustrates the point)
> Then there
> wouldn't be any ambiguity of whether you're getting the function address or
> the address of the return value.
It would still leave that problem. And I wouldn't count on
address-of-returns being invalid. If const references get in, then a
const reference to a return value might be handy (see below). I'll have
to think some more on that one.
// try something until sentinel is false;
void fig(bool *const sentinel);
bool quit;
bool Quit(){return quit;}
...
bool local;
passToAnotherThread(&local);
fig(&local); // time out from another thread
quit = true;
fig(&Quit()); // no timeout;
quit = false;
fig(&Quit()); // no blocking;
>
> auto a = foo();
> auto b = &foo; // ambiguous
> auto c = foo.(int); // c is byte function(int) (or byte(int)*, as typeid
> call it)
> auto d = foo.(); // d is address of foo();
> auto e = foo.(float);
>
> No need for foo.(void), which is good because you can't declare a function
> to take (void) as its arguments in D.
>
> And if you're right about the ident(type never showing up where a function
> call should, the dot might just be unnecessary.
>
>
Thinking about it the "Ident . ( Types )" syntax looks good.
More information about the Digitalmars-d-learn
mailing list