Le 30/05/2017 à 19:53, Niall Douglas via Boost a écrit :
On 30/05/2017 18:43, Peter Dimov via Boost wrote:
Niall Douglas wrote:
Do you accept that the static checked and runtime checked varieties are orthogonal user bases? There is a camp of users who strongly prefer no runtime overhead and static checking. Why are their needs not served by value_if?
auto r = function();
if( auto* p = r.value_if() ) { // use *p // no runtime overhead on using *p // static checkers know use of *p implies p != nullptr }
Between this pattern and using `assert( r.has_value() )` directly to advise the static checker, are we not covered? I'm still pondering your idea on this for the runtime checked editions. So far I am liking it, but I need to sleep on it some more.
But there was still a large minority of folk who want all-narrow observers. They haven't voiced anything to say they have changed their minds.
I currently, roughly speaking, find approx 50% in favour of a runtime checked edition, approx 40% in favour of a statically checked edition.
Emil and Vicente make up the 10% of folk who want something completely different.
I say that we don't have to choose. We can provide as we have already done in a lot of libraries provide wide and narrow functions. No need to split the world on two parts. No silos. value_if could be a complementary/helper interface. We don't need to provide them on all the types, but as algorithms. The implementation is the same for optional, expected, result, .... The same for T nv = value_or(pv, v); E ne = error_or(pe, e); bool b = has_error(pe, e); IMHO, most of the wide function constracts can be provided this way. There are some exceptions e.g. value that throw a different exception depending on the type, but this is because we don't have found yet the minimal interface. E.g. If we had a pe.rethrow() function, we could define value by in function of has_value, operator* and rethrow. Vicente