Re: [boost] [variant] Maintainer

Subject: Re: [boost] [variant] Maintainer
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-06-28 09:15:18

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/