"Rainer Deyke" <rain...@eldwood.com> wrote in message news:gsbodm$mj...@digitalmars.com... > Nick Sabalausky wrote: >> But anyway, like I've said before, syntactic sugar is fine, but this is >> syntactic sugar that undermines the programmer's ability to rely on >> compile-time checking of class members. "But only for the classes that >> use >> it." No, it undermines that trust across the board because it's >> non-obvious >> what classes are using it, so you'd have to always be on guard. "Operator >> overloading blah blah blah" That only causes problems when it's used >> *and* >> abused by a class, while this would cause problems *any* time it's used. >> Etc >> etc... > > Compile time checking is not undermined at all, even for classes that > use this functionality. opDotExp just makes it easier to create classes > with a large, possibly infinite set of members. There are three > possible cases: > > 1. The class does not use opDotExp. Compile time member checking is not > undermined. > > 2. The body of opDotExp triggers an error at compile time if it receives > an unexpected name. Compile time member checking is not undermined, > although the specific error message may have changed. > > 3. The body of opDotExp accepts all names. Compile time member checking > is not undermined, we just have a class that has every legal identifier > as a member. >
If the member-name parameter to opDotExp was *required* to be a template paramater, then I agree, and I would have no objections to having that. But it should be pointed out that that would not actually be dynamic invokation, since you wouldn't be able to invoke a member whose name is only known at run-time. (But I would love for that to be possible through a reflection API.)
