|
Boost : |
Subject: Re: [boost] [outcome] Second high level summary of review feedback accepted so far
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-06-01 07:14:03
2017-05-31 22:57 GMT+02:00 Vicente J. Botet Escriba via Boost <
boost_at_[hidden]>:
> Le 31/05/2017 à 22:45, Niall Douglas via Boost a écrit :
>
>> On 31/05/2017 21:08, Vicente J. Botet Escriba wrote:
>>
>>> Le 31/05/2017 à 14:04, Niall Douglas via Boost a écrit :
>>>
>>>> On 30/05/2017 22:28, Vicente J. Botet Escriba wrote:
>>>>
>>>>> Do we want to banish narrow contract in this library as if this kind of
>>>>> access was the leprose?
>>>>>
>>>> People have the statically checked varieties available to them if they
>>>> want narrow contracts.
>>>>
>>>> What if I want both?
>>>
>> You can't have a statically checked function which is always legal to
>> call. The static analyser couldn't claim calling it to be suspicious.
>>
>> Sorry, I'm tired to try to explain you the advantages of having both
> functions one with wide and and the other with narrow contract.
> The narrow function is not always legal to cal as it has a narrow contract.
>
>
> Hopping someone else could have more chance than me.
>
Both narrow- and wide-contract accessors are provided in std::optional. The
rationale for this is that decision whether I want "just value" or whether
I want the lack of value to be treated as a run-time error is best made at
the point where the value is used: not at the point where the type of the
object is being decided, or at the point where object is constructed.
Back in the days where `boost::optional` was being designed, some people
have suggested that the fall-back value (in case optional is empty) is
provided upon construction:
```
// not boost::optional:
optional<int> o {fallback_value(-1)};
o = 2;
assert (*o == 2);
o = none;
assert (*o == -1);
```
But again that it was decided that fall-back value is better determined at
the call site, not at object construction site. Hence we have `value_or`.
Regards,
&rzej;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk