The new Boost 17.0.0

classic Classic list List threaded Threaded
128 messages Options
1234 ... 7
Reply | Threaded
Open this post in threaded view
|

The new Boost 17.0.0

Boost - Dev mailing list
Hi,

== The problem.
TL;DR: we are having huge troubles with usability and popularity!

Quite a lot of companies forbid using Boost because:
* it provides vocabulary types, that should be the same across the
whole project (like shared_ptr, filesystem::path or optional).
Otherwise it's hard to combine different APIs
* it is huge, in consists of legacy on more than a half, with a lot of
dependencies between libraries. This is extremely painful for big
companies, because there's no efficient distributed build system. Each
company invents it's own and/or tries to minimize headers by all
means.

New companies (startups) also avoid Boost:
* "We are using C++17, we do not want legacy libraries with C++98 support"
* Junior developers are confused by multiple vocabulary types. "Should
we use boost::optional or std::optional?"
* hard to upgrade, because symbols are not versioned

ISO C++ WG21 community not willing to push prototypes into Boost. "We
aim to establish "existing practice" and provide reference
implementations so that Boost libraries are suitable for eventual
standardization." - that's not really true any more.


== The Solution
TL;DR: we need a C++17 fork of Boost with close to 0 dependencies
between libraries and namespace versioning.

С++17 provides many vocabulary types, feature test macro and a bunch
of features for variadic templates. All of that allows us to drop a
lot of weight and fix majority of popularity and usability problems.

Rule of a thumb should be: "If the C++17 provides that functionality -
use the standard version".

That approach would allow to loose a lot of weight, do not mess with
vocabulary types and significantly reduce dependencies
https://pdimov.github.io/boostdep-report/master/module-levels.html

By levels:
config 0 -> we probably would not need it any more
assert 1 -> 0
core 2 -> 1 (or 0 if we merge it with asser)
smart_ptr 4 -> 2
exception 5 -> 2
stacktrace 5 -> 2
intrusive 5 -> 2
outcome 6 -> 3
container 6 -> 3
gil 11 -> 2?
context 16 -> 2?
dll 17 -> 1
asio 18 -> 3?
beast 19 -> 4?


== The Path
TL;DR: we should start the Boost17 now and ship it as we are ready.
Old Boost should be still available.

The new approach requires quite a lot of effort and not all the
maintainers have enough time to do the migration. We should keep
releasing the existing Boost, while migrating the libraries to the
Boost17.

The migration is not as hard as it seems. It took 2 or 3 days to make
Boost.DLL work with either boost or std filesystem. It could be done
in less than a day, if I do not have to support the Boost filesystem.


== Action points
0) Discuss
1) Bury the idea, wait for a few years, goto 0); or make a boost17
repo with the same layout as the existing one, but without submodules
2) start the migration

--
Best regards,
Antony Polukhin

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The new Boost 17.0.0

Boost - Dev mailing list

> On 27. Nov 2020, at 09:58, Antony Polukhin via Boost <[hidden email]> wrote:
>
> == The Solution
> TL;DR: we need a C++17 fork of Boost with close to 0 dependencies
> between libraries and namespace versioning.

I am personally fine with a C++17 fork, but that means dropping Boost Serialization among other things, right?

Boost Histogram has level 2 dependencies without Boost Serialization, which is opt-in. With Boost Serialization is has level 18, because Boost Serialization depends on the world. AFAIK rewriting Boost Serialization to drop Boost MPL would be a major effort.

Besides that, demanding 0 dependencies has serious drawbacks. Boost Histogram uses Boost functionality where there is no equivalent in the stdlib, not even in C++17 (Boost config, Boost throw_exception, Boost mp11, Boost core). I already reimplemented functionality in Boost Histogram that was originally found in other Boost libs to reduce coupling, like Boost Iterator and Boost Multiprecision. Boost Beast does this, too, it has its own variant type and more.

A non-fundamental library like Histogram or Beast has the choice to either suffer a significant loss of functionality or use its own private implementation of Boost functionality to give the appearance of low dependencies. This inflates the private code of these libraries and maintaining private (duplicated) implementations is frankly crazy. We bundle Boost to make use of **synergies** between the libs. I should not use my private (potentially buggy) implementation of Boost iterator, I should use the official maintained (and hopefully less buggy) one.

Best regards,
Hans

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The new Boost 17.0.0

