Le 31/12/2015 10:24, Sergey Mitsyn a écrit :
On 31.12.2015 12:00, Rob Stewart wrote:
On December 31, 2015 2:42:55 AM EST, Sergey Mitsyn
wrote: 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.
Your point is valid except that one-type customization points are likely to be provided by the library providing the type X or Y, or by the library providing the customization point using a separate header (opt in).
But then until they don't it's still an issue, because eventually they may provide, so a specialization made by a library user is a ticking bomb.
Right. We should expect that the library document the need of such a customization so that the end user can know if s/he can combine it with other libraries. Customization of a class X are expected to be given by the library providing class X, or a friend library. I don't remember if I've already suggested to replace the deduce_xx customizations by a customization that depends only on the first parameter. I don't think this will dismiss a lot the functionality of the library. Vicente
Bold warnings in the documentation may be the only real solution to the issue.