Re: [boost] Boost.Conversion - pre review request

Subject: Re: [boost] Boost.Conversion - pre review request
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2011-07-11 12:59:19

Gordon Woodhull wrote:
> 
> On Jul 9, 2011, at 11:39 AM, Vicente Botet wrote:
> 
>> You are right and the same applies to any type-to-type conversion. And
>> maybe
>> this is the MAJOR flaw of Boost.Conversion: to think that we can define
>> extrinsically THE conversion between two types. Every body admit that if
>> a
>> class T defines a constructor from a std::string THE conversion from
>> std::string to T is the one defined by this constructor. 
> 
> Yes, this is a problem with all global customization points.
> 
> I would expect than any one developer would want to use either
> lexical_cast or coerce.  However, does the ODR mean that the exact same
> conversions would have to be defined in a library and in any code that
> uses the library?  That sounds tricky!
> 
> Just document it as a known limitation and reviewers can decide 
> 

Yes. we can not have two customizations that conflict within the same
program.

>> Note that this issue is not only limited to Boost.Conversion but to any
>> function that could be overloaded by the user or any template class that
>> can
>> be specialized by the user. Two different parts of a program could make
>> the
>> same overloading or the same specialization. This doesn't implies that we
>> should avoid overloading or specializations.
> 
> Right.
> 
>> It seems clear to me that if we don't have a consensus on the default
>> type-to-type conversion extrinsically Boost.Conversion mustn't not
>> provide
>> it,
> 
> IIUC it's providing the conversions and the user chooses them by
> #including the headers of interest.
> 
>> neither the user.
> 
> ?  Really?
> 

Well, we have two kind of users. Final users and library author users. The
final users can choose to include the header of their interest as far as
there is no conflict in the whole program, but library author users can use
only consensual type-to-type conversions if they want its library to be
reusable in a large context.

>> Does it means that Boost.Conversion has no sens? I
>> don't know. 
>> 
>> Coming back to the string to int conversion, if we can not have a default
>> string-to-type or type-to-string, Boost.Conversion must remove these
>> specializations.
> 
> Seems to me there are still defaults: decimal provided by either
> lexical_cast or coerce depending on user preferences.  And the user has to
> be careful.  
> 
> Or are you saying that since all libraries linked into a program must
> agree on which conversions to use, Conversion should only define ones that
> everyone agrees on?  That sounds rather extreme.  Why not just stipulate
> that the set must be the same throughout the program?  Libraries would
> document or allow customization of which converters they use.
> 
> 

Yes, this is exactly the point. There couldn't be a conflict in the whole
program. Library authors could document the conversions choices they have
taken, but the use of a non-consensual conversion will make the library less
usable.

I don't think that Boost.Conversion can provide a string-to-type conversion
that is configurable. It could provide one if there is a consensus of a
default. We should see Boost.Conversion customization as if we were adding
some methods to one of the classes. For the string to float conversions, it
is as if we were adding

explicit operator float() const;

to the std::string class.

Best,
Vicente

--
View this message in context: http://boost.2283326.n4.nabble.com/Boost-Conversion-pre-review-request-tp3650286p3660138.html
Sent from the Boost - Dev mailing list archive at Nabble.com.