|
Boost : |
Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-05-19 20:30:47
Le 19/05/2017 à 15:48, Andrzej Krzemienski via Boost a écrit :
> 2017-05-19 15:08 GMT+02:00 Niall Douglas via Boost <boost_at_[hidden]>:
>
>>>> The constexpr variables are already there. So basically do we prefer:
>>>>
>>>> 1. .ensure_empty(), .ensure_value(), .ensure_error() and
>>>> .ensure_exception()
>>>>
>>>> 2. Or .ensure(empty), .ensure(value), .ensure(error) and
>> .ensure(exception)
>>>> I figure the latter looked nicer. It's same difference to the compiler,
>>>> simple overload matching is constant time.
>>>>
>>> Just one note. If I use namspace prefixes, the notation with "constants"
>>> becomes longer:
>>>
>>> `o.ensure_empty()` becomes `o.ensure(boost::outcome::empty)`
>>>
>>> One could respond to this "just import anything from namespace
>>> `boost::outcome` into the scope", but that is imposing on me a certain
>>> style of programming, which I not necessarily want to adapt.
>> Yes that's a good point.
>>
>> Also, after a few nights of sleeping on it, I'm not keen on .ensure_XXX().
>>
>> Would people be okay with:
>>
>> * o.check() <= (void) o.value()
>>
>> * o.check_error() <= (void) o.error()
>>
>> * o.check_exception() <= (void) o.exception()
>>
> Given that this "ensure" functionality would be used rarely, and some even
> suggest there is no use case for it, I would be satisfied with this syntax
> `(void)o.value()`.
+1 KISS
Vicente
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk