Boost logo

Boost :

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-11-20 09:11:54


On Tuesday 19 November 2002 04:44 pm, Paul Mensonides wrote:
> Clever type traits are one thing, but they are a side-effect of the
> solution to a more general problem. Specifically, one template function
> declaration can permanently break an overload set--even if it is not
> selected. The solution to this is obvious, if type deduction yields
> nonsense, it should fail. It just so happens that we could exploit that
> solution in significant ways with traits and expression validity checking.

I don't think it's quite so clear-cut, because we have to define what you mean
by "nonsense", and I'm not sure you'll find agreement. The committee chose
one view of nonsense: trying to form any type that isn't a C++ type (e.g.,
typename int::foo) is nonsense, so deduction fails. But we're talking about a
whole new dimension of nonsense, where we want it to say "anything that can't
compile is nonsense". I have to wonder if this makes the problem you
cite---that one function template declaration can permanently break an
overload set---even worse. We're not talking about one brilliantly-written
function template declaration, we're talking about one that is poorly written
because it is too general. It's an error that should be corrected, but the
user won't ever actually see this error because the function template will
never make it into the overload set.

Also note that this change is a huge problem for backward compatibility. That
badly broken function template from above is silently useless on C++0x, but
step back to C++98/C++02 and its going to fail.

> *why* something is invalid in the general sense. Also, the "sizeof" trick
> is open-ended. Any possible future language primitives will only give us a
> few of the things we need, and we'll still have to do the rest anyway.
>
> Paul Mensonides

... but don't forget that once we get more language primitives, that will
enable new tricks as well.

        Doug


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk