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