Properties no longer work?

Jarrett Billingsley kb3ctd2 at yahoo.com
Thu Jul 27 15:30:00 PDT 2006


"BCS" <BCS at pathlink.com> wrote in message 
news:eab6vo$1h47$4 at digitaldaemon.com...

> Does D allow taking the address of a return value? Seems to me that could 
> be used to disambiguate the resolution version from the  function call 
> version. I'm not sure how this would effect the context free aspect of the 
> syntax. Alternately the [ Identifier "(" Type ] sequence shouldn't ever 
> show up  where a function call would be. This, however, still leave a 
> problem with the "function taking void" type.
>
> humm
>
>
> byte foo(int);
> char foo(float);
> int foo();
>
> auto a = foo(); // a is int
> auto b = &foo; // ambiguous
> auto c = &foo(int); // a is byte function(int)
> auto d = &foo(); // address of return | address of foo(/*void*/)
> auto e = &foo(void); // inconsistent but unambiguous

Actually, thinking about it, the & wouldn't even be necessary.  The overload 
resolution expression would simply return a function pointer.  Then there 
wouldn't be any ambiguity of whether you're getting the function address or 
the address of the return value.

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. 





More information about the Digitalmars-d-learn mailing list