Fully dynamic d by opDotExp overloading

[Denis Koroskin]

On Sun, 19 Apr 2009 18:26:11 +0400, Steven Schveighoffer <schveiguy at yahoo.com> wrote:

> On Sun, 19 Apr 2009 06:26:57 -0400, Denis Koroskin <2korden at gmail.com>  
> wrote:
>
>> On Sun, 19 Apr 2009 05:40:32 +0400, Steven Schveighoffer  
>> <schveiguy at yahoo.com> wrote:
>>
>>> On Sat, 18 Apr 2009 21:10:27 -0400, Andrei Alexandrescu  
>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>
>>>> Adam Burton wrote:
>>>>> Andrei Alexandrescu wrote:
>>>>>>> What about using something like '->' for dynamic calls instead of  
>>>>>>> '.'?
>>>>>> That's absolutely useless. If I have to write anything different  
>>>>>> from
>>>>>> "." I might as well write "bloodyMaryBloodyMaryBloodyMary".
>>>>>>
>>>>>> Andrei
>>>>> You could even write 'noodles' but that doesn't really give me a  
>>>>> reason as to why it's absolutely useless. Please clarify, I thought  
>>>>> it seemed like a reasonable idea, if it isn't I would like to know  
>>>>> why.
>>>>
>>>> I apologize for the snapping. There's no excuse really, but let me  
>>>> mention that this thread has been particularly meandering.
>>>>
>>>> The point of using "." is not syntactic convenience as much as the  
>>>> ability of the Dynamic structure to work out of the box with  
>>>> algorithms that use the standard notation.
>>>
>>> Hm... the thought just occurred to me.
>>>
>>> At what time are you going to use opDotExp so an entity be used in an  
>>> algorithm rather than actually defining the functions directly?  For  
>>> example, if you want to make a class/struct a range, why not just  
>>> define the functions directly?  It seems odd to define them using  
>>> opDotExp.
>>>
>>
>> Variant variantRange = someRange();
>> foreach (element; variantRange) {
>>     // ...
>> }
>>
>> Variant forwards all the front/back/etc methods to an underlying range.
>
> Doesn't the current opDot solution do this?  Forwarding all calls to a  
> certain member is not a really compelling argument for changing opDot to  
> allow dynamic method names.
>
> -Steve

opDot is reprecated (use alias this instead) and will be eventually removed.

But "alias this" is quite unsafe because it exposes the inner data (which is supposed to be hidden in some case, think of reference counting wrapper - you never want to give raw access to an underlying data).

Besides, there are is a use-cases that you can't implement in a way other than opDotExp. For example, add some logging or profiling:

struct Profile(T)
{
    private T inner;

    auto opDotExp(string name, T...)(T args)
    {
        profiler.enter(name);
        scope(exit) profiler.leave();

        return <forward a call to 'inner' - how one would do this?>(args);
    }
}