Fully dynamic d by opDotExp overloading

[Nick Sabalausky]

"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
news:gsamrs$204u$3 at digitalmars.com...
>>
>> Typically, yes, having "as many useful tools as possible in our 
>> programmer toolbox" is great. But with opDotExp, that's not the whole 
>> story. What opDotExp is, is a tool of only occasional use that provides 
>> only a small benefit, *and* ends up destroying a much more important 
>> tool: compile-time checking on a class's members.
>
> s/on a class's members/on the members of the class that actively chose 
> that/
>

Right, that's what I meant, but that's still worse than not having opDotExp 
at all.

If someone wants to do dynamic programming, then ok, fine, even though I 
think they're making a mistake, they're free to go use a dynamic language. 
But D is supposed to be a static language. That's why I use it. I don't want 
that staticness to be hijackable just because some people prefer 
dynamicness. Obviously, if there's a dynamic feature that *doesn't* 
interfere with the static stuff (the phobos Variant, for example), then 
that's great. Toss it in and let people use it if they want. Why should I 
care?

But with opDotExp, its mere *existence* undermines my ability to be sure 
that non-quoted identifiers are ok as long as they've compiled. That type of 
tradeoff is obviously fine when the potential benefits are significant 
enough (operator overloading, for instance). But from everything I've seen 
so far, opDotExp's benefits are trivial at best. I don't want to have to 
keep track of "ok, is this class using opDotExp or not, because if it is, 
then I need to be more careful", just for the sake of a feature that 
provides such a tiny and questionable benefit.