Boost - Dev mailing list
пт, 27 нояб. 2020 г. в 12:46, Hans Dembinski <[hidden email]>:
>
>
> > On 27. Nov 2020, at 09:58, Antony Polukhin via Boost <[hidden email]> wrote:
> >
> > == The Solution
> > TL;DR: we need a C++17 fork of Boost with close to 0 dependencies
> > between libraries and namespace versioning.
>
> I am personally fine with a C++17 fork, but that means dropping Boost Serialization among other things, right?

Not really. Serialization library can not be replaced with C++17
Standard library, so we can move it to Boost17. This would require
some effort in dropping MPL dependency or replacing it with Mp11,
untying it from boost::variant and others


> Boost Histogram has level 2 dependencies without Boost Serialization, which is opt-in. With Boost Serialization is has level 18, because Boost Serialization depends on the world. AFAIK rewriting Boost Serialization to drop Boost MPL would be a major effort.

I'm doubting that. A quick search shows that Serialization mostly uses
MPL things that are available in C++17 (like enable_if, true_type and
static_assert). Effort is required, but it is bearable.

Because of that effort we need time to make Boost17 usable. I'd be
able to move stacktrace and dll libraries in a few weeks. Mp11, Pfr
and Predef are ready to move. It may take much more time to move
Histogram or GIL


> Besides that, demanding 0 dependencies has serious drawbacks. Boost Histogram uses Boost functionality where there is no equivalent in the stdlib, not even in C++17 (Boost config, Boost throw_exception, Boost mp11, Boost core). I already reimplemented functionality in Boost Histogram that was originally found in other Boost libs to reduce coupling, like Boost Iterator and Boost Multiprecision. Boost Beast does this, too, it has its own variant type and more.

Not 0, close to 0. It is fine to reuse libraries if there is no
Standard Library replacement. It is not fine to use Boost version, if
there is a close alternative in the C++17


> A non-fundamental library like Histogram or Beast has the choice to either suffer a significant loss of functionality or use its own private implementation of Boost functionality to give the appearance of low dependencies. This inflates the private code of these libraries and maintaining private (duplicated) implementations is frankly crazy. We bundle Boost to make use of **synergies** between the libs. I should not use my private (potentially buggy) implementation of Boost iterator, I should use the official maintained (and hopefully less buggy) one.

Yep, we need to keep being reasonable during migration.


> Best regards,
> Hans



--
Best regards,
Antony Polukhin

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The new Boost 17.0.0

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 11/27/20 11:58 AM, Antony Polukhin via Boost wrote:

>
> == The Solution
> TL;DR: we need a C++17 fork of Boost with close to 0 dependencies
> between libraries and namespace versioning.
>
> С++17 provides many vocabulary types, feature test macro and a bunch
> of features for variadic templates. All of that allows us to drop a
> lot of weight and fix majority of popularity and usability problems.
>
> Rule of a thumb should be: "If the C++17 provides that functionality -
> use the standard version".

We went over this multiple times. I'll just reiterate that I disagree
with this approach. Many Boost libraries are superior to std
equivalents, and I want to keep using them inside and outside Boost.
Also, I don't see why Boost libraries are not allowed to exist as an
extension over the std equivalents.

> That approach would allow to loose a lot of weight, do not mess with
> vocabulary types and significantly reduce dependencies
> https://pdimov.github.io/boostdep-report/master/module-levels.html
>
> By levels:
> config 0 -> we probably would not need it any more

That's wishful thinking, unfortunately. Compiler bugs still exist, and
C++17 support level is not uniform across compilers. Moving forward,
later C++ versions are also not uniformly implemented.

> assert 1 -> 0

I'm not aware of a standard replacement of Boost.Assert. <cassert> is
not one.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The new Boost 17.0.0

Boost - Dev mailing list
пт, 27 нояб. 2020 г. в 13:36, Andrey Semashev via Boost <[hidden email]>:
> We went over this multiple times. I'll just reiterate that I disagree
> with this approach. Many Boost libraries are superior to std
> equivalents, and I want to keep using them inside and outside Boost.
> Also, I don't see why Boost libraries are not allowed to exist as an
> extension over the std equivalents.

That's why we are not dropping the existing Boost. There are many
users who share your point of view. But there are others, and we have
more and more of them year over year.


> > That approach would allow to loose a lot of weight, do not mess with
> > vocabulary types and significantly reduce dependencies
> > https://pdimov.github.io/boostdep-report/master/module-levels.html
> >
> > By levels:
> > config 0 -> we probably would not need it any more
>
> That's wishful thinking, unfortunately. Compiler bugs still exist, and
> C++17 support level is not uniform across compilers. Moving forward,
> later C++ versions are also not uniformly implemented.

