Boost logo

Boost :

Subject: Re: [boost] [qvm] deduce_xx traits wouldn't introduce ODR issues.
From: Sergey Mitsyn (svm_at_[hidden])
Date: 2015-12-31 02:42:55


On 29.12.2015 22:54, Rob Stewart wrote:
>
> What if the two libraries that specialize the return type are not
> related to the two that provide X and Y, but are, say, internal
> libraries used by different teams? If a third team decides to use the
> first two teams' libraries together, the problem arises again. The
> specializations would be reasonable for the first two teams. Only the
> third team has a problem and you can easily imagine that no one from
> the first two teams would think of the potential problem to warn the
> third team.
>

Correct me if I'm wrong, but it to me seems that the root of evil here
is a specialization by third party library, by which I mean the case
when template from library X is specialized with type(s) exclusively
from library (libraries) Y (Y might be the same as X) by library Z
(which is neither X nor Y, third party). If it's true, an ODR would be
caused for a user even if _unary_ deduce_m (or any other deduce_X) will
be specialized by two unrelated third party libraries A and B imported
by user.

Adding an extra formal type parameter to the template(s) for tag type
from library Z would make it safe, but in this case that's pointless as
QVM's template machinery would not know which tag to use.

If this is a flaw, then many things are also flawed - e.g. overloads by
third party too. Also, adaptation of any set of types to any concept by
third party. E.g., std::vector is adopted to BGL with
boost/graph/vector_as_graph.hpp, but any third party library shall not
adopt boost::container::vector; this can only be done by one team. For
large teams it seems unmanageable.

The question is does it mean that libraries that provide templates for
specialization (or overloading) are undesirable? Or can a specialization
be just limited in such a way that no third party library (as defined
above) shall specialize it? I.e., libraries - only for their own types,
users - for anything, given they can find a way to manage this in large
projects.


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