2017-05-31 22:57 GMT+02:00 Vicente J. Botet Escriba via Boost < boost@lists.boost.org>:
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;