We have feature test macro and Predef. IMO that's enough.


> > assert 1 -> 0
>
> I'm not aware of a standard replacement of Boost.Assert. <cassert> is
> not one.

Assert drops dependency on Config and moves to Level 0. I'm not
proposing to purge the library.

--
Best regards,
Antony Polukhin

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The new Boost 17.0.0

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
It's almost impossible to not top post from the phone, sorry!

I am just a simple user, even if long dated. For what is worth I don't
agree with the goal of 0 dependencies between boost libraries: this for me
goes against the spirit of the language. I agree that dependencies can grow
out of control and the unnecessary proliferation should be avoided (a lot
of work has been done on that)...

But what remains of "boost" if a boost library cannot use other boost
libraries? It becomes a "curated collection"... Which is worth while but
less so than boost librariES as a whole.

Sorry if I have a naive point of view, in my work and experience I don't
face the constraints of super large institutions and so maybe I am lacking
such perspective.

Best and sorry again for the top post,
Francesco

Il ven 27 nov 2020, 09:58 Antony Polukhin via Boost <[hidden email]>
ha scritto:

> Hi,
>
> == The problem.
> TL;DR: we are having huge troubles with usability and popularity!
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The new Boost 17.0.0

Boost - Dev mailing list
пт, 27 нояб. 2020 г. в 14:09, Francesco Guerrieri via Boost
<[hidden email]>:
>
> It's almost impossible to not top post from the phone, sorry!
>
> I am just a simple user, even if long dated. For what is worth I don't
> agree with the goal of 0 dependencies between boost libraries: this for me
> goes against the spirit of the language. I agree that dependencies can grow
> out of control and the unnecessary proliferation should be avoided (a lot
> of work has been done on that)...

OK, how about a goal "Use the C++17 standard version whenever
possible"? With that goal we would reach the required result, but the
goal wording is less obscure.

--
Best regards,
Antony Polukhin

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The new Boost 17.0.0

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 11/27/20 1:46 PM, Antony Polukhin wrote:
>>>
>>> By levels:
>>> config 0 -> we probably would not need it any more
>>
>> That's wishful thinking, unfortunately. Compiler bugs still exist, and
>> C++17 support level is not uniform across compilers. Moving forward,
>> later C++ versions are also not uniformly implemented.
>
> We have feature test macro and Predef. IMO that's enough.

I don't think it is. There are a bunch of non-standard attribute macros,
which vary from one compiler to another. There are quite a few relevant
compiler bug macros. There are non-standard feature detection macros.
Boost.Predef don't implement those.

Also, feature test macros for standard library features are useless, as
they require including the standard library headers. <version> only
appears in C++20.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The new Boost 17.0.0

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, 2020-11-27 at 11:58 +0300, Antony Polukhin via Boost wrote:

> == The problem.
> * it is huge, in consists of legacy on more than a half, with a lot
> of
> dependencies between libraries. This is extremely painful for big
> companies, because there's no efficient distributed build system.
> Each
> company invents it's own and/or tries to minimize headers by all
> means.
>
> == The Solution
> TL;DR: we need a C++17 fork of Boost with close to 0 dependencies
> between libraries and namespace versioning.
>
>
> == Action points
> 0) Discuss
> 1) Bury the idea, wait for a few years, goto 0); or make a boost17
> repo with the same layout as the existing one, but without submodules
> 2) start the migration
>
> --
> Best regards,
> Antony Polukhin
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost


If I may propose another course of action for discussion what about a
Boost 2.0 that is based on the C++20 standard? One of the goals of
modules was to reduce compile times/overhead especially with monolithic
libraries like boost. After a module has been imported one time it
should be nearly free to use thereafter. Clang, GCC, and MSVC all have
experimental support for modules to begin development of Boost 2.0. If
we are truly concerned about adoption in the future I would not expend
significant time and effort to rewrite using what is now a past
language standard, and instead look forward. As for how to execute
this? We could use the python 2/3 model where both are supported with a
published countdown to when new development ceases on the old version.

Matt





_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The new Boost 17.0.0

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, 27 Nov 2020 at 10:58, Antony Polukhin via Boost
<[hidden email]> wrote:
> ISO C++ WG21 community not willing to push prototypes into Boost. "We
> aim to establish "existing practice" and provide reference
> implementations so that Boost libraries are suitable for eventual
> standardization." - that's not really true any more.

