Fully dynamic d by opDotExp overloading

[Nick Sabalausky]

"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
news:gsapl6$24ei$1 at digitalmars.com...
> Steven Schveighoffer wrote:
>>
>> Sure, how do you know that the class actively chose it, or did not 
>> actively choose it, or will *never* actively choose it simply by looking 
>> at the statement?
>
> You shouldn't worry about it as much as you shouldn't when you iterate a 
> built-in array vs. a user-defined range.
>
> Would you like ranges that work very different from built-in arrays, and 
> everybody to special-case around that?
>

That's an inadequate comparison. We *can* make arrays and ranges usable in 
the same way. But opDotExp cannot make dynamic calls usable in the same way 
as static calls, because one of the rules of static method invokation is 
that trying to call a non-existant function results in a compile-time error. 
The best opDotExp can do it make dynamic calls *seem* the same which is 
deceptive.

If you want static and dynamic calls to be really usable in the same way 
(like iterating over a range vs array), then there's only two possibilities:

1. Make attempts to invokation a non-existant static function a runtime 
error (obviously a bad idea).
or
2. Provide a *secondary* syntax to invoke a method that works for both 
static and dynamic. Such as through a reflection api:

traits(new Foo()).invokeMethod("bar");