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