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

From: Viktor Sehr (viktor.sehr_at_[hidden])
Date: 2024-01-31 19:21:15

Hi,
std::expected<NumberType, WhateverError> would be even better, just didn't
think about it when I wrote the post.
Basically just an easy to use version of std::stoi which takes a
string_view as argument and does not throw.

/Viktor

On Wed, Jan 31, 2024 at 5:00 PM Peter Dimov via Boost <boost_at_[hidden]>
wrote:

> Dominique Devienne wrote:
> > On Wed, Jan 31, 2024 at 1:38 PM Peter Dimov via Boost
> > <boost_at_[hidden] <mailto:boost_at_[hidden]> > wrote:
> >
> >
> >       Viktor Sehr wrote:
> >       > I think boost::charconv should add one convenience function as
> > follows:
> >       > // Returns std::nullopt on error
> >       > template <typename NumberType>
> >       > std::optional<NumberType> boost::charconv::to_number(const
> >       > std::string_view& sv) noexcept;
> >
> >       This throws away the error code
> >
> >
> >
> > But sometimes that's all you want. That's kinda the point from Viktor I
> guess.
>
> It's actually never what you want the way from_chars is specified, because
> 0.000[more 0...]001 fails with ERANGE, whereas 1.000[same 0...]001 succeeds
> and returns 1.0.
>
> I don't really know of a use case where this is what one wants.
>
> > Not that an `expected` or `outcome` return type is bad; but it is more
> complex.
>
> It's not any more complex for the user; the interface is the same as
> optional's
> if you don't need the error.
>
> Returning `optional` is almost always a design mistake.
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>