|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk