Fully dynamic d by opDotExp overloading

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> On Mon, 20 Apr 2009 06:54:21 -0400, Denis Koroskin <2korden at gmail.com> 
> wrote:
> 
>> On Mon, 20 Apr 2009 06:09:28 +0400, Steven Schveighoffer 
>> <schveiguy at yahoo.com> wrote:
>>
>>> Yes, there are many things that opDotExp can do that opDot or alias 
>>> this (which is essentially opDot without any code).  Hooking every 
>>> function call on a type seems to be one of the two killer use cases 
>>> of this feature (the other being defining a large range of functions 
>>> from which only a small number need to exist).  But call forwarding 
>>> seems not to be one of them.  There are better ways to simply forward 
>>> a call (such as in your variant example).
>>>
>>> I'm pretty convinced that this is a useful feature, I still have 
>>> qualms about how it's really easy to define a runtime black hole 
>>> where the compiler happily compiles empty functions that do nothing 
>>> instead of complaining about calling a function that does not exist.
>>>
>>> Also, I don't think the requirement for this feature needs to be for 
>>> the arguments to be templated, it should be sufficient to have a 
>>> single string template argument.  This way, you can overload opDotExp 
>>> functions via argument lists.
>>>
>>
>> That way you loose type safety of arguments.
> 
> No
> 
> class C
> {
>    int y;
>    void opDotExp(string fname)(int x)
>    {
>       y = x;
>    }
> }
> 
> auto c = new C;
> c.foo(1); // ok
> c.foo("hi"); // compile error, no such function.
> 
> -Steve

Good point. My take is, just have the compiler rewrite a.b(c, d, e) into 
a.opDot!("b")(c, d, e) and call it a day. After that, the usual language 
rules enter in action.


Andrei