Properties no longer work?

[BCS]

Jarrett Billingsley wrote:
> "BCS" <BCS at pathlink.com> wrote in message 
> news:eaarq2$1h47$1 at digitaldaemon.com...
> 
> 
>>It gets worse. If foo is overloaded, then DMD silently grabs the lexically 
>>first version and uses it. This is in direct contradiction of the idea 
>>that lexical order of functions/classes/etc. should not effect semantics. 
>>(I seem to recall that this is one of the goals of D, but I can't find the 
>>reference).
> 
> 
> That is ugly.  In fact, I even came up with a solution for it in my 
> scripting language (before it was dynamically typed): an "overload 
> resolution expression."
> 
[...]
> 
> &foo // ambiguous
> &foo.(int) // foo(int) overload
> &foo.(float) // foo(float) overload
> 
> The dot is in there so that the parser doesn't interpret it as a function 
> call.  And as far as I know, there is no other syntax that allows the ".(" 
> sequence. 
> 

Nice. Looks a bit odd though, I'll have to think on that.


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