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