On Friday, November 09, 2012 01:53:40 Nick Sabalausky wrote: > Looking at one set of interfaces in isolation, sure the chances might > be low. (Just like the chances of name collisions when hygeine is > lacking, and yet we thankfully have a real module system, instead of C's > clumsy "Well, it should usually work ok!" garbage.) But it's a terrible > precedent. Scale things up, use ducks as common practice, and all of a > sudden you're right back into the same old land of "no-hygeine". Bad, > sloppy, lazy precedent. AND the presumed benefit of the duckness is > minimal at best. Just not a good design, it makes all the wrong > tradeoffs.
As long as your template constraints requires more than a couple of functions and actually tests much of anything about what those functions return or what arguments can be passed to them, I find it very unlikely that anything will accidentally pass them. Too many coincidences would be required to end up with a set of functions that matched when they weren't supposed to . It's only likely to be problem if you're checking only one or two functions and don't check much beyond their existence. It just doesn't take very many checks before it's highly unlikely for anyone to have created a type with functions with the same names and whose signatures are close enough to pass a template constraint when they're not supposed to. - Jonathan M Davis