Boost logo

Boost :

Subject: Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2018-02-08 20:39:17


2018-02-08 18:56 GMT+01:00 Nevin Liber via Boost <boost_at_[hidden]>:

> On Mon, Feb 5, 2018 at 6:00 PM, Rob Stewart via Boost <
> boost_at_[hidden]
> > wrote:
>
> > I think the library could, at least, assert in debug builds when a result
> > or outcome is not inspected.
> >
>
> That can be problematic. Suppose you have one that isn't inspected
> (because the library you are calling uses outcome for return values) and an
> exception is thrown (say, from a different library). Is it incorrect to
> not have inspected it?
> <http://lists.boost.org/mailman/listinfo.cgi/boost>
>

Another such case that does not involve exceptions. Suppose I have a
function template that can convert any T to any U, such as lexical_cast but
with different interface:

```
template <typename U, typename T>
auto convert(T const& v) noexcept(false) -> result<U, ConvFailure>
```

This function still throws exceptions upon resource shortage but signals
failure through `result<>` if a given value of type `T` cannot be
represented in type `U`.

When, at some place, I use it to convert from `int` to `string`, I know
that for this combination of T and U the function cannot fail to find
representation, so it is correct for me not to check for failure:

```
string s = convert<string>(-123).assume_value();
```

Would a run-time check be able to keep silent in the case like that?

Regards,
&rzej;


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk