Re: [boost] [type_erasure] ODR violation promotion

Subject: Re: [boost] [type_erasure] ODR violation promotion
From: Gordon Woodhull (gordon_at_[hidden])
Date: 2011-09-09 22:19:25

I don't think it's fair to single out TypeErasure here.  

Customization through template specializations or overloads is everywhere.

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?
>>>>> 
>>>> I have no intention of trying to deal with it.
>>>> As far as I'm concerned it's the responsibility
>>>> of whoever defines the specializations.  I'm
>>>> not going to worry about it at all until I
>>>> hear reports of it causing real problems, as
>>>> opposed to being a purely theoretical concern.
>>>> 
>>>> 
>>> IIUC you response, you agree that your library has the same problem.
>> Or, it is not a real problem.
>> 
>> Or, as Roman Perepelitsa suggested, it is a more serious problem if you are defining customizations on two types, because then it is unclear which library has responsibility for defining the customizations.
>> 
> Or, the library can not be used with 3rd party types by other libraries without promoting ODR violations ;-)
> 
> Note that 3rd party libraries could not be aware of the existence of Boost.TypeErasure or any other library that could define concepts that can be mapped and can not define themsenves the specialization for them.
> 
> Or, may be I'm wrong and there is a solution to this problem?

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.  

IMO it is easier to imagine a design policy where concept maps are defined consistently than one for libraries defining conversions.  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?)

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.

Cheers,
Gordon