Re: [boost] [type_erasure] ODR violation promotion

Subject: Re: [boost] [type_erasure] ODR violation promotion
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-09-10 01:11:03

Le 10/09/11 04:19, Gordon Woodhull a écrit :
> I don't think it's fair to single out TypeErasure here.
That was no my intention. It is just that with Boost.Generic, these were 
the two last libraries I was reading on that have an explicit convept map.
>
> Customization through template specializations or overloads is everywhere.
Do you have other examples of Boost.Libraries that have the same issue?
>
> On Sep 9, 2011, at 4:06 PM, Vicente J. Botet Escriba wrote:
>
>> Le 09/09/11 21:46, Gordon Woodhull a écrit :
>>> On Sep 9, 2011, at 3:26 PM, Vicente J. Botet Escriba wrote:
>>>
>>>> Le 09/09/11 20:44, Steven Watanabe a écrit :
>>>>>> Before the Boost.Conversion review someone signaled that the
>>>>>> Boost.Conversion review was promoting ODR violations as two libraries
>>>>>> could specialize a conversion for types S and T and make them
>>>>>> incompatible for an end user as the ODR is violated.
>>>>>>
>>>>>> I think that your library suffer from the same issue, when two libraries
>>>>>> need to specialize a concept provided by the library for a 3rd part
>>>>>> concrete class using the proposed concept map mechanism. Do you agree?
>>>>>> If not, how do  the library avoids this kind of issue?
>>>>>>
> The complete program has to have some consistent policy so that conflicts are impossible.  I don't think the fact that you could run into ODR problems with a library means that the library "promotes" ODR violations, and actually I think this may be an overstatement for Conversion as well.
You are right, as the library works well in most of the cases. I was 
trying to delimit the application scope of the library. Maybe it will be 
enoug to add to the documentation that the library can not be used with 
3rd party types that need a concept map.
>
>
> IMO it is easier to imagine a design policy where concept maps are defined consistently than one for libraries defining conversions.

You are right, as the conversion unicity on the concept map unicity or 
something like that. (Recall that I constrained the scope of the 
Boost.Conversion library to types that model the same underlying type 
concept).

> I think this is because a concept map is more likely to have only one reasonable definition than a conversion.  I do not see any hard-and-fast rule (yet?)
You are right, the definition should be unique, but nothing ensures that 
the concept map defined by two independent teams will be the same, isn't it?
>
> It does look like the problem was acknowledged with the dearly departed concepts, and the proposed solution was to define concept maps in namespaces: see "scoped concept maps".  IIUC I don't see how anything like that technique could apply here and now.
>
>
I'm interesteed in knowing how scoped concept maps solve the issue. Have 
you a pointer?

Best,
Vicente