Re: Boost.Charconv review runs January 15th - 25th, 2024

From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2024-01-23 17:46:48

  >>> Can I request that this library flips the defaults>>> so that boost::from_chars is 100%-compatible>>> with std::from_chars, and you also get
>>> boost::from_chars_plus that behaves like strtod?
>> Your reasoning is sound, and I have no issue>> with flipping them
> Reviewers: If this default-flipping-befavior is of> importance, please do note this fascination> discussion. This is because it is seems like> a somewhat significant recognition at a> progressive time point in the review.
Sorry, I had a typographical error in thatexpression.
Reviewers: If this default-flipping-befavior is ofmajor importance, please do note this fascinatingdiscussion. This is because it is seems likea somewhat significant recognition at aprogressive time point in the review.
Thank you. Christopher
    On Tuesday, January 23, 2024 at 06:42:38 PM GMT+1, Christopher Kormanyos <e_float_at_[hidden]> wrote:  
 
 >> Can I request that this library flips the defaults>> so that boost::from_chars is 100%-compatible>> with std::from_chars, and you also get
>> boost::from_chars_plus that behaves like strtod?
> Your reasoning is sound, and I have no issue> with flipping them
Reviewers: If this default-flipping-befavior is ofimportance, please do note this fascinationdiscussion. This is because it is seems likea somewhat significant recognition at aprogressive time point in the review.
Christopher
   On Tuesday, January 23, 2024 at 06:25:13 PM GMT+1, Andrey Semashev via Boost <boost_at_[hidden]> wrote:  
 
 On 1/23/24 20:14, Matt Borland via Boost wrote:
>>
>> Can I request that this library flips the defaults, so that
>> boost::from_chars is 100%-compatible with std::from_chars, and you also get
>> boost::from_chars_plus that behaves like strtod?
> 
> Your reasoning is sound, and I have no issue with flipping them. In the docs I can highlight that the default behavior will likely change in the future based on whatever resolution LWG comes up with. 

I think I'd prefer that the "default" interface (that is, the one that
users will likely use by default) to be the one that implements the
"right" behavior (i.e. the behavior people find most useful) and keeps
implementing that behavior regardless of the standard committee
decisions on the standard.

We recently had Boost.Scope review, and in its results it was
highlighted that people generally prefer better interfaces to strict
conformance with the standard. Boost libraries don't have to be strict
implementation of the standard, especially when we can do better.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost