Re: [boost] [qvm] deduce_xx traits wouldn't introduce ODR issues.

Subject: Re: [boost] [qvm] deduce_xx traits wouldn't introduce ODR issues.
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2015-12-31 14:17:11

Unary deduction for a type defined by any library isn't a problem since the
specialization reasonably belongs to the library that defines the type.

Operation overloads for third party types won't cause ambiguities with the
generic overloads defined by QVM.

On Thursday, December 31, 2015, Sergey Mitsyn <svm_at_[hidden]> wrote:

> 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.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode