Aristotle Pagaltzis wrote: >Then again, if we split LHS from RHS overloads and LHS overloads become >rare then that problem should be substantially contained. It wouldn't be all that rare. Marking the feature as being only for autodie's use wouldn't work, especially if there's no intent to actually remove it later. And even if it is only used by autodie, that doesn't render it contained. If there are lhs overloads, then all the matching rules that are subject to them are just attractive nuisances. In Tony's plan I think that would be all except for the one with an overloaded object on the rhs. Since your objection to breaking code using given($@) with autodie applies to any use of given, presumably you're actually arguing for us to make no change at all to smartmatching semantics, in which case there are even more. > anyone just reading the autodie POD would even today not know to >assume anything amiss with the given($@) interface. That's true. They'll learn that there's a problem quite soon, once they run some code following that pattern, by virtue of the "experimental" warning. But there's effectively a conflict between the warning and the autodie doc. Even if we don't resolve smartmatch now, we should at least put something in the autodie and autodie::exception documentation warning about the unstable nature of the mechanism. -zeframThread Previous | Thread Next