..well.. it might end up being true for different libraries than it
was before. More below.

> == The Solution
> TL;DR: we need a C++17 fork of Boost with close to 0 dependencies
> between libraries and namespace versioning.
>
> С++17 provides many vocabulary types, feature test macro and a bunch
> of features for variadic templates. All of that allows us to drop a
> lot of weight and fix majority of popularity and usability problems.

Well, yeah. There was a long period of time during which boost was a
very significant library,
because it had multithreading and better smart pointer. Then WG21 woke
up, shipped C++11,
and *bam*, a sizeable portion of boost's attraction vanished,
especially since C++11 was rapidly
adopted all over the place.

Boost still has things that are alluring. Networking is alluring for
quite some time still. Beast is alluring.
JSON is alluring. I find it interesting that the alluring bits are now
much more high-level than they
used to be. Perhaps there's something there.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

The new Boost 17.0.0

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> Gesendet: Freitag, 27. November 2020 um 11:36 Uhr
> Von: "Andrey Semashev via Boost" <[hidden email]>
>
> On 11/27/20 11:58 AM, Antony Polukhin via Boost wrote:
> >
> > == The Solution
> > TL;DR: we need a C++17 fork of Boost with close to 0 dependencies
> > between libraries and namespace versioning.
> >
> > С++17 provides many vocabulary types, feature test macro and a bunch
> > of features for variadic templates. All of that allows us to drop a
> > lot of weight and fix majority of popularity and usability problems.
> >
> > Rule of a thumb should be: "If the C++17 provides that functionality -
> > use the standard version".
>
> We went over this multiple times. I'll just reiterate that I disagree
> with this approach. Many Boost libraries are superior to std
> equivalents, and I want to keep using them inside and outside Boost.
> Also, I don't see why Boost libraries are not allowed to exist as an
> extension over the std equivalents.
>

Speaking for me in particular: What does annoy me, is if a boost library
uses the boost equivalent of a standard library vocabulary type in its
interface. E.g. boost::string_view instead of std::string_view or
boost::chrono::duration instead of std::chrono::duration.

As far as other duplications go:
If (and I really want to stress the if) using the boost version adds
significant compiletime or binary size overhead compared to the std version
then I'd also prefer if the std versions were used in the implementation
where possible. Otherwise I as a user don't really care.
The difference in compiletime might happen when the boost version using some
complex TMP (especially mpl) hacks whereas the std version can use more
efficient language constructs - and of course the std version almost always
ends up in my translation unit anyway, so compiling the boost equivalent is
just some additional work, but I don't have any experimental data to show if
there are actually any significant gains possible inpractice.


Regarding the proposal in general: Let me play the devil's advocate and ask, how
many active boost maintainers there are left. Are there enough to pull through with
something like that, without loosing a big chunk of the libs for which there
isn't a good c++17 equivalent yet (or ever).

Actually, that would be an argument for removing internal dependencies on boost
libs that have a c++17 equivalent: Reduced overall maintenence overhead for boost
once you are there and more flexibility for individual libs. But of course I'm
certainly not able to predict, if it would be a net win or not.


Best

Mike



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The new Boost 17.0.0

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, Nov 27, 2020 at 12:58 AM Antony Polukhin via Boost
<[hidden email]> wrote:
> asio 18 -> 3?
> beast 19 -> 4?

Beast depends on Asio, so you will have to convince Christopher
Kohlhoff to go along with this idea for Asio.

Thanks

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The new Boost 17.0.0

Boost - Dev mailing list
On 27/11/2020 12:19, Vinnie Falco via Boost wrote:
> On Fri, Nov 27, 2020 at 12:58 AM Antony Polukhin via Boost
> <[hidden email]> wrote:
>> asio 18 -> 3?
>> beast 19 -> 4?
>
> Beast depends on Asio, so you will have to convince Christopher
> Kohlhoff to go along with this idea for Asio.

It is one of those rare occasions that I agree with Vinnie.

If I were Chris K, I'd respond "If you want to use Boost.ASIO with the
standard C++ library, please go use Standalone ASIO. Boost.ASIO is
specifically ASIO targeting Boost".

I have that exact opinion regarding Outcome, incidentally, though I made
it a bit easier to bash Boost.Outcome with a stick into 100% not using
Boost than Chris K has with ASIO (which BTW is also possible, in theory).

