Subject: Re: [boost] [outcome] Second high level summary of review feedback accepted so far
From: Peter Dimov (lists_at_[hidden])
Date: 2017-05-30 16:11:45
Niall Douglas wrote:
> 1. I have been persuaded to use longer more appropriate naming for
> result<T> and outcome<T>, so now the typedefed varieties with implicit
> conversions to their empty-capable form indicated by "=>" are:
> - static_checked_outcome<T> => static_checked_optional_outcome<T>
> static_checked_result<T> => static_checked_optional_result<T>
> - runtime_checked_outcome<T> => runtime_checked_optional_outcome<T>
> runtime_checked_result<T> => runtime_checked_optional_result<T>
> Nobody is proposing that end users actually type out the full name each
> and every time they use them, and the documentation will make that clear.
As I already said, for me this takes away the whole point of the library,
which is to provide STANDARD result types which people use in their public
If everyone is typedefing their own varieties, this doesn't provide a
standard infrastructure. Sure, it would be useful for people who control all
of their code, but no more than that.
There should be one and only one result<T>, and one and only one outcome<T>,
with those names, which the world should use.
Let's first see if people who favor a narrow interface are satisfied with
value_if, which for me is a very good compromise. Once you have a raw
pointer, things are as narrow as it gets.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk