Boost logo

Boost :

Subject: Re: [boost] [variant] Maintainer
From: charleyb123 . (charleyb123_at_[hidden])
Date: 2015-07-01 17:53:28

<vicente.botet_at_[hidden]> wrote:

> Le 28/06/15 15:15, Niall Douglas a écrit :
>> On 28 Jun 2015 at 10:38, Vicente J. Botet Escriba wrote:
>> The current C++ proposal design has a hidden error state that IMO is
>>> viral and should be fixed. The problem is that with the current language
>>> there is no know implementation without using extra memory (as
>>> boost::variant does). I would like to see the language modified so that
>>> the boost::variant original implementation [1] is well-formed. This
>>> implementation would still be less efficient than an possible empty
>>> variant that mix empty and error, but the guaranties would be different.
>> I think adding ternary logic support to the language would make
>> solving this sort of problem much more elegant. Charley Bay did a
>> good talk "Your CPU is Binary" at C++ Now which convinced me to add
>> tribool support to lightweight monad + future such that:
>> Empty => False
>> Value => True
>> Errored/Excepted => Indeterminate
>> Ternary logic then has the truth tables from
>> ics.
>> The extension to the C++ language, if I understood what was proposed
>> by Charley, is minimal:
>> variant<...> v;
>> tribool t(v); // from explicit operator tribool()
>> if(t) { /* has value */ }
>> else if(!t) { /* is empty */ }
>> else { /* is errored */ } // Failure to provide this branch is a
>> compiler error
My proposed language change would be something like:

if(...) {
} else {
} unknown {

...Where the "trailing-unknown" clause would be a non-breaking C++ language
addition. It implies "true" and "false" are different from "unknown".

As an accident, this happens to behave similarly to a "try/catch" clause
when you have extended if/else chains (because an "unknown" never navigates
into an "if/else", but can only navigate into an "unknown").

On Sun, Jun 28, 2015 at 7:38 AM, Vicente J. Botet Escriba

> Sorry Nial, but I don't want to program like that.

Fair point. It's different. The assertion is that our code is littered
with "false-choices" and badly-handled ambiguities. The assertion is that
Boole's conclusions are based largely on false assumptions that manifest in
unfortunate ways when constructing real-world systems.

Under an alternative model, the common construct would be something like:

void foo(...) {
  return switch_(...) {

... and you manage your true/false/unknown cases explicitly. Works great
for asynchronous and distributed, and for interfacing-with-hardware.


Boost list run by bdawes at, gregod at, cpdaniel at, john at