Niall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The new Boost 17.0.0

Boost - Dev mailing list
> Gesendet: Freitag, 27. November 2020 um 13:26 Uhr
> Von: "Niall Douglas via Boost" <[hidden email]>
>
> On 27/11/2020 12:19, Vinnie Falco via Boost wrote:
> > On Fri, Nov 27, 2020 at 12:58 AM Antony Polukhin via Boost
> > <[hidden email]> wrote:
> >> asio 18 -> 3?
> >> beast 19 -> 4?
> >
> > Beast depends on Asio, so you will have to convince Christopher
> > Kohlhoff to go along with this idea for Asio.
>
> If I were Chris K, I'd respond "If you want to use Boost.ASIO with the
> standard C++ library, please go use Standalone ASIO. Boost.ASIO is
> specifically ASIO targeting Boost".

Whats the problem? Shouldn't that essentially just be a matter of tweaking
boostify.pl to replace fewer std types from the no-boost reference code
with boost equivalents than it currently does? Or is there more to it?

Best

Michael

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The new Boost 17.0.0

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 11/27/2020 3:58 AM, Antony Polukhin via Boost wrote:

> Hi,
>
> == The problem.
> TL;DR: we are having huge troubles with usability and popularity!
>
> Quite a lot of companies forbid using Boost because:
> * it provides vocabulary types, that should be the same across the
> whole project (like shared_ptr, filesystem::path or optional).
> Otherwise it's hard to combine different APIs
> * it is huge, in consists of legacy on more than a half, with a lot of
> dependencies between libraries. This is extremely painful for big
> companies, because there's no efficient distributed build system. Each
> company invents it's own and/or tries to minimize headers by all
> means.
>
> New companies (startups) also avoid Boost:
> * "We are using C++17, we do not want legacy libraries with C++98 support"

If a library provides support for C++98/2003 but also works perfectly
fine using C++17, please explain to me what is wrong with using that
library when compiling for C++17 ? Thank you !

> * Junior developers are confused by multiple vocabulary types. "Should
> we use boost::optional or std::optional?"

See CXXD ( https://github.com/eldiener/cxx_dual ) or always use standard
libraries when available.

> * hard to upgrade, because symbols are not versioned

Versioned symbols ?



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The new Boost 17.0.0

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Friday, November 27, 2020, Antony Polukhin  wrote:.
>
>
> == Action points
> 0) Discuss
> 1) Bury the idea, wait for a few years, goto 0); or make a boost17
> repo with the same layout as the existing one, but without submodules
> 2) start the migration
>
>


One thing you could try, without requiring that the rest of us do anything,
is drop C++03 support  from your Boost libraries and use only C++17
standard library types on interfaces in a future Boost release and evaluate
the effect.

(If existing Boost libraries depend on yours and the authors still want to
maintain compatibility, maybe they will reimplement that themselves. Or
not).

Another thing you could try is creating this new collection of libraries
yourself.  You might not get to call it Boost, but you can grab all the
Boost libraries you want, strip them of C++03 support, make them use C++17
features, and ship this collection and evaluate how popular it is.

Either option will get you (and the rest of us) some data that could
motivate Boost's future.

Otherwise do the homework and read every single other thread like this in
the Boost archive to see why people are against it, or not motivated by it,
or why it will be at stage (0) forever unless you're willing to take action
yourself.

Glen

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The new Boost 17.0.0

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, Nov 27, 2020 at 12:56 PM Matt Borland via Boost <
[hidden email]> wrote:

> On Fri, 2020-11-27 at 11:58 +0300, Antony Polukhin via Boost wrote:
> > == The Solution
> > TL;DR: we need a C++17 fork of Boost with close to 0 dependencies
> > between libraries and namespace versioning.
>
> If I may propose another course of action for discussion what about a
> Boost 2.0 that is based on the C++20 standard? One of the goals of
> modules was to reduce compile times/overhead especially with monolithic
> libraries like boost. After a module has been imported one time it
> should be nearly free to use thereafter. [...]
> We could use the python 2/3 model where both are supported with a
> published countdown to when new development ceases on the old version.
>

Hi. I like that idea. I'm on C++17 and Boost 1.74, likely for a long time*,
so a C++17
Boost fork would work better for me, but C++20's modules and concepts do
seem
like a stronger base for a Boost 2.0 and would yield bigger bang for the
buck, longer term.

