"Andrei Alexandrescu" <seewebsiteforem...@erdani.org> wrote in message news:gsamrs$204...@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.
