[boost] Boost.Experimental Re: [variant] Maintainer

Subject: [boost] Boost.Experimental Re: [variant] Maintainer
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2015-07-02 10:44:46

On Sun, Jun 28, 2015 at 10:29 AM, Agustín K-ballo Bergé
<kaballo86_at_[hidden]> wrote:
> On 6/28/2015 5:38 AM, Vicente J. Botet Escriba wrote:
>>
>> Le 27/06/15 21:32, Agustín K-ballo Bergé a écrit :
>>>
>>> On 6/27/2015 12:38 PM, Vicente J. Botet Escriba wrote:
>>>>
>>>> I would accept Eggs.Variant without even a review (or with a minimal
>>>> review) as an experimental library as part of Boost.Variant after some
>>>> minimal adaptation to fit in Boost of course.
>>>
>>> First of, as I have already said before, Eggs.Variant is an
>>> experiment. As such it is highly unstable, and I reserve the right to
>>> change things in any way I see fit, with no regards for backwards
>>> compatibility, maintenance, or support. I have made these kinds of
>>> changes in the past, and I have more planned for the near future. I
>>> think it would be unwise to make it a part of Boost, even as an
>>> experimental library, until the design has fully hatched ("Eggs", get
>>> it?).
>>
>> Agustin, this is exactly the kind of constraints of an experimental
>> library. When the design is fully hatched then it moves to non
>> experimental.
>
>
> I fail to see the point in including an experimental library that changes
> its interface every month into Boost, which is released every 3 months or
> so. By the time you get your hands in a release, the interface of the
> library has already changed. And the library as such would only exist for a
> single release.
>
> Who would benefit from Boost packaging old snapshots of experimental
> libraries?
>
> Perhaps you'd wish to bring back the Sandbox
> (http://www.boost.org/community/sandbox.html), which has been superseded by
> standalone repositories since the move to Git.
>

I think we need *something* for experimental libraries.  Even if it is
just someone's own git repository stamped (but not endorsed) with the
Boost "brand".
Or a page in boost.org listing current experiments.
Or... something.

There are (at least) 2 needs that Boost tackles:
1.  great libraries that solve problems for developers
2.  great libraries that can turn into std:: libraries

I think we are doing better on 1 than 2.  I think 2 requires more
experimentation (whereas 1 requires more stability).
Yes I know 2 looks successful - just look at how much of boost is in C++11.
But when each Boost library is brought to the committee, we have 2 choices:

- make design changes before going into std
- take as is

Making design choices in a committee (and without experimenting) is
not always a good idea.  We are, in theory at least, suppose to
standardize existing behaviour.

Taking as is means we are accepting whatever was good enough to pass
Boost review as *best*.  Boost review is a high bar, but the std::
should be higher.

It is common for the committee to hear/say "boost users have been
using it this way for years".  That is usually a good strong argument
- we want/need implementation and usage experience.  But saying "this
works" doesn't mean something else could work better.
Implementation/usage experience is most accurate when it says "this
does NOT work", because then you have ruled out an option.  When you
say "this works", it doesn't rule out options that might work
_better_.

We are increasingly going with option 3:

- put into std::experimental

which delays the desired outcome of getting great libraries into the standard.

I'd like some kind of experimental area that would help find the best
possible libraries.
What I'd _really_ like is more experimentation in _current_ Boost
libraries, breaking users left and right - I'd rather break boost
users than std:: users. (We have and will make breaking changes in the
standard library).  But I understand that current users wouldn't be
too happy about breaking changes _just for experimentation's sake_.
And if we lost the boost user base, boost would no longer be helpful
to the standard at all.

(As a reasonable example of not being afraid of breaking changes: Sean
Parent's Adobe Standard Library would boldly break whenever he thought
something could be made better.  It didn't break just for
experimenting, but he wasn't afraid to make breaking changes for the
better.)