"Fred Bertsch" <fred.bertsch@gmail.com> writes:
I can see that there's no way to make the assignment operator do any better. I didn't mean to imply otherwise. However, that doesn't change the fact that it doesn't do the right thing.
I would claim that if code far from a call can change the order of parameters in a function call, and if the compiler won't tell me about it, then this is dangerous.
How different is that from this situation? int x; void f(int x) // "code far from a call" { // ... lots of code a_call(x); // I thought I was passing ::x } Here code far from a call can affect the meaning of that call. I don't see why the order of parameters is especially more sacrosanct than other changes to the meaning of a function call.
I don't mean to say that it could be done better. It's really a very slick library. I'm just saying that I won't recommend its use to my coworkers.
That's your perogative of course. Maybe you should tell them to avoid using scopes, though, because lexical scoping can cause the same problems without this library being involved ;-)
I think it would be reasonably safe, however, if you put the argument identifiers in a separate namespace. I like that idea. It's potentially ugly, but it should be considerably safer.
Normally the keyword objects should be declared in a nested namespace of the one that declares functions whose parameters they identify, and that should generally be a different namespace from that of the functions that use those keyword objects. However, it's idiomatic to bring those keywords in via using directives to make them available without qualification. -- Dave Abrahams Boost Consulting www.boost-consulting.com