Boost 1.0 would remain, mostly as it is currently, with a wide range of
supported standards and compilers.
But a subset of Boost would be modularized and ported to C++20 and later,
taking full advantage of that much higher footing.

I also think Boost 2.0 should not try to work around buggy C++20 compilers
(and std-lib), and simply accept
that some advanced libraries won't work on non-conforming C++20 compilers.
Kinda like Boost.Hana didn't
try to work-around MSVC bugs of the past. Have Boost 2.0 look forward to
the future, and the next 10/20 years
while letting Boost 1.0 look back at the past 20 years (with still some
maintenance for the near future).
The analogy with Python2/3 is also a good one IMHO.

This is just wishful thinking of course. Maintainers may not want to port
to Boost 2.0 >= C++20 while still
maintaining Boost 1.0. I just think Boost needs a second breath, and a
clean reboot for the next decade.

FWIW, --DD

* Like many companies, we upgrade compilers and dependencies only every 2-3
years.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The new Boost 17.0.0

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 27/11/2020 12:36, Mike via Boost wrote:

>> Gesendet: Freitag, 27. November 2020 um 13:26 Uhr
>> Von: "Niall Douglas via Boost" <[hidden email]>
>>
>> On 27/11/2020 12:19, Vinnie Falco via Boost wrote:
>>> On Fri, Nov 27, 2020 at 12:58 AM Antony Polukhin via Boost
>>> <[hidden email]> wrote:
>>>> asio 18 -> 3?
>>>> beast 19 -> 4?
>>>
>>> Beast depends on Asio, so you will have to convince Christopher
>>> Kohlhoff to go along with this idea for Asio.
>>
>> If I were Chris K, I'd respond "If you want to use Boost.ASIO with the
>> standard C++ library, please go use Standalone ASIO. Boost.ASIO is
>> specifically ASIO targeting Boost".
>
> Whats the problem? Shouldn't that essentially just be a matter of tweaking
> boostify.pl to replace fewer std types from the no-boost reference code
> with boost equivalents than it currently does? Or is there more to it?

Yes, it's support costs for additional build variants.

From my perspective, I already support an Outcome targeting Boost and an
Outcome targeting the standard library. If somebody else wants to do
more work to support a third build variant, cool. But it won't be me.

(For added information, I know of two forks of Outcome maintained by
others. One didn't like my build system and so completely replaced it;
the other needed to customise Outcome for a proprietary platform to an
extent I wasn't willing to support)

Outcome consumes a fraction of the effort required to support ASIO, and
even then, supporting Outcome has consumed 100% of my non-work free
hours for two weeks now, thanks to Travis requiring replacement with
Github Actions, and just released VS2019.8 ICEing when fed Outcome which
of course produced a bunch of urgent support requests. Sigh.

Niall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The new Boost 17.0.0

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Speaking only for myself as an author of a Boost library, maintainer
of many Boost libraries, and contributor to many Boost libraries,  as
well as being involved in the Boost release process:

1. Based on my personal knowledge of Boost users, as well as e-mails
to the Boost developers lists (boost@...), and the Boost Owners  lists
(boost-owner@...) from users such as:
   -    @us.af.mil  (US Airforce)
   -   @nasa.gov  (NASA)
  and others

I would not be in favor of a Boost distribution that requires anything
higher than C++11 for existing libraries. i.e. Not C++17 or even
C++14.

2. Based on first hand accounts of certain users choosing not to
migrate to C++20 because of a silently breaking change in the language
affecting their code (operator== rewriting rules, which has even
broken certain Boost libraries like Rational), I would certainly not
be in favor of changing existing Boost libraries to require C++20 for
anything in an official Boost distribution.

Glen

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The new Boost 2.0 C++20

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Dominique Devienne via Boost said:     (by the date of Fri, 27 Nov 2020 15:04:50 +0100)

> Hi. I like that idea. I'm on C++17 and Boost 1.74, likely for a long time*,
> so a C++17  Boost fork would work better for me, but C++20's
> modules and concepts do seem like a stronger base for a Boost 2.0
> and would yield bigger bang for the buck, longer term.

I completely agree. Let the boost versions 1.74, 1.75, 1.76 etc
remain C++Old compliant, and can be maintained as long as one wishes
to maintain it. And start the 2.00, 2.01, 2.02 boost releases
versioning which takes a new breath by fully utilizing the new C++20 features.

No workarounds broken compilers is also a good idea.

--
# Janek Kozicki                              http://janek.kozicki.pl/

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
1234 ... 7