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-27 11:00:04

On Sat, Dec 26, 2015 at 5:19 PM, Rob Stewart <rob.stewart_at_[hidden]>
wrote:

> On December 26, 2015 4:54:19 AM EST, Rainer Deyke <rainerd_at_[hidden]>
> wrote:
> > On 25.12.2015 13:03, Rob Stewart wrote:
> > > I think, rather than X and Y providing conflicting definitions, the
> > > problem is that abc provides a specialization to allow
> > > interoperability with def, and def does the same for abc. Using the
> > > two libraries, in that case, always creates a conflict.
> >
> > This implies a circular dependency between abc and def.  If those
> > libraries are that tightly coupled, surely they can work out this
> > conflict between themselves?
>
> It implies no such thing. It implies that each library provider chose,
> independently, to offer interoperability with the other using QVM.
>

It isn't exactly interoperability. The specialization in question isn't
needed to make library X and Y compatible with each other using QVM, that's
automatic. It only specifies the return type of operator* when multiplying
e.g. X::matrix by Y::matrix; and it is plain wrong for X or Y to specify
that, because the user most likely wants to get a my_matrix instead.

That's of course in addition to the fact that a library can't be
responsible for ODR violations introduced by the user.

Emil