Re: [boost] [outcome] Second high level summary of review feedback accepted so far

Subject: Re: [boost] [outcome] Second high level summary of review feedback accepted so far
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-05-30 21:28:20

Le 30/05/2017 à 21:36, Niall Douglas via Boost a écrit :
>>> 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.
>>>
>> It is probably not a good idea to measure correctness by popular opinion,
> I think C++ Either result types will always fall into two camps, narrow
> and wide. As you mentioned yourself Emil, the cause is the language's
> current inability to specify statically correctness preconditions for
> function calls. That would get a lot better if something like Herb's
> metaclasses came along, but those are many, many years out, if ever.
>
> Until then we are trapped: either put UB on the observers so it can be
> trapped at compile time, or eliminate all UB so logic errors appear at
> runtime. You can choose either of those per function, but you cannot
> have both at once per function.
You can have two functions :)
>
> I intend to put UB "raw" observers on the runtime checked editions,
> maybe using the form Peter suggested. But I am deeply opposed to having
> short-to-type-out observers like operator*() do UB unless the type's
> name loudly declares "I am an unsafe type".
>
>
>
:(

I don't understand. Aren't we on a C++ forum? on the review of a C++ 
library?

Do we want to banish narrow contract in this library as if this kind of 
access was the leprose?

Do you want that boost.shared_ptr checks if not null before access on 
operator->?

I could want that on a DEBUG version, but not on my release version.

Best,

Vicente