Re: [boost] [variant] Maintainer

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
>> https://en.wikipedia.org/wiki/Three-valued_logic#Kleene_and_Priest_log
>> 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.

--charley