On 28 Jun 2015 at 10:38, Vicente J. Botet Escriba wrote:
There is something that I don't like of the possibly empty variant. It confounds the empty state and a hidden error state. When we assign a type A to variant containing a type B the resulting variant can be empty (contains a different type C). While I understand the efficiency trade-offs, this difference in behavior merits IMHO a different name (well if we have several variants ;-).
You can see then why I deliberately made my lightweight monad & future fixed variant. It makes this issue (which was talked about frequently at C++ Now) go away. BTW for those interested lightweight future-promise will be a minimum of 2x faster than STL future-promise as I got the first benchmarks late last night. I think 50 CPU cycle promise => future overhead might just be doable.
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 In other words, the only relaxation of the language spec is that: 1. Logic operators permit tribool in the standard. 2. Where choosing operator tribool and operator bool are ambiguous, we always choose operator tribool. (3. I'd personally like if strongly typed enums permitted constexpr only member functions such as operator tribool(), see below). I have a constexpr tribool for C++ 11 at https://github.com/ned14/boost.spinlock/blob/master/include/boost/spin lock/tribool.hpp for anyone interested. Its most annoying feature is requiring users to use the free functions: true_(tribool) false_(tribool) unknown(tribool) ... because enum class doesn't allow constexpr member functions :(
To sum it up, Eggs.Variant is its own thing, but it is way too young for me to know what that thing is yet.
Regards, No problem, I'm not requesting you to submit your library to Boost. It is just an example of the kind of experimental libraries I would like to see in Boost.[Experimental].
I believe that we need more experimental and basic libraries as yours in Boost.
+100. Far too much interesting C++ isn't coming to Boost any more. We need Boost.Sandbox back, and Vicente's Boost.Experimental looks like a great replacement. To get in a library merely needs to look a bit like a Boost library e.g. naming conventions. Other than that, it's open season. If such a thing were set up, can we have a Google Summer of Code section in it for student projects please? Right now they get their own github org for each year, but I think the students would just love if their GSoC was closer to Boost. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/