[boost] The new Boost 17.0.0

[Antony Polukhin via Boost]

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

[Hans Dembinski via Boost]

> On 27. Nov 2020, at 09:58, Antony Polukhin via Boost <bo...@lists.boost.org> 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

[Antony Polukhin via Boost]

пт, 27 нояб. 2020 г. в 12:46, Hans Dembinski <hans.de...@gmail.com>:

>
>
> > On 27. Nov 2020, at 09:58, Antony Polukhin via Boost <bo...@lists.boost.org> 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

_______________________________________________

[Andrey Semashev via Boost]

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.

[Antony Polukhin via Boost]

пт, 27 нояб. 2020 г. в 13:36, Andrey Semashev via Boost <bo...@lists.boost.org>:

> 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

_______________________________________________

[Francesco Guerrieri via Boost]

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 <bo...@lists.boost.org>
ha scritto:

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

[Antony Polukhin via Boost]

пт, 27 нояб. 2020 г. в 14:09, Francesco Guerrieri via Boost
<bo...@lists.boost.org>:

>
> 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

_______________________________________________

[Andrey Semashev via Boost]

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.

[Matt Borland via Boost]

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

[Ville Voutilainen via Boost]

On Fri, 27 Nov 2020 at 10:58, Antony Polukhin via Boost
<bo...@lists.boost.org> 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.

[Mike via Boost]

> Gesendet: Freitag, 27. November 2020 um 11:36 Uhr
> Von: "Andrey Semashev via Boost" <bo...@lists.boost.org>

>
> 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

[Vinnie Falco via Boost]

On Fri, Nov 27, 2020 at 12:58 AM Antony Polukhin via Boost
<bo...@lists.boost.org> 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

[Niall Douglas via Boost]

On 27/11/2020 12:19, Vinnie Falco via Boost wrote:
> On Fri, Nov 27, 2020 at 12:58 AM Antony Polukhin via Boost
> <bo...@lists.boost.org> 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

[Mike via Boost]

> Gesendet: Freitag, 27. November 2020 um 13:26 Uhr
> Von: "Niall Douglas via Boost" <bo...@lists.boost.org>

>
> On 27/11/2020 12:19, Vinnie Falco via Boost wrote:
> > On Fri, Nov 27, 2020 at 12:58 AM Antony Polukhin via Boost
> > <bo...@lists.boost.org> 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

[Edward Diener via Boost]

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 ?

[Glen Fernandes via Boost]

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

[Dominique Devienne via Boost]

On Fri, Nov 27, 2020 at 12:56 PM Matt Borland via Boost <
bo...@lists.boost.org> 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.

[Niall Douglas via Boost]

On 27/11/2020 12:36, Mike via Boost wrote:
>> Gesendet: Freitag, 27. November 2020 um 13:26 Uhr
>> Von: "Niall Douglas via Boost" <bo...@lists.boost.org>
>>
>> On 27/11/2020 12:19, Vinnie Falco via Boost wrote:
>>> On Fri, Nov 27, 2020 at 12:58 AM Antony Polukhin via Boost
>>> <bo...@lists.boost.org> 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

[Glen Fernandes via Boost]

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

[Janek Kozicki via Boost]

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/

[Andrey Semashev via Boost]

On 11/27/20 5:15 PM, Glen Fernandes via Boost wrote:
>
> 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.

I have to say that I'm also hesitant to upgrade my projects to C++20,
while going through 11, 14 and 17 was rather easy. That operator
rewriting issue is a blocker, and it's not even clear if there will be a
resolution before C++23 or however it will be called.

[Ville Voutilainen via Boost]

On Fri, 27 Nov 2020 at 17:01, Andrey Semashev via Boost
<bo...@lists.boost.org> wrote:
>
> On 11/27/20 5:15 PM, Glen Fernandes via Boost wrote:
> >
> > 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.
>
> I have to say that I'm also hesitant to upgrade my projects to C++20,
> while going through 11, 14 and 17 was rather easy. That operator
> rewriting issue is a blocker, and it's not even clear if there will be a
> resolution before C++23 or however it will be called.

A resolution proposal is already under discussion.

[Dominique Devienne via Boost]

On Fri, Nov 27, 2020 at 3:15 PM Glen Fernandes via Boost <
bo...@lists.boost.org> wrote:

> 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.
>

But that's basically Boost as it stands, i.e. Boost 1.x.
I don't think anyone's proposing to drop that.

> 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.
>

But isn't this just a "teething" issue? I see Ville already replied in fact.

There will of course be few large codebases making the jump to C++20 in the
near future, after all we're still in 2020 and that standard is just
hot-off-the-press.

But we're discussing the next 10-20 years of Boost, not the next 10 months.
And only to start Boost 2.x, not to abandon Boost 1.x.

You are of course a pillar of Boost, while I'm a nobody, so what I say
doesn't matter much,
but either modules (and concepts) are a game changer, and it's worth
modularizing Boost
(not at the Git level, but C++ level), or C++20 modules are a mis-feature
and then indeed
why ever start a Boost 2.x? I'm of course referring to full-blown modules,
not just wrapping
headers to have glorified precompiled headers (although I'm out of my depth
here, so I'd
better shut-up :)). My $0.02. --DD

[Glen Fernandes via Boost]

Dominique Devienne wrote:
>
> Glen Fernandes wrote

>> 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.
>
> But that's basically Boost as it stands, i.e. Boost 1.x.
> I don't think anyone's proposing to drop that.

That's Boost 1.x with more C++11 and less C++03 - with authors who
choose to drop C++03 support, requiring C++11 at a minimum as per:
https://pdimov.github.io/articles/phasing_out_cxx03.html

This is something which Boost authors are actually acting on. e.g.
Boost.Math and Boost.Multiprecision as of a future Boost 1.77 release:
https://www.boost.org/users/history/version_1_73_0.html

<quote>
Math
* IMPORTANT: C++03 support is now deprecated and will be removed
from March 2021.
</quote>

<quote>
Multiprecision
* IMPORTANT: C++03 support is now deprecated and will be removed
from March 2021.
</quote>

i.e. This is promising because people support this particular proposal
enough to do something, not just for the (potentially unlimited) joy
of discussing it on a list.

> But isn't this just a "teething" issue? I see Ville already replied in fact.

I'm following this discussion over this in C++ committee EWG
reflector. I'm optimistic that people will do the right thing by
users. But I prefer to make decisions based on what I know now, and
what has bitten users today, with -std=c++20 and GCC 10.1 that has
already shipped, not speculation about what will happen.

As I said before, this is just me. C++11 (not higher, not C++17 or
C++20) is just what I support and what I'd be willing to put in work
towards in existing Boost libraries (and even volunteer to do for
those that I do not currently maintain, but would welcome the
contributions). Other authors remain free to drop support for
everything besides C++17 or C++20 if they want.

Glen

[Glen Fernandes via Boost]

On Fri, Nov 27, 2020 at 11:09 AM Glen Fernandes wrote:
> I'm following this discussion over this in C++ committee EWG
> reflector. I'm optimistic that people will do the right thing by
> users. But I prefer to make decisions based on what I know now, and
> what has bitten users today, with -std=c++20 and GCC 10.1 that has
> already shipped, not speculation about what will happen.
>
> As I said before, this is just me. C++11 (not higher, not C++17 or
> C++20) is just what I support and what I'd be willing to put in work
> towards in existing Boost libraries (and even volunteer to do for
> those that I do not currently maintain, but would welcome the
> contributions). Other authors remain free to drop support for
> everything besides C++17 or C++20 if they want.
>
> Glen

Note that despite what I feel about the "minimum' required C++
version, I'm responsible for fixing C++20 compatibility in at least
the following libraries:
* Bimap
* Format
* Signals2
* Rational
* Polygon
* uBLAS (though this wasn't merged for the 1.75 release yet)

So I'm all for supporting C++20, just not requiring C++20. :)

[Francesco Guerrieri via Boost]

On Fri, Nov 27, 2020 at 12:27 PM Antony Polukhin <anto...@gmail.com>
wrote:

> пт, 27 нояб. 2020 г. в 14:09, Francesco Guerrieri via Boost
> <bo...@lists.boost.org>:
> >
> > 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
>

Hi Antony,

this is a much clearer goal and I can see why a new library - or a subset
of the libraries - could aim for that. On the other hand Boost has a very
strong tradition and has proven its importance over and over, in providing
useful - or indispensable - tools even when the environment is old/obscure.
I don't think that it would be a good idea to suddenly "drop" this
support.. and why should developers, already a scarce resource, "waste
time" in removing support from something that is working and is potentially
useful for many users? On the other hand there could very well be cases of
libraries who are severely constrained if they are forced to support older
standards. In that case it would be a very reasonable call to "move" to
C++17.

But I wonder, is this really new? Hasn't every developer until now declared
a specific goal (I want to support only C++11 onward, even C++03... only
gcc X.Y for X and Y greater than ...)?

So are you calling to action for a more stringent requirement on C++17,
with a conversion of existing libraries and dropping (part of) the support
for older standards? or are you calling for a more enthusiastic adoption of
the new standard?

Sorry if I am missing something and thanks for your reply.

Best,
Francesco

[Mathias Gaunard via Boost]

On Fri, 27 Nov 2020 at 10:36, Andrey Semashev via Boost
<bo...@lists.boost.org> wrote:

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

A tangent, but I'd rather use a simple and standard component that is
used throughout all kinds of C and C++ code that some boost-specific
thing that adds zero value.
If you want to set a custom handler, just hook on SIGABRT, which will
catch a lot more things than defining boost::assertion_failed.
If you want to know where the assertion handler happened, just learn
how to use core files or how to dump the stack yourself.

[Peter Dimov via Boost]

Mathias Gaunard wrote:

> A tangent, but I'd rather use a simple and standard component that is used
> throughout all kinds of C and C++ code that some boost-specific thing that
> adds zero value.

The purpose of BOOST_ASSERT is to provide the ability for controlling
assertions in Boost libraries without affecting all other uses of the
standard `assert`.

[Emil Dotchevski via Boost]

Deleting support for C++11 and older versions means breaking user code.
Therefore, forking means fracturing of the community. I don't see how this
is helpful to the users.

Further: are you saying that there is something wrong with some libraries
that are part of Boost becoming standard in the future? How are we going to
deal with the resulting two versions later on? Fork again? No, we'll deal
with it the same way we deal with e.g. boost::error_code/std::error_code
today (as an aside, it is notable that users who use exception handling
don't have this specific problem, because exception types are not coupled
with function signatures).

[Paul A Bristow via Boost]

> -----Original Message-----
> From: Boost <boost-...@lists.boost.org> On Behalf Of Emil Dotchevski via Boost
> Sent: 27 November 2020 23:26
> To: Boost <bo...@lists.boost.org>
> Cc: Emil Dotchevski <emildot...@gmail.com>
> Subject: Re: [boost] The new Boost 17.0.0
>
> Deleting support for C++11 and older versions means breaking user code.
> Therefore, forking means fracturing of the community. I don't see how this is helpful to the
users.

Nearly all of Boost is still C++03 compatible - It is only key or core libraries that have this big
and bad effect.

(People using Boost.Math to calculate a probability will still be able to - nothing much has
changed).

We have an excellent track record for providing workarounds that keep the old version working where
possible, while using macros to allow improvements from using new language features.

Eventually library authors run of out road, and/or patience, and say "enough - I need Cxx-more" but
it's a slow and continuous process.

Our continuous progress but keep as much working as possible strategy has worked very well for
decades.

The difficulty with our strategy is selling it to potential users who are desperate to be able to
tick a box marked 'Cxx-supported'.
It gives them a warm feeling, but little in reality.

Somehow we don't seem to be able to sell our strategy.

But if we get to Boost 17, Boost 20 and Boost 23 will soon follow. Won't more Boost 1 (and then 17,
23...) users be frightened off/confused?

Paul

PS And KISS applies? (Keep Is Simple Sirs)

[Rainer Deyke via Boost]

On 28.11.20 00:25, Emil Dotchevski via Boost wrote:
> Deleting support for C++11 and older versions means breaking user code.
> Therefore, forking means fracturing of the community. I don't see how this
> is helpful to the users.

The current status quo is that individual library maintainers can choose
to drop support for old C++ standards at any time. This means that user
are often stuck on a specific version of the 1.x line. From a user
perspective, forking is an improvement over the status quo: it means
that Boost can guarantee that the 1.x line can stop dropping support for
old C++ standards, making it relatively safe to upgrade within the 1.x line.

One of the big weaknesses of Boost, from a user perspective, is the way
releases are handled, with each release potentially containing breaking
changes bundled along with the bug fixes and new features. What I'd
really like to see is a policy where breaking changes are reserved for
major (x.0) versions, with minor (x.y) versions only containing bug
fixes and backwards-compatible new features. Since the major versions
aren't expected to be completely backwards-compatible, they could make
relatively bold changes like dropping obsolete libraries.

(The drawback of this approach is of course that on the developer side
it's a lot more work to support multiple versions of a library in
parallel. I have deliberately taken a user-centric view here.)


--
Rainer Deyke (rai...@eldwood.com)

[Mike via Boost]

> Gesendet: Samstag, 28. November 2020 um 13:28 Uhr
> Von: "Paul A Bristow via Boost" <bo...@lists.boost.org>

>
>
> The difficulty with our strategy is selling it to potential users who are desperate to be able to
> tick a box marked 'Cxx-supported'.
> It gives them a warm feeling, but little in reality.

Aren't you dismissing the voiced concerns too easily?
I want to be able to interact with libraries using standard library vocabulary types
and I don't want my compiletimes to explode when using them. Supporting
old c++ standards as many boost libs do can be a problem for both of
those goal:
- Apparently a lot of the compilation slowdown is due to the use of
boost.MPL, which could be replaced in c++11 by mp11 or language constructs.
- Obviously a c++03 lib can't use std::chrono::duration or std::string_view
in its interface. The former can sometimes be added as additional overload
if available, however, adding the latter almost certainly leads to ambiguous
overload resolution situations. So instead I have to convert the c++11/17/20
types into the appropriate boost types.

I'm naming just the two examples that are most relavant to me (I can think of a
few more) but the point is:
This is not about "having a warm feeling", but about the real costs for users
that are a result from the continued support of c++03 and in particular the usage
of boost types that have been "merged" into the standard library orthe language.

The difficult part is to place numbers on those costs and especially putting them
in relation to the boost user base. It may very well be, that most of the people
that are still using boost at all don't use more recent standards or that those
costs are insigificantt to them and that the people complaining about the state
of boost the loudest don't have any real interest in using boost anyway. Point in
case: Almost all projects I'm involved in have removed their boost dependencies
if they had any to begin with.
So people like me might simply not be a relevant target audience for boost.

Best

Mike

>
> PS And KISS applies? (Keep Is Simple Sirs)
>

There is a lot that can be said about boost but "simple" is certainly not
something that comes to mind. Certainly not when we are talking about the
implementation and - depending on the lib - not even when considering their
usage.

[Edward Diener via Boost]

I agree with this completely.

There is only one other issue which I believe is important for end-users
using Boost libraries in relation to the C++ standard level, which is
that when end-users compile with a certain C++ standard level they are
most likely using in their own code C++ standard libraries at that level
while Boost libraries compiled at that same C++ standard level may often
be using one or more Boost library equivalents to C++ standard library.
The end-user I think has a right to be a bit annoyed at this bifurcation
of C++ standard library/Boost library equivalent which must then occur
in their code in order to use for them useful Boost libraries. Therefore
in this sense, and in this sense only, can I understand a call for Boost
to provide a set of libraries which, when compiled at the C++11 ( or
above ), only use the equivalent C++ standard libraries. This is not in
any way to denigrate the Boost equivalent libraries to various C++
standard libraries, since the Boost equivalent libraries sometimes
contain more and/or better features or are better designed than their
C++ standard library equivalents. But it is still fairly reasonable to
understand that, for some given Boost library which an end-user would
find useful in his code, dependence on a Boost library when the
equivalent C++ standard library is available, might be a strong negative
from the end-users point of view not only based on an added dependency
but also based on the complication in the end-user's code.

[Edward Diener via Boost]

On 11/28/2020 11:47 AM, Mike via Boost wrote:
>> Gesendet: Samstag, 28. November 2020 um 13:28 Uhr
>> Von: "Paul A Bristow via Boost" <bo...@lists.boost.org>
>>
>>
>> The difficulty with our strategy is selling it to potential users who are desperate to be able to
>> tick a box marked 'Cxx-supported'.
>> It gives them a warm feeling, but little in reality.
>
> Aren't you dismissing the voiced concerns too easily?
> I want to be able to interact with libraries using standard library vocabulary types
> and I don't want my compiletimes to explode when using them. Supporting
> old c++ standards as many boost libs do can be a problem for both of
> those goal:
> - Apparently a lot of the compilation slowdown is due to the use of
> boost.MPL, which could be replaced in c++11 by mp11 or language constructs.

Proof please about compilation slowdown regarding MPL versus mp11.

> - Obviously a c++03 lib can't use std::chrono::duration or std::string_view
> in its interface. The former can sometimes be added as additional overload
> if available, however, adding the latter almost certainly leads to ambiguous
> overload resolution situations. So instead I have to convert the c++11/17/20
> types into the appropriate boost types.

I think this is valid. But you are certainly allowed to create a PR for
a Boost library which changes its use of a Boost type to its C++
standard library equivalent, with the proviso that the Boost library's
base C++ level be C++11 and not C++03. The latter should not be an issue
since Boost has already stated that Boost officially supports C++11 on
up. Do realize, however, that a number of Boost libraries which have
C++11 on up standard library equivalents actually offer more
functionality than their C++ standard library equivalent, and that the
added functionality may be necessary for some other Boost library.

[Peter Dimov via Boost]

Rainer Deyke wrote:

> From a user perspective, forking is an improvement over the status quo: it
> means that Boost can guarantee that the 1.x line can stop dropping support
> for old C++ standards, making it relatively safe to upgrade within the 1.x
> line.

This is only an improvement in the imaginary world where we have enough
resources to maintain two forks. In reality, we have trouble maintaining
one.

[Peter Dimov via Boost]

Edward Diener wrote:

> Proof please about compilation slowdown regarding MPL versus mp11.

http://metaben.ch/

[Rainer Deyke via Boost]

On 28.11.20 19:07, Peter Dimov via Boost wrote:
> Rainer Deyke wrote:
>
>> From a user perspective, forking is an improvement over the status
>> quo: it means that Boost can guarantee that the 1.x line can stop
>> dropping support for old C++ standards, making it relatively safe to
>> upgrade within the 1.x line.
>
> This is only an improvement in the imaginary world where we have enough
> resources to maintain two forks. In reality, we have trouble maintaining
> one.

Yes, that's why I wrote "from a user perspective". I'm not saying that
this a practicable solution. I'm just saying that it would be nice if
it were.

I think it /might/ be possible to mark some releases (maybe one every
two years?) as "major", and delay the release of breaking changes for
the next major release. Actively developing on two or more branches in
parallel is probably just fantasy though.


--
Rainer Deyke (rai...@eldwood.com)

[Emil Dotchevski via Boost]

On Sat, Nov 28, 2020 at 5:23 AM Rainer Deyke via Boost <
bo...@lists.boost.org> wrote:
>
> On 28.11.20 00:25, Emil Dotchevski via Boost wrote:
> > Deleting support for C++11 and older versions means breaking user code.
> > Therefore, forking means fracturing of the community. I don't see how
this
> > is helpful to the users.
>
> The current status quo is that individual library maintainers can choose
> to drop support for old C++ standards at any time. This means that user
> are often stuck on a specific version of the 1.x line.

You're trying to say that the status quo is to break user code. The actual
status quo is to have the option to break user code. Above, you're arguing
that breaking user code sucks for the users. Agreed.

> One of the big weaknesses of Boost, from a user perspective, is the way
> releases are handled, with each release potentially containing breaking
> changes bundled along with the bug fixes and new features. What I'd
> really like to see is a policy where breaking changes are reserved for
> major (x.0) versions, with minor (x.y) versions only containing bug
> fixes and backwards-compatible new features. Since the major versions
> aren't expected to be completely backwards-compatible, they could make
> relatively bold changes like dropping obsolete libraries.
>
> (The drawback of this approach is of course that on the developer side
> it's a lot more work to support multiple versions of a library in
> parallel. I have deliberately taken a user-centric view here.)

This can be done at the library level. The "drawback" is that the library
developer who breaks user code has more work to do, which in my mind is
excellent.

[Emil Dotchevski via Boost]

On Sat, Nov 28, 2020 at 5:20 AM Paul A Bristow via Boost <
bo...@lists.boost.org> wrote:
> But if we get to Boost 17, Boost 20 and Boost 23 will soon follow. Won't
more Boost 1 (and then 17,
> 23...) users be frightened off/confused?

Hello, in our code base we use Boost, Boost 17 and Boost 23. When I try to
...... I get a core dump. Please help!

[Peter Dimov via Boost]

Rainer Deyke wrote:
> On 28.11.20 19:07, Peter Dimov via Boost wrote:
> > Rainer Deyke wrote:
> >
> >> From a user perspective, forking is an improvement over the status quo:
> >> it means that Boost can guarantee that the 1.x line can stop dropping
> >> support for old C++ standards, making it relatively safe to upgrade
> >> within the 1.x line.
> >
> > This is only an improvement in the imaginary world where we have enough
> > resources to maintain two forks. In reality, we have trouble maintaining
> > one.
>
> Yes, that's why I wrote "from a user perspective". I'm not saying that
> this a practicable solution. I'm just saying that it would be nice if it
> were.

Nice for the end user, perhaps, but intermediate libraries are now forced to
choose between using boost or boost2, or maintaining two versions.

My alternative idea of "nice to have" is a single Boost library that can use
either boost or std components in its interface. That's not always possible
to obtain though.

[Edward Diener via Boost]

On 11/28/2020 4:59 PM, Peter Dimov via Boost wrote:
> Rainer Deyke wrote:
>> On 28.11.20 19:07, Peter Dimov via Boost wrote:
>> > Rainer Deyke wrote:
>> >
>> >> From a user perspective, forking is an improvement over the status
>> quo: >> it means that Boost can guarantee that the 1.x line can stop
>> dropping >> support for old C++ standards, making it relatively safe
>> to upgrade >> within the 1.x line.
>> >
>> > This is only an improvement in the imaginary world where we have
>> enough > resources to maintain two forks. In reality, we have trouble
>> maintaining > one.
>>
>> Yes, that's why I wrote "from a user perspective".  I'm not saying
>> that this a practicable solution.  I'm just saying that it would be
>> nice if it were.
>
> Nice for the end user, perhaps, but intermediate libraries are now
> forced to choose between using boost or boost2, or maintaining two
> versions.
>
> My alternative idea of "nice to have" is a single Boost library that can
> use either boost or std components in its interface. That's not always
> possible to obtain though.

ROFL.

"How would you link all the variations of that library if the library
were not a header-only library. You would have to have a different name
for each combination and the number of combinations would proliferate to
an unusable number. What a pipe dream you have !"

<g>

[Mike via Boost]

> Gesendet: Samstag, 28. November 2020 um 18:32 Uhr
> Von: "Edward Diener via Boost" <bo...@lists.boost.org>

>
> On 11/28/2020 11:47 AM, Mike via Boost wrote:
> >> Gesendet: Samstag, 28. November 2020 um 13:28 Uhr
> >> Von: "Paul A Bristow via Boost" <bo...@lists.boost.org>
> >>
> >>
> >> The difficulty with our strategy is selling it to potential users who are desperate to be able to
> >> tick a box marked 'Cxx-supported'.
> >> It gives them a warm feeling, but little in reality.
> >
> > Aren't you dismissing the voiced concerns too easily?
> > I want to be able to interact with libraries using standard library vocabulary types
> > and I don't want my compiletimes to explode when using them. Supporting
> > old c++ standards as many boost libs do can be a problem for both of
> > those goal:
> > - Apparently a lot of the compilation slowdown is due to the use of
> > boost.MPL, which could be replaced in c++11 by mp11 or language constructs.
>
> Proof please about compilation slowdown regarding MPL versus mp11.

Thats what I've heard repeatedly here on the ML and on slack. I see that
Peter has supplied a link further up in this thread: http://metaben.ch/

Whether MPL is solely to "blame" for compilation slowdowns people complain
about when using boost I don't know, but it stands to reason that the more
native language features can be used instead of library based workarounds and
the less "redundant" code the compiler has to churn through, the more efficient
the code becomes to compile. I've also read that microsofts
STL tries to port as much of their code from tag dispatch to if constexpr,
because it supposedly inicreases throughput, but I'm not aware of any
benchmarks I could compare it with.

>
> > - Obviously a c++03 lib can't use std::chrono::duration or std::string_view
> > in its interface. The former can sometimes be added as additional overload
> > if available, however, adding the latter almost certainly leads to ambiguous
> > overload resolution situations. So instead I have to convert the c++11/17/20
> > types into the appropriate boost types.
>
> I think this is valid. But you are certainly allowed to create a PR for
> a Boost library which changes its use of a Boost type to its C++
> standard library equivalent, with the proviso that the Boost library's
> base C++ level be C++11 and not C++03. The latter should not be an issue
> since Boost has already stated that Boost officially supports C++11 on
> up.

Aside from the fact that things like std::stng_view, std::byte or std::memory_resource
aren't c++11, but c++17:
Could you point me to this statement? All I'm aware of is that there is
consensus that boost libs are allowed to drop c++03 support if they want -
provided they follow certain procedure.
So far I'm aware of 3 libs that are planning to make use of this:
Math, Multiprecision and Geometry. I guess there are more, but I didn't get
the impression that there is hughe push towards this.

Again: I'm not trying to tell anyone what is best for boost or the boost
users because I'm lacking expertise, also can't really quantify any of it and
am probably not the one who has pay the costs.
But there are imho very reasonable reasons why people ask for a version
of boost that makes use of c++XX beyond "because it is cool".

Best

Mike

[Jeff Garland via Boost]

On Sat, Nov 28, 2020 at 11:08 AM Peter Dimov via Boost <
bo...@lists.boost.org> wrote:

> Rainer Deyke wrote:
>
> > From a user perspective, forking is an improvement over the status quo:
> it
> > means that Boost can guarantee that the 1.x line can stop dropping
> support
> > for old C++ standards, making it relatively safe to upgrade within the
> 1.x
> > line.
>
> This is only an improvement in the imaginary world where we have enough
> resources to maintain two forks. In reality, we have trouble maintaining
> one.
>

Why not just alternate releases -- so we'd have a 20 release and then a 17
release, etc? Over time we might change the pattern to emphasize the newer
distro as libraries drop support for 17. When c++23 rolls around we can
move to there. Note that boost.stacktrace has been voted into c++23 so it
might be removed in the future. We'd probably need some branches and
testing setup to manage this for libraries that might be in both for some
period of time.

If we did pull this off, one interesting problem that would be induced is
what various linux distros ship with...

[Jeff Garland via Boost]

On Sun, Nov 29, 2020 at 8:48 AM Mike via Boost <bo...@lists.boost.org>
wrote:

>
> But there are imho very reasonable reasons why people ask for a version
> of boost that makes use of c++XX beyond "because it is cool".
>

I can give you a very concrete one -- from_iso_string in date_time. It's
signature takes a const std::string&. If I have an std::string_view, then
I have to unnecessarily construct a string to call this function -- which
harms performance and is ugly. The bit of good news here is that it's easy
to change the signature for c++17 and up to just take string_view (that
covers string too) -- well after some code rewrite and by adding macro
hackery. But then the issue might be, should I support boost string_view
in older versions and add more macros so I'm not including extra stuff.
The combinatorics of supporting all the options can grow quickly.

[Peter Dimov via Boost]

Mike wrote:
> > Gesendet: Samstag, 28. November 2020 um 18:32 Uhr
> > Von: "Edward Diener via Boost" <bo...@lists.boost.org>

...

> > The latter should not be an issue since Boost has already stated that
> > Boost officially supports C++11 on up.
>
> Aside from the fact that things like std::stng_view, std::byte or
> std::memory_resource aren't c++11, but c++17:
> Could you point me to this statement?

There is no such statement.

[Peter Dimov via Boost]

Jeff Garland wrote:
> Why not just alternate releases -- so we'd have a 20 release and then a 17
> release, etc?

I have no idea how that's supposed to work.

> If we did pull this off, one interesting problem that would be induced is
> what various linux distros ship with...

Linux distros ship Boost built with the default gcc, with the default C++
standard. g++ defaults to C++03 before g++-6, to C++14 before g++-11. A
C++17 Boost will be unshippable for a while. C++14 is kind of acceptable
today.

The other major consumer of pre-C++11 Boost are non-mainstream platforms
such as z/OS, where people are still stuck with C++03.

See e.g.

https://github.com/boostorg/build/issues/534
https://github.com/boostorg/build/issues/535
https://github.com/boostorg/build/issues/519
https://github.com/boostorg/build/issues/511
https://github.com/boostorg/build/issues/473
https://github.com/boostorg/build/issues/471

[Peter Dimov via Boost]

Jeff Garland wrote:

> I can give you a very concrete one -- from_iso_string in date_time. It's
> signature takes a const std::string&. If I have an std::string_view, then
> I have to unnecessarily construct a string to call this function -- which
> harms performance and is ugly.

The answer here is to take a string_view that is constructible from all
StringLike types, including std::string_view and boost::string_view.

boost::string_view could have been this type, but Marshall refuses to add
conversions to it, so everybody needs to roll his own. Or perhaps we need to
add one to Core so Marshall's one can be kept pristine and in its original
shrink wrap.

[Jeff Garland via Boost]

On Sun, Nov 29, 2020 at 9:15 AM Peter Dimov via Boost <bo...@lists.boost.org>
wrote:

> Jeff Garland wrote:
> > Why not just alternate releases -- so we'd have a 20 release and then a
> 17
> > release, etc?
>
> I have no idea how that's supposed to work.
>
>

The point is we wouldn't try to double the number of releases stressing the
available resources. For libraries in both releases we would have to have
something like release20 and develop20 branches to maintain differences.
Libraries only in one of the packages wouldn't have that issue. I'm not
claiming this is a fully formed process, but I think something like this
could be done.

> > If we did pull this off, one interesting problem that would be induced
> is
> > what various linux distros ship with...
>
> Linux distros ship Boost built with the default gcc, with the default C++
> standard. g++ defaults to C++03 before g++-6, to C++14 before g++-11. A
> C++17 Boost will be unshippable for a while. C++14 is kind of acceptable
> today.
>
>

Believe g++10 is now c++14 by default and is on Fedora32 -- redhat 8 also
has a version available to customers.

The other major consumer of pre-C++11 Boost are non-mainstream platforms
> such as z/OS, where people are still stuck with C++03.
>
> See e.g.
>
> https://github.com/boostorg/build/issues/534
> https://github.com/boostorg/build/issues/535
> https://github.com/boostorg/build/issues/519
> https://github.com/boostorg/build/issues/511
> https://github.com/boostorg/build/issues/473
> https://github.com/boostorg/build/issues/471
>

Thanks. I'm less concerned with supporting them frankly. They have a
boost that they can use now -- the rest of us can move on.

[Jeff Garland via Boost]

On Sun, Nov 29, 2020 at 9:20 AM Peter Dimov via Boost <bo...@lists.boost.org>
wrote:

> Jeff Garland wrote:
>
> > I can give you a very concrete one -- from_iso_string in date_time.
> It's
> > signature takes a const std::string&. If I have an std::string_view,
> then
> > I have to unnecessarily construct a string to call this function --
> which
> > harms performance and is ugly.
>
> The answer here is to take a string_view that is constructible from all
> StringLike types, including std::string_view and boost::string_view.
>

Sure, but that type is going to need to account for c++17 versus earlier
versions. And to be clear -- I was just illustrating an example that I
don't consider to be a 'nice to have' for a newer version of c++. There
are certainly others....

> boost::string_view could have been this type, but Marshall refuses to add
> conversions to it, so everybody needs to roll his own. Or perhaps we need
> to
> add one to Core so Marshall's one can be kept pristine and in its original
> shrink wrap.

idk that seems like an even bigger mess...

[Peter Dimov via Boost]

Jeff Garland wrote:

> Believe g++10 is now c++14 by default

That's what I said. g++-6 and up (and clang++-6.0 and up) are C++14 by
default.

> > The other major consumer of pre-C++11 Boost are non-mainstream platforms
> > such as z/OS, where people are still stuck with C++03.
> >
> > See e.g.
> >
> > https://github.com/boostorg/build/issues/534
> > https://github.com/boostorg/build/issues/535
> > https://github.com/boostorg/build/issues/519
> > https://github.com/boostorg/build/issues/511
> > https://github.com/boostorg/build/issues/473
> > https://github.com/boostorg/build/issues/471
>
> Thanks. I'm less concerned with supporting them frankly. They have a
> boost that they can use now -- the rest of us can move on.

As far as I can see, the major problem with b2 dropping C++03 was not the
fact that it happened, but that it happened without Boost announcing that
C++03 is no longer supported for building Boost.

Technically, you could still build Boost if you compiled just b2
with -std=c++11, but in the real world nobody cares for that distinction.
Boost doesn't build, and that's that.

[Peter Dimov via Boost]

Jeff Garland wrote:
> > The answer here is to take a string_view that is constructible from all
> > StringLike types, including std::string_view and boost::string_view.
>
> Sure, but that type is going to need to account for c++17 versus earlier
> versions.

For this specific use, it doesn't need to. It can just match against a
StringLike concept, as I said.

[Peter Dimov via Boost]

Jeff Garland wrote:

> And to be clear -- I was just illustrating an example that I don't
> consider to be a 'nice to have' for a newer version of c++. There are
> certainly others....

There are certainly others, and in every case I think that the right thing
to do is along the same lines. This is sometimes relatively trivial, as with
string_view, sometimes hard, as with taking error_code& or returning an
optional.

Note how we don't have this issue at all with boost::function - that's
because it already takes everything, including std::function, so interop
mostly just works. A library that takes a boost::function in its interface
is usable as-is from C++17 client code.

[Raffi Enficiaud via Boost]

On 27.11.20 09:58, Antony Polukhin via Boost wrote:
> Hi,
>
> == The problem.
> TL;DR: we are having huge troubles with usability and popularity!

Indeed. Several points points below summarized as:

* feedback from boost.test
* elements of friction within boost
* the good things about boost
* approach taken for boost.test


----------------------------------------------------
Feedback from Boost.Test:

- its level of popularity increased over the last 5 years, and I believe
it is still one of the best C++ unit tests tool out there. Using it
myself in my other projects, which is already a good sign.
- its main popularity is outside of Boost, not even from within Boost as
it's competing with test lightweight
- for the years of maintenance I am doing, I've never heard someone
asking for a super ancient compiler support
- from within boost, it has this overhead of being compatible with the
union of libs that are using boost, taking in turn their union of
requirements.

The last point is a disservice for the library and for boost itself. In
addition to what you said: not enforcing ourselves to revisit some
libraries makes virtually impossible to upgrade something or to drop an
API. Boost itself is one of the most demanding client for Boost.Test in
terms of compatibility. I am seeing code using boost.test that is 15y old.

----------------------------------------------------
Elements of friction within Boost

Some elements on which there is no consensus and rather **friction**:
build system, documentation (tooling), things like layout, etc. and base
version of C++. Those are technical frictions.

There are deeper frictions that are left in a floating state such as the
scope and purpose of Boost and its governance.
If there will ever be a Boost 2.0, it should be on a reflection of a
"new way of doing things", not technical choices such as C++20 or cmake.

----------------------------------------------------
The good things about Boost

I would rather in turn ask in a very bold way:
what does work well with boost?

- review: whether we agree or not, we have a level of expertise that is
the cream of the cream in C++, usability, scope, API, documentation.
- releases: process in place, done by a handful of people, understood by
devs.
- distribution: can be done better but just works and people used to it.
Alternative solution exist for free.
- web hosting and domain name: works, some parts completely unmaintained
or barely used (wiki, google calendar).
- communication/mailing list: not very helpful for developments, lot of
messages ignored, lots of ML in dead state. I believe frustrating for many.
- other infra:
* tests (the "official" test matrix): community around this, can be
bigger and more appealing/helpful.
* appveyor/travis: I really cannot say, I always "time out", just
noise for me and for the PRs. I had to put my own CI in place.
* git/modular boost: works, process well understood. Purpose is more
for distribution and inter-library dependencies. Friction almost never
happen.
* github: boost not doing much here apart from maintaining a sane
permission system, keeping the brand safe. Ticketing on GH (getting rid
of trac) benefited boost in general.

Some of the above, even if not perfect, are quite difficult to put in
place if each of the library maintainer would do that by themselves.

----------------------------------------------------
Approach taken for boost.test


** customer first **

- customer does not care about all the discussions that are happening.
Neither should I.
- some customers are following the boost schedule for updates and want
the big fat .zip at the end by each release
- some customers are willing to include boost.test into their code but
the impact is too high for many reasons. Once Boost in the set of
dependencies, there is also a fear that the code becomes more and more
dependent on Boost. I, as a manager, do not want my code to heavily
depend on Boost.


** from dev perspective **

- no consensus possible within boost in a quorum of this size. That is
ok, it is a given we have to play with
- nothing really blocking me from making evolution to boost.test
- I assume there is a set of minimal services (and I say services, not
libraries - Web hosting, doc building, etc) provided by boost such that
libraries can grow within boost.


** development target **

- ship boost.test completely independently (a library with 0 dependency
on any other library), with a minimal C++ version I can choose from.
- at the same time ship boost.test compatible version, and benefit from
web hosting, branding, doc build and availability, test matrix, keeping
existing "market".

It turns out that the 2 above are not incompatible, but it comes with
the cost of pulling parts of boost into boost.test. I am fine with
having "demangle" duplicated in boost.test. It is much trickier to
emulate some parts of boost.preprocessor.
A good property of this approach is that, if at some point the switch is
made on Boost to move to C++17 or cmake, the cost will be lower.

I am not sure that this branch will ever see the light TBH. I am working
on it as much as I can despite COVID and the Karabakh war.

----------------------------------------------------

>
> == 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.


Replacing all the MPL stuff and the various macros such as
BOOST_OVERRIDE is quite easy. Replacing Boost.Config is a bit more
trickier, but OTOH we can assume that the version of the compiler is
fully compatible with some requirements.

I find replacing Boost.Preprocessor however extremely hard, and this is
blocking me for some time. I absolutely do not want to replace
quickbook, but the consumer that not need it anyway.

It is definitely not a 2 day work.

> == 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
>

0/ For the discussions I am all for it, but I would absolutely not try
to gather consensus. Because there won't be. I would rather first
exchange ideas and "how tos".
1/ The idea is there, the problem is real. We should find a sound solution.

Raffi

[Glen Fernandes via Boost]

On 2020-11-29, Raffi Enficiaud wrote:
> 0/ For the discussions I am all for it, but I would absolutely not try
> to gather consensus. Because there won't be.

You definitely don't need consensus. You are free to drop C++03 and
C++11 and C++14 support from Boost.Test whenever you want.

We've been steadily migrating Boost libraries away from using
Boost.Test to using Boost.LightweightTest for various reasons. (And
have plans to migrate a few more to Boost.LightweightTest by Boost
1.76)

So you can decide to require C++17 or higher for Boost.Test and not
have to worry about other Boost libraries. We'll make sure their tests
are still working by moving them to LWT.

Just give us some warning, before you drop any support. :)

Glen

[Edward Diener via Boost]

Boost.Preprocessor works in whatever C++ level you want. It has no
reliance on any C++ standard or Boost equivalent library, or any other
Boost library. That does not mean you could not eliminate use of its
macros in code if you have a better alternative.

[Edward Diener via Boost]

What statement ? Boost doesn't officially support C++03, even if
individual libraries still support C++03, so a PR that changes a library
that currently supports C++03 as its base level to instead support C++11
as its base level by using C++11 standard libraries in its code instead
of the Boost equivalent libraries, would not be a radical change. Of
course it is still up to the maintainer(s) of the library to accept the
PR. As for changing a library's base level to C++14, C++17, or C++20 via
a PR that probably needs to be justified since it would remove that
library's usefulness for those compiling at the C++11 level.

> All I'm aware of is that there is
> consensus that boost libs are allowed to drop c++03 support if they want -
> provided they follow certain procedure.
> So far I'm aware of 3 libs that are planning to make use of this:
> Math, Multiprecision and Geometry. I guess there are more, but I didn't get
> the impression that there is hughe push towards this.
>
> Again: I'm not trying to tell anyone what is best for boost or the boost
> users because I'm lacking expertise, also can't really quantify any of it and
> am probably not the one who has pay the costs.
> But there are imho very reasonable reasons why people ask for a version
> of boost that makes use of c++XX beyond "because it is cool".

[Glen Fernandes via Boost]

On Sun, Nov 29, 2020 at 4:44 PM Edward Diener wrote:
>
> On 11/29/2020 10:47 AM, Mike via Boost wrote:
> >> Gesendet: Samstag, 28. November 2020 um 18:32 Uhr
> >> Von: "Edward Diener via Boost" <bo...@lists.boost.org>
> >>

> >> I think this is valid. But you are certainly allowed to create a PR for
> >> a Boost library which changes its use of a Boost type to its C++
> >> standard library equivalent, with the proviso that the Boost library's
> >> base C++ level be C++11 and not C++03. The latter should not be an issue
> >> since Boost has already stated that Boost officially supports C++11 on
> >> up.
> >
> > Aside from the fact that things like std::stng_view, std::byte or std::memory_resource
> > aren't c++11, but c++17:
> > Could you point me to this statement?
>
> What statement ? Boost doesn't officially support C++03, even if
> individual libraries still support C++03, so a PR that changes a library
> that currently supports C++03 as its base level to instead support C++11
> as its base level by using C++11 standard libraries in its code instead
> of the Boost equivalent libraries, would not be a radical change. Of
> course it is still up to the maintainer(s) of the library to accept the
> PR. As for changing a library's base level to C++14, C++17, or C++20 via
> a PR that probably needs to be justified since it would remove that
> library's usefulness for those compiling at the C++11 level.

Note that for new libraries being accepted into Boost, the only
requirement is that (at the time of review) they compile with at least
two C++ compilers and that they at least compile under the current C++
standard (which today is C++17).

i.e. We accept new libraries that don't compile under C++11, and we
even have some libraries today that require C++14 or higher.

Glen

[Emil Dotchevski via Boost]

On Sun, Nov 29, 2020 at 1:44 PM Edward Diener via Boost <
bo...@lists.boost.org> wrote:
> What statement ? Boost doesn't officially support C++03, even if
> individual libraries still support C++03, so a PR that changes a library
> that currently supports C++03 as its base level to instead support C++11
> as its base level by using C++11 standard libraries in its code instead
> of the Boost equivalent libraries, would not be a radical change.

That depends on whether or not the user code depends on the boost types
which, as you know, work fine when compiled with a new C++ compiler.
Supporting old compilers is only part of the motivation, the other part is
supporting old user code; and it's safe to assume that for the user
switching from boost types to std types is very difficult.

[Emil Dotchevski via Boost]

On Sun, Nov 29, 2020 at 2:04 PM Glen Fernandes via Boost <
bo...@lists.boost.org> wrote:
> Note that for new libraries being accepted into Boost, the only
> requirement is that (at the time of review) they compile with at least
> two C++ compilers and that they at least compile under the current C++
> standard (which today is C++17).
>
> i.e. We accept new libraries that don't compile under C++11, and we
> even have some libraries today that require C++14 or higher.

New libraries always try to support the oldest C++ standard possible. When
your library is new, you instinctively grasp that it will be more popular
the wider the range of the supported platforms. The flip side is that a few
years later, that oldest C++ standard supported by the library is older
still, yet the user base is bigger because of it. Don't turn it into a trap
now, keep it working.

[Mike via Boost]

> Gesendet: Sonntag, 29. November 2020 um 22:43 Uhr

> Von: "Edward Diener via Boost" <bo...@lists.boost.org>
>
> On 11/29/2020 10:47 AM, Mike via Boost wrote:
> >> Gesendet: Samstag, 28. November 2020 um 18:32 Uhr
> >> Von: "Edward Diener via Boost" <bo...@lists.boost.org>
> >>
> >> On 11/28/2020 11:47 AM, Mike via Boost wrote:

> > [...]

> >>
> >>> - Obviously a c++03 lib can't use std::chrono::duration or std::string_view
> >>> in its interface. The former can sometimes be added as additional overload
> >>> if available, however, adding the latter almost certainly leads to ambiguous
> >>> overload resolution situations. So instead I have to convert the c++11/17/20
> >>> types into the appropriate boost types.
> >>
> >> I think this is valid. But you are certainly allowed to create a PR for
> >> a Boost library which changes its use of a Boost type to its C++
> >> standard library equivalent, with the proviso that the Boost library's
> >> base C++ level be C++11 and not C++03. The latter should not be an issue
> >> since Boost has already stated that Boost officially supports C++11 on
> >> up.
> >

> > [...]

> > Could you point me to this statement?
>
> What statement ?

Whatever you meant when you wrote:

> since Boost has already stated that Boost officially supports C++11 on up.

[Andrey Semashev via Boost]

On 11/29/20 7:19 PM, Peter Dimov via Boost wrote:
>
> Or perhaps we
> need to add one to Core so Marshall's one can be kept pristine and in
> its original shrink wrap.

Please, no yet another string_view. I already have 4 to support in
Boost.Log.

https://github.com/boostorg/log/blob/a36417bcf34e9818cbc7e013d18c1c83c9e4221c/include/boost/log/utility/formatting_ostream.hpp#L565-L594

[Edward Diener via Boost]

I recall something Peter Dimov wrote about Boost no longer guaranteeing
support of code compiled at the C++03 level, but do not remember where
it is on the website.

[Glen Fernandes via Boost]

It's not an official statement and it's not on the Boost website.
It was a proposal, and hosted on Peter's github:
https://pdimov.github.io/articles/phasing_out_cxx03.html

Glen

[Gavin Lambert via Boost]

On 30/11/2020 6:21 am, Peter Dimov wrote:
> Jeff Garland wrote:
>> > The answer here is to take a string_view that is constructible from
>> all > StringLike types, including std::string_view and
>> boost::string_view.
>>
>> Sure, but that type is going to need to account for c++17 versus
>> earlier versions.
>
> For this specific use, it doesn't need to. It can just match against a
> StringLike concept, as I said.

Except that you can't use concepts in a compiled library, only in a
header-only one. (Or it still requires you to write that concrete type
conversion.)

[Peter Dimov via Boost]

Gavin Lambert wrote:
> > For this specific use, it doesn't need to. It can just match against a
> > StringLike concept, as I said.
>
> Except that you can't use concepts in a compiled library, only in a
> header-only one. (Or it still requires you to write that concrete type
> conversion.)

Of course you can.

class string_view
{
public:

template<class StringLike,
class E = enable_if_t<is_string_like<StringLike>>
>
string_view( StringLike const& sl ): p_( sl.data() ), n_( sl.size() ) {}
};

void my_compiled_library( string_view sv );

This is not something theoretical. E.g. Victor Zverovich has independently
come to the same conclusion:
https://twitter.com/vzverovich/status/1333111364357746690

[Raffi Enficiaud via Boost]

On 29.11.20 22:32, Edward Diener via Boost wrote:
> On 11/29/2020 2:14 PM, Raffi Enficiaud via Boost wrote:
>> On 27.11.20 09:58, Antony Polukhin via Boost wrote:

[...]

>
> Boost.Preprocessor works in whatever C++ level you want. It has no
> reliance on any C++ standard or Boost equivalent library, or any other
> Boost library. That does not mean  you could not eliminate use of its
> macros in code if you have a better alternative.

My point is that the biggest blocker for larger adoption of Boost.Test
is the size of monolithic Boost, not C++17 (which it supports).
Boost.Test depends on various libs among which preprocessor. It is good
design in a single library to reuse functions. But

* Boost.Test is not shipping some additional feature on top of
preprocessor, it is a client of it. Preprocessor is an implementation
detail of Boost.Test.

* Boost is not a single library (especially since "modular Boost"), it
is an umbrella of libraries. Each library is addressing a specific need
in the C++ world and has a specific target audience. Code reuse should
be thought as a way to bring features faster to market, this is a price
usually customer is ok to pay for. But then library coupling has various
downsides, such as slowing wider adoption and harming retention.

Preprocessor is a valuable library (especially now that I am trying to
re-implement a tiny subset of it) but that dependency has to be put in
the light of what it costs to customers, and the customers of boost.test
and preprocessor have little overlap.

[Gavin Lambert via Boost]

On 30/11/2020 1:36 pm, Peter Dimov wrote:
> Gavin Lambert wrote:
>> > For this specific use, it doesn't need to. It can just match against
>> a > StringLike concept, as I said.
>>
>> Except that you can't use concepts in a compiled library, only in a
>> header-only one.  (Or it still requires you to write that concrete
>> type conversion.)
>
> Of course you can.
>
> class string_view
> {
> public:
>
>    template<class StringLike,
>        class E = enable_if_t<is_string_like<StringLike>>
>    >
>    string_view( StringLike const& sl ): p_( sl.data() ), n_( sl.size()
> ) {}
> };
>
> void my_compiled_library( string_view sv );

Yes, that's exactly what I meant by "concrete type conversion".

Since the standard library string_view doesn't (currently?) do this, it
means that everybody will be writing their own string_views. (Or worse:
writing their own is_string_like.) This is not an improvement.

> Victor Zverovich has independently come to the same conclusion:
> https://twitter.com/vzverovich/status/1333111364357746690

I'm not sure if that was the wrong link or if you're referring to
something non-obvious to me there, but that doesn't appear related.

[Peter Dimov via Boost]

Gavin Lambert wrote:
> > Victor Zverovich has independently come to the same conclusion:
> > https://twitter.com/vzverovich/status/1333111364357746690
>
> I'm not sure if that was the wrong link or if you're referring to
> something non-obvious to me there, but that doesn't appear related.

You don't see the documentation of fmt::basic_string_view in the screenshot?

[Antony Polukhin via Boost]

On Fri, Nov 27, 2020, 15:54 Edward Diener via Boost <bo...@lists.boost.org>
wrote:

> 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 !
>

For example, that library may use boost/type_traits.hpp and boost/mpl/*.
Those headers include a bunch of text and variadic templates emulation, and
compile times getting drastically worse.

Another example: library that uses boost/optional.hpp includes ~500kB of
code. To make things funnier, ln some standard libraries inclusion of
boost/optional.hpp
leads to inclusion of <optiknal>, so removing the dependency drops 500kb of
text from each translation unit.

Final example: library work in c++98 and it almost does not depend on other
Boost libraries. Great! It's a perfect candidate for Boost17.

Nothing wrong in c++98 support, the problem is in the dependencies and huge
translation units to compile.



> * hard to upgrade, because symbols are not versioned
>

> Versioned symbols ?
>

If you are using a system package that relies on Boost, then you can not
upgrade Boost. For example mongo library uses Boost 1.45 and you wish to
use Boost 1.74 => you've got problems. Linker may merge not ABI
compatible Boost
symbols, leading to breakages. More specifically, the layout of
Boost.Variant changed multiple times since 1.45, but the signature of the
boost::apply_visitor function did not change. As a result you get
ODR-violation.

[Antony Polukhin via Boost]

On Sat, Nov 28, 2020, 02:26 Emil Dotchevski via Boost <bo...@lists.boost.org>
wrote:

> Deleting support for C++11 and older versions means breaking user code.
> Therefore, forking means fracturing of the community. I don't see how this
> is helpful to the users.
>

Think of it not as of fracturing a community. Treat it as getting a *new*
users, that previously were scared of by the Boost monolith, it's
dependencies and legacy code that adds only size to the translation units
and slows down the compile times.

[Antony Polukhin via Boost]

On Sun, Nov 29, 2020, 01:02 Peter Dimov via Boost <bo...@lists.boost.org>
wrote:

> Rainer Deyke wrote:
> > On 28.11.20 19:07, Peter Dimov via Boost wrote:
> > > Rainer Deyke wrote:
> > >
> > >> From a user perspective, forking is an improvement over the status
> quo:
> > >> it means that Boost can guarantee that the 1.x line can stop dropping
> > >> support for old C++ standards, making it relatively safe to upgrade
> > >> within the 1.x line.
> > >
> > > This is only an improvement in the imaginary world where we have
> enough
> > > resources to maintain two forks. In reality, we have trouble
> maintaining
> > > one.
> >
> > Yes, that's why I wrote "from a user perspective". I'm not saying that
> > this a practicable solution. I'm just saying that it would be nice if
> it
> > were.
>
> Nice for the end user, perhaps, but intermediate libraries are now forced
> to
> choose between using boost or boost2, or maintaining two versions.
>
> My alternative idea of "nice to have" is a single Boost library that can
> use
> either boost or std components in its interface. That's not always
> possible
> to obtain though.
>

I've tried that and it kind of works. There are still problems:
* users have to use macro to customize the library
* bcp still pulls in the Boost alternatives
* code redability suffers from typedefs
* you still kind of have two different libraries

Here's how it works on Boost.DLL:
* users define BOOST_DLL_USE_STD_FS
* bcp still puls in Boost.Filesystem, Boost.System...
* boost::dll::fs::path = std::conditional_t<a-lot-of-mess>
* code in incompatible with the library that was build without
BOOST_DLL_USE_STD_FS

Splitting Boost.DLL into std17 and current-Boost libraries fixes 3 issues
out of 4.

[Antony Polukhin via Boost]

On Sun, Nov 29, 2020, 19:14 Peter Dimov via Boost <bo...@lists.boost.org>
wrote:

> Jeff Garland wrote:
> > Why not just alternate releases -- so we'd have a 20 release and then a
> 17
> > release, etc?
>
> I have no idea how that's supposed to work.
>

> > If we did pull this off, one interesting problem that would be induced
> is
> > what various linux distros ship with...
>
> Linux distros ship Boost built with the default gcc, with the default C++
> standard. g++ defaults to C++03 before g++-6, to C++14 before g++-11. A
> C++17 Boost will be unshippable for a while. C++14 is kind of acceptable
> today.
>

GCC moves to c++17 by default
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=0801f419440c14f6772b28f763ad7d40f7f7a580

AFAIK Clang plans the same move

[Antony Polukhin via Boost]

On Mon, Nov 30, 2020, 04:19 Raffi Enficiaud via Boost <bo...@lists.boost.org>
wrote:

> On 29.11.20 22:32, Edward Diener via Boost wrote:
> > On 11/29/2020 2:14 PM, Raffi Enficiaud via Boost wrote:
> >> On 27.11.20 09:58, Antony Polukhin via Boost wrote:
> [...]
> >
> > Boost.Preprocessor works in whatever C++ level you want. It has no
> > reliance on any C++ standard or Boost equivalent library, or any other
> > Boost library. That does not mean you could not eliminate use of its
> > macros in code if you have a better alternative.
>
> My point is that the biggest blocker for larger adoption of Boost.Test
> is the size of monolithic Boost, not C++17 (which it supports).
> Boost.Test depends on various libs among which preprocessor.
>

Yes, thank you!

Exactly that's the problem I'm trying to solve with the Boost17. The
problem becomes much bigger, when the Boost library becomes part of the
iterface. For example, Boost.DLL needs shared_ptr and filesystem in it's
interface. Users suffer from boost::filesystem and boost::shared_ptr if
their projects use C++17 std:: alternatives.

[Glen Fernandes via Boost]

On Tue, Dec 1, 2020 at 3:27 PM Antony Polukhin wrote:
>
> Exactly that's the problem I'm trying to solve with the Boost17. The
> problem becomes much bigger, when the Boost library becomes part of the
> iterface. For example, Boost.DLL needs shared_ptr and filesystem in it's
> interface. Users suffer from boost::filesystem and boost::shared_ptr if
> their projects use C++17 std:: alternatives.

Why haven't you solved it for Boost.DLL users by switching to
std::shared_ptr and std::filesystem yet? You don't need anyone's
permission.

Glen

[Robert Ramey via Boost]

On 12/1/20 12:23 PM, Antony Polukhin via Boost wrote:
> On Mon, Nov 30, 2020, 04:19 Raffi Enficiaud via Boost <bo...@lists.boost.org>

> when the Boost library becomes part of the
> iterface. For example, Boost.DLL needs shared_ptr and filesystem in it's
> interface. Users suffer from boost::filesystem and boost::shared_ptr if
> their projects use C++17 std:: alternatives.

I'm kind of intrigued with the idea of including things like shared_ptr
(and others) in a (user) library API. I never do this. In general, I
never use mutable references to mutable objects in any API. That is I
always pass f(const T &). So I never have to pass ownership to a user
function. So I can pass a reference to some constant underlying type.
For example rather than

unsigned int string_hash( const std::string s &) {...}

I would use

unsigned int string_hash( const std::string s &) const {
return string_hash( s.c_str() );
}

Of course making this change after the fact would be quite a bit of
work. But since I do it from the beginning, it's no extra work at all.
And it eliminates many, many problems including the one described
above. It's gotten to the point that for me, non constant parameters
parameters are code smell. I almost never use them. And when I do,
usage is almost always confined to member functions.

I'm aware that this is actually off topic so sorry for hijaking the
thread. But I believe that a lot of this (and other discussions),
rather than trying to address problems with reconciling boost and std
libraries would (mostly disappear) if users would step back and think
more about what functional program can mean in the real world.

Robert Ramey

[Antony Polukhin via Boost]

On Tue, Dec 1, 2020, 23:36 Glen Fernandes <glen.fe...@gmail.com> wrote:

> On Tue, Dec 1, 2020 at 3:27 PM Antony Polukhin wrote:
> >
> > Exactly that's the problem I'm trying to solve with the Boost17. The
> > problem becomes much bigger, when the Boost library becomes part of the
> > iterface. For example, Boost.DLL needs shared_ptr and filesystem in it's
> > interface. Users suffer from boost::filesystem and boost::shared_ptr if
> > their projects use C++17 std:: alternatives.
>
> Why haven't you solved it for Boost.DLL users by switching to
> std::shared_ptr and std::filesystem yet? You don't need anyone's
> permission.
>

Because I'm not planning to drop support for the pre-C++17 users. I wish to
provide another library for users that avoid existing Boost.DLL because of
the dependencies.

Wich brings me to a less radical idea: we may simplify acceptance of
dependenceless library clones. Next step would be to provide predefined
bcp'ed subsets of libraries (boost 17, boost 23?)

[Edward Diener via Boost]

So if you use in a C++17 project a Boost library which supports
C++98/C++03 you have huge translation units but if you use a Boost
library which supports C++11 on up or if you use C++ standard libraries
which often depend on each other you never have huge translation units.
Is that what you are saying ?

>
>
>
>> * hard to upgrade, because symbols are not versioned
>>
>
>> Versioned symbols ?
>>
>
> If you are using a system package that relies on Boost, then you can not
> upgrade Boost. For example mongo library uses Boost 1.45 and you wish to
> use Boost 1.74 => you've got problems.

Of course if you use the mongo library, whatever it is, with the C++
standard library it automatically works with whatever the latest C++
standard library is installed but if you use mongo with Boost it only
works with Boost 1.45 and not the latest Boost. And this is Boost's
fault no doubt !

> Linker may merge not ABI
> compatible Boost
> symbols, leading to breakages. More specifically, the layout of
> Boost.Variant changed multiple times since 1.45, but the signature of the
> boost::apply_visitor function did not change. As a result you get
> ODR-violation.

Are you saying that Boost is not ABI compatible between releases but any
compiler's C++ standard library is always ABI compatible between releases ?

[Glen Fernandes via Boost]

On Tue, Dec 1, 2020 at 4:16 PM Antony Polukhin <anto...@gmail.com> wrote:
>
> On Tue, Dec 1, 2020, 23:36 Glen Fernandes <glen.fe...@gmail.com> wrote:
>>
>> On Tue, Dec 1, 2020 at 3:27 PM Antony Polukhin wrote:
>> >
>> > Exactly that's the problem I'm trying to solve with the Boost17. The
>> > problem becomes much bigger, when the Boost library becomes part of the
>> > iterface. For example, Boost.DLL needs shared_ptr and filesystem in it's
>> > interface. Users suffer from boost::filesystem and boost::shared_ptr if
>> > their projects use C++17 std:: alternatives.
>>
>> Why haven't you solved it for Boost.DLL users by switching to
>> std::shared_ptr and std::filesystem yet? You don't need anyone's
>> permission.
>
>
> Because I'm not planning to drop support for the pre-C++17 users. I wish to provide another library for users that avoid existing Boost.DLL because of the dependencies.
>
> Wich brings me to a less radical idea: we may simplify acceptance of dependenceless library clones. Next step would be to provide predefined bcp'ed subsets of libraries (boost 17, boost 23?)

One option is for that other library (DLL for C++17+) to still live
under the boostorg/dll repository - i.e. it doesn't need to have its
own repository.

If so, there's no concern about acceptance either since you already
have it (you can maintain both under boostorg/dll and then eventually
choose to drop the C++03 variation in a later Boost release etc...).

Glen

[Edward Diener via Boost]

On 12/1/2020 4:03 PM, Robert Ramey via Boost wrote:
> On 12/1/20 12:23 PM, Antony Polukhin via Boost wrote:
>> On Mon, Nov 30, 2020, 04:19 Raffi Enficiaud via Boost
>> <bo...@lists.boost.org>
>
>> when the Boost library becomes part of the
>> iterface. For example, Boost.DLL needs shared_ptr and filesystem in it's
>> interface. Users suffer from boost::filesystem and boost::shared_ptr if
>> their projects use C++17 std:: alternatives.
>
> I'm kind of intrigued with the idea of including things like shared_ptr
> (and others) in a (user) library API.  I never do this.  In general, I
> never use mutable references to mutable objects in any API.  That is I
> always pass f(const T &).  So I never have to pass ownership to a user
> function.  So I can pass a reference to some constant underlying type.

You may still have to choose the type between Boost and a C++ standard
alternative and no matter which type you choose the end-user may be
using the other type in his code and be irritated that you are not using
the type he is using.

> For example rather than
>
> unsigned int string_hash( const std::string s &) {...}
>
> I would use
>
> unsigned int string_hash( const std::string s &) const {
>     return string_hash( s.c_str() );
> }
>
> Of course making this change after the fact would be quite a bit of
> work.  But since I do it from the beginning, it's no extra work at all.
>  And it eliminates many, many problems including the one described
> above. It's gotten to the point that for me, non constant parameters
> parameters are code smell.  I almost never use them. And when I do,
> usage is almost always confined to member functions.
>
> I'm aware that this is actually off topic so sorry for hijaking the
> thread.  But I believe that a lot of this (and other discussions),
> rather than trying to address problems with reconciling boost and std
> libraries would (mostly disappear) if users would step back and think
> more about what functional program can mean in the real world.

[Kostas Savvidis via Boost]

> On Dec 1, 2020, at 22:05, Antony Polukhin via Boost <bo...@lists.boost.org> wrote:
>
>> My alternative idea of "nice to have" is a single Boost library that can
>> use either boost or std components in its interface. That's not always
>> possible to obtain though.
>
> I've tried that and it kind of works. There are still problems:
> * users have to use macro to customize the library
> * bcp still pulls in the Boost alternatives
> * code redability suffers from typedefs
> * you still kind of have two different libraries

Here is a case study. Some while ago I proposed to Steven Watanabe, the maintainer of boost.random
to produce a version of my MIXMAX random number generator for inclusion.
The software at that point was plain vanilla C++11.

After a go-ahead from Steven I added a series of boosticisms in order to make the stuff conform to how things were done in boost.random.
The only sticky point was std:array. I was informed by Steven that the library must work with C++03 and there I had to use boost::array or something else.
Not wanting to use typedefs and macros such as the below,

#ifndef BOOST_NO_CXX11_HDR_ARRAY
#include <array>
#define mixmaxarray std::array
#else
#include <boost/array.hpp>
#define mixmaxarray boost::array
#endif
...#undef mixmaxarray

The other alternative kindly proposed by Steven was:
namespace boost { namespace random { namespace arrayns = std; } }

And yet another suggestion was to turn off inclusion of MIXMAX under C++03, but that required messing with
[[config.requires cxx11_hdr_array]] in the jamfile for tests which I learned had been a source of problems back in 2016!
http://boost.2283326.n4.nabble.com/question-regarding-quot-requires-cxx11-hdr-array-quot-clause-in-Jamfile-td4690277.html <http://boost.2283326.n4.nabble.com/question-regarding-quot-requires-cxx11-hdr-array-quot-clause-in-Jamfile-td4690277.html>

So, what was the least disruptive solution? Yes, going with boost::array everywhere.

Best Regards,
Kostas

[Antony Polukhin via Boost]

On Wed, Dec 2, 2020, 00:22 Edward Diener via Boost <bo...@lists.boost.org>

wrote:

> On 12/1/2020 2:44 PM, Antony Polukhin via Boost wrote:
> > On Fri, Nov 27, 2020, 15:54 Edward Diener via Boost
> >>

> >> 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 !
> >>
> >
> > For example, that library may use boost/type_traits.hpp and boost/mpl/*.
> > Those headers include a bunch of text and variadic templates emulation,
> and
> > compile times getting drastically worse.
> >
> > Another example: library that uses boost/optional.hpp includes ~500kB of
> > code. To make things funnier, ln some standard libraries inclusion of
> > boost/optional.hpp
> > leads to inclusion of <optiknal>, so removing the dependency drops 500kb
> of
> > text from each translation unit.
> >
> > Final example: library work in c++98 and it almost does not depend on
> other
> > Boost libraries. Great! It's a perfect candidate for Boost17.
> >
> > Nothing wrong in c++98 support, the problem is in the dependencies and
> huge
> > translation units to compile.
>
> So if you use in a C++17 project a Boost library which supports
> C++98/C++03 you have huge translation units but if you use a Boost
> library which supports C++11 on up or if you use C++ standard libraries
> which often depend on each other you never have huge translation units.
> Is that what you are saying ?
>

More or less. Users will use the standard libraries anyway, adding Boost
libraries that duplicate the functionality increase the size of translation
unit. If you have no standard alternative - you use Boost, you have no
choice.

> Linker may merge not ABI
> > compatible Boost
> > symbols, leading to breakages. More specifically, the layout of
> > Boost.Variant changed multiple times since 1.45, but the signature of the
> > boost::apply_visitor function did not change. As a result you get
> > ODR-violation.
>
> Are you saying that Boost is not ABI compatible between releases but any
> compiler's C++ standard library is always ABI compatible between releases ?
>

Not any, but many.

[Antony Polukhin via Boost]

On Wed, Dec 2, 2020, 00:23 Glen Fernandes <glen.fe...@gmail.com> wrote:

> On Tue, Dec 1, 2020 at 4:16 PM Antony Polukhin.

> >
> > Wich brings me to a less radical idea: we may simplify acceptance of
> dependenceless library clones. Next step would be to provide predefined
> bcp'ed subsets of libraries (boost 17, boost 23?)
>
> One option is for that other library (DLL for C++17+) to still live
> under the boostorg/dll repository - i.e. it doesn't need to have its
> own repository.
>

You mean folder structure like
include/boost/dll/
include/boost/dll17/

Would the bcp treat dependencies of include/boost/dll17 separately from
include/boost/dll?

[Peter Dimov via Boost]

Antony Polukhin wrote:
> > My alternative idea of "nice to have" is a single Boost library that can
> > use either boost or std components in its interface. That's not always
> > possible to obtain though.
>
> I've tried that and it kind of works. There are still problems:
> * users have to use macro to customize the library
> * bcp still pulls in the Boost alternatives
> * code redability suffers from typedefs
> * you still kind of have two different libraries
>
> Here's how it works on Boost.DLL:
> * users define BOOST_DLL_USE_STD_FS
> * bcp still puls in Boost.Filesystem, Boost.System...
> * boost::dll::fs::path = std::conditional_t<a-lot-of-mess>
> * code in incompatible with the library that was build without
> BOOST_DLL_USE_STD_FS

That's not what I have in mind. Macros don't solve the problem. What I have
in mind is that there is a single library that, in its interface, can
seamlessly take either boost::fs::path or std::fs::path, without the user
having to define anything.

Of course, when building the library, you probably would need to have
Boost.Filesystem available.

[Edward Diener via Boost]

I wrote a library called cxx_dual ( https://github.com/eldiener/cxx_dual
) to solve a problem like yours, but it did not meet with general
approval. With cxx_dual your code above could have been:

#include <boost/cxx_dual/array.hpp>
#define mixmaxarray cxxd_array_ns::array

C'est tout !

But that is far too easy <g>.

>
> And yet another suggestion was to turn off inclusion of MIXMAX under C++03, but that required messing with
> [[config.requires cxx11_hdr_array]] in the jamfile for tests which I learned had been a source of problems back in 2016!
> http://boost.2283326.n4.nabble.com/question-regarding-quot-requires-cxx11-hdr-array-quot-clause-in-Jamfile-td4690277.html <http://boost.2283326.n4.nabble.com/question-regarding-quot-requires-cxx11-hdr-array-quot-clause-in-Jamfile-td4690277.html>
>
> So, what was the least disruptive solution? Yes, going with boost::array everywhere.

That certainly works ! But then the end-user who is compiling with C++11
on up in his code and using std::array when he needs a C++ array class
might be a bit piqued that he has to use boost::array in your case. OTOH
if he is compiling with C++11 on up he is probably using std::random
instead of boost::random so your choice is right.

[Kostas Savvidis via Boost]

> On Dec 2, 2020, at 00:01, Edward Diener via Boost <bo...@lists.boost.org> wrote:
>
> OTOH if he is compiling with C++11 on up he is probably using std::random instead of boost::random so your choice is right.

I am providing my new, better RNG in boost::random since convincing LWG to include it in std::random will take some while longer ;)

(btw, std:array is not a part of any interfaces of boost::random it is a purely an internal issue which, yes, I know, is not considered as serious)

[Edward Diener via Boost]

I am not against C++98/C++03 libraries being upgraded to C++11 in order
to use C++ standard library equivalents to Boost types. Nor am I against
a separate C++11 library of a current C++98/C++03 library being added to
Boost which uses C++ standard library equivalents to Boost types and in
all other respects is the same as the original library. But the latter
solution does require extra maintenance and who is going to do that ?

>
>
>> Linker may merge not ABI
>>> compatible Boost
>>> symbols, leading to breakages. More specifically, the layout of
>>> Boost.Variant changed multiple times since 1.45, but the signature of the
>>> boost::apply_visitor function did not change. As a result you get
>>> ODR-violation.
>>
>> Are you saying that Boost is not ABI compatible between releases but any
>> compiler's C++ standard library is always ABI compatible between releases ?
>>
>
> Not any, but many.

I believe the great majority of Boost libraries attempt to maintain ABI
compatibility between releases. But just like with compilers it is not
always possible between releases.

[Glen Fernandes via Boost]

On Tue, Dec 1, 2020 at 4:46 PM Antony Polukhin <anto...@gmail.com> wrote:
>
> On Wed, Dec 2, 2020, 00:23 Glen Fernandes <glen.fe...@gmail.com> wrote:
>>
>> On Tue, Dec 1, 2020 at 4:16 PM Antony Polukhin.
>> >
>> > Wich brings me to a less radical idea: we may simplify acceptance of dependenceless library clones. Next step would be to provide predefined bcp'ed subsets of libraries (boost 17, boost 23?)
>>
>> One option is for that other library (DLL for C++17+) to still live
>> under the boostorg/dll repository - i.e. it doesn't need to have its
>> own repository.
>
>
> You mean folder structure like
> include/boost/dll/
> include/boost/dll17/
>
> Would the bcp treat dependencies of include/boost/dll17 separately from include/boost/dll?

Yes, i.e. if we establish some convention like that, then the tools
should understand that.

This gives people much more freedom than have to have up to M*n
repositories (for n Boost libraries, and M different minimum-supported
standards) and especially have to go through an additional (M-1)
formal reviews for what is really the same library just switching
boost:: components to std:: ones.

Glen

[Gavin Lambert via Boost]

On 2/12/2020 11:01 am, Edward Diener wrote:

> On 12/1/2020 4:36 PM, Kostas Savvidis wrote:
>> #ifndef BOOST_NO_CXX11_HDR_ARRAY
>> #include <array>
>> #define mixmaxarray std::array
>> #else
>> #include <boost/array.hpp>
>> #define mixmaxarray boost::array
>> #endif
>> ...#undef mixmaxarray
>>
>> The other alternative kindly proposed by Steven was:
>> namespace boost { namespace random { namespace arrayns = std; } }
>
> I wrote a library called cxx_dual ( https://github.com/eldiener/cxx_dual
> ) to solve a problem like yours, but it did not meet with general
> approval. With cxx_dual your code above could have been:
>
> #include <boost/cxx_dual/array.hpp>
> #define mixmaxarray cxxd_array_ns::array

You shouldn't use #define for that sort of thing anyway. Define a local
typedef:

namespace boost
{
namespace mylib
{
typedef cxxd_array_ns::array mixmaxarray;
}
}

(Or a "using" alias, if you can assume C++11.)

However this is only actually correct behaviour if it's a header-only
library.

In a compiled library, what you actually should do is something closer
to this:

// header file
#if SOME_CONDITION
typedef std::foo myfoo;
namespace detail1 { class aclass { ...; std::foo m_foo; }; }
typedef detail1::aclass aclass;
#else
typedef boost::foo myfoo;
namespace detail2 { class aclass { ...; boost::foo m_foo; }; }
typedef detail2::aclass aclass;
#endif
class commonclass { void method(myfoo const& x); };

// cpp file 1
#if CAN_COMPILE_STD_FOO
// or equivalently set build rules to skip this file if std::foo doesn't
// exist at build time
void commonclass::method(std::foo const& x) { ... }
// implementation for detail1::aclass
#endif

// cpp file 2
void commonclass::method(boost::foo const& x) { ... }
// implementation for detail2::aclass

Note that the condition used to select the implementation in the header
file is not necessarily the same as the one used to decide whether to
build the std implementation (the first may be influenced by a user
preference, the second is not). Also note that the two implementations
are in separate cpp files because linkers have an easier time throwing
away entire object files if they're not referenced (at least in static
libraries), and may be less good at doing that for individual symbols.
And you *don't* make building the second file conditional.

If these rules are followed, and as long as the library is compiled with
the highest-desired-C++-standard, this allows apps to link against it
using either class safely -- you can even have a mix of both in the same
app provided those components don't try to directly talk to each other.

Actually doing these things in any non-trivial library, however, is
*very hard* -- not impossible, if you leverage some preprocessor tricks
-- but it's not surprising that most people don't want to do it until
they have no other choice. There's also a lot of subtle complications
where the compiler doesn't especially help you to catch violations, for
things even as simple as private members; pimpl helps but it's still
tricky, and has performance tradeoffs. ("aclass" avoids those problems
but introduces some of its own.)

And it quickly snowballs (as you add more dependencies) into an
unmanageable mess, unless you can take a whole slate of dependencies as
a fixed unit rather than having them individually configurable.

(It's perhaps worth noting that this doesn't *only* apply to compiled
libraries; this is similar to how glibc handles the different
implementations of std::string between C++03 and C++11, for example.)

C++ ABI is *hard*.

[Edward Diener via Boost]

On 12/1/2020 6:39 PM, Gavin Lambert via Boost wrote:
> On 2/12/2020 11:01 am, Edward Diener wrote:
>> On 12/1/2020 4:36 PM, Kostas Savvidis wrote:
>>> #ifndef BOOST_NO_CXX11_HDR_ARRAY
>>> #include <array>
>>> #define mixmaxarray std::array
>>> #else
>>> #include <boost/array.hpp>
>>> #define mixmaxarray boost::array
>>> #endif
>>> ...#undef mixmaxarray
>>>
>>> The other alternative kindly proposed by Steven was:
>>> namespace boost { namespace random { namespace arrayns = std; } }
>>
>> I wrote a library called cxx_dual (
>> https://github.com/eldiener/cxx_dual ) to solve a problem like yours,
>> but it did not meet with general approval. With cxx_dual your code
>> above could have been:
>>
>> #include <boost/cxx_dual/array.hpp>
>> #define mixmaxarray cxxd_array_ns::array
>
> You shouldn't use #define for that sort of thing anyway.  Define a local
> typedef:

I only used #define to mimic the original example. You are correct that
a typedef or type alias is the right way. In cxx_dual 'cxxd_array'
becomes the correct namespace, rather than 'std' or 'boost' and the
programmer can go from there.

[Alexander Grund via Boost]

> That's not what I have in mind. Macros don't solve the problem. What I
> have in mind is that there is a single library that, in its interface,
> can seamlessly take either boost::fs::path or std::fs::path, without
> the user having to define anything.
>
> Of course, when building the library, you probably would need to have
> Boost.Filesystem available.

This may work for simple types like string_view. But it won't work for
(non-header-only) libraries using e.g. fs::path. At some point you have
to convert to either type or to a third and that is gonna cost you

Additionally that interface may need includes to either or would require
the user to include that first introducing an include-order issue.

And finally once you return a type you have no way for "either" (again
except for simple types that could on-the-fly convert) and that too
requires an explicit choice for the include.

IMO it would be enough on a cost-benefit ratio to go to C++11 by
basically banning the use of MPL in Boost (the single-worst offender on
compile times) and reducing the use of type_traits to the absolute
minimum. Those 2 are (transitively) in the largest chunk of boost
libraries and hence hit hard on compiletimes. Then using the std
smart-pointers wherever possible would further untangle the libraries.
So basically a bottom-up approach to improvement instead of a fork to
whatever is the current greatest and latest. This could even be done
for/by GSoC, interns or similar. And in ~8 years one can check if C++17
would be a good base point.

[Andrey Semashev via Boost]

On 12/2/20 1:21 AM, Edward Diener via Boost wrote:
>
> I believe the great majority of Boost libraries attempt to maintain ABI
> compatibility between releases.

My impression is the opposite. Boost has never declared backward ABI or
API compatibility. There's a reason why binary distributions of Boost
append a version tag that matches Boost version to packages and binaries.

> But just like with compilers it is not
> always possible between releases.

You have to give credit to libstdc++ developers at the very least. It
maintains backward ABI compatibility across all C++ standard versions
and across libstdc++ releases for many years. I think, libc++ also does
the same, although I'm not following its development.

[Andrey Semashev via Boost]

On 12/2/20 12:43 AM, Antony Polukhin via Boost wrote:
> On Wed, Dec 2, 2020, 00:23 Glen Fernandes <glen.fe...@gmail.com> wrote:
>
>> On Tue, Dec 1, 2020 at 4:16 PM Antony Polukhin.
>>>
>>> Wich brings me to a less radical idea: we may simplify acceptance of
>> dependenceless library clones. Next step would be to provide predefined
>> bcp'ed subsets of libraries (boost 17, boost 23?)
>>
>> One option is for that other library (DLL for C++17+) to still live
>> under the boostorg/dll repository - i.e. it doesn't need to have its
>> own repository.
>>
>
> You mean folder structure like
> include/boost/dll/
> include/boost/dll17/
>
> Would the bcp treat dependencies of include/boost/dll17 separately from
> include/boost/dll?

AFAIR, bcp operates on file level, so yes, it should be able to select
individual headers used by some root source file, regardless of git
submodules.

If we're talking about dependency report and similar tools, it operates
on git submodule level, and therefore will treat boost/dll and
boost/dll17 as a single submodule with its common set of dependencies.
For example, depinst.py used in CI will pull all dependencies of the
submodule.

[Andrey Semashev via Boost]

On 12/2/20 1:17 AM, Kostas Savvidis via Boost wrote:
>
>> On Dec 2, 2020, at 00:01, Edward Diener via Boost <bo...@lists.boost.org> wrote:
>>
>> OTOH if he is compiling with C++11 on up he is probably using std::random instead of boost::random so your choice is right.
>
> I am providing my new, better RNG in boost::random since convincing LWG to include it in std::random will take some while longer ;)
>
> (btw, std:array is not a part of any interfaces of boost::random it is a purely an internal issue which, yes, I know, is not considered as serious)

Perhaps not in the particular case of array, but having user-selectable
std or boost components as class members is even more serious than in
interface (e.g. function arguments). Class member types do not get
reflected in the symbol names, which makes ABI discrepancies go
unnoticed by the linker and cause weird bugs in runtime. This is why
compile time selection between types of internal components is generally
discouraged.

[Mike via Boost]

> Gesendet: Mittwoch, 02. Dezember 2020 um 11:18 Uhr
> Von: "Andrey Semashev via Boost" <bo...@lists.boost.org>

>
> On 12/2/20 12:43 AM, Antony Polukhin via Boost wrote:
> > On Wed, Dec 2, 2020, 00:23 Glen Fernandes <glen.fe...@gmail.com> wrote:
> >
> >> On Tue, Dec 1, 2020 at 4:16 PM Antony Polukhin.
> >>>
> >>> Wich brings me to a less radical idea: we may simplify acceptance of
> >> dependenceless library clones. Next step would be to provide predefined
> >> bcp'ed subsets of libraries (boost 17, boost 23?)
> >>
> >> One option is for that other library (DLL for C++17+) to still live
> >> under the boostorg/dll repository - i.e. it doesn't need to have its
> >> own repository.
> >>
> >
> > You mean folder structure like
> > include/boost/dll/
> > include/boost/dll17/
> >
> > Would the bcp treat dependencies of include/boost/dll17 separately from
> > include/boost/dll?
>
> AFAIR, bcp operates on file level, so yes, it should be able to select
> individual headers used by some root source file, regardless of git
> submodules.

I believe this is true for the header files, but how would bcp know
which subset of source files to include?

Regards

Mike

[Peter Dimov via Boost]

Alexander Grund wrote:

> IMO it would be enough on a cost-benefit ratio to go to C++11 by basically
> banning the use of MPL in Boost (the single-worst offender on compile
> times) and reducing the use of type_traits to the absolute minimum. Those
> 2 are (transitively) in the largest chunk of boost libraries and hence hit
> hard on compiletimes.

What is the problem with TypeTraits?

[Edward Diener via Boost]

On 12/2/2020 5:12 AM, Andrey Semashev via Boost wrote:
> On 12/2/20 1:21 AM, Edward Diener via Boost wrote:
>>
>> I believe the great majority of Boost libraries attempt to maintain
>> ABI compatibility between releases.
>
> My impression is the opposite. Boost has never declared backward ABI or
> API compatibility. There's a reason why binary distributions of Boost
> append a version tag that matches Boost version to packages and binaries.

Whether Boost declares it or not I do not think Boost libraries change
the API or ABI very often between releases and, if they do, they will
notify the end-user about it. But of course you are correct that their
is no attempt at a policy that claims compatibility between releases.

>
>> But just like with compilers it is not always possible between releases.
>
> You have to give credit to libstdc++ developers at the very least. It
> maintains backward ABI compatibility across all C++ standard versions
> and across libstdc++ releases for many years. I think, libc++ also does
> the same, although I'm not following its development.

So are you telling me that if I have gcc-10.2 I should be able to use
the gcc-5.1 libstdc without any ABI problems ?

[Edward Diener via Boost]

Feel free to offer PRs to those C++98/C++03 libraries to transition them
from MPL to mp11 and from Boost type traits to standard type traits so
that they can become C++11 libraries. I do have the greatest admiration
for mp11 so I am not being facetious. But "banning" MPL and Boost type
traits is going to currently remove a great number of libraries from
Boost. I do agree that a bottom up approach is necessary to transition
Boost libraries to C++11 since a given Boost C++98/C++03 library has
dependencies on other Boost C++98/C++03 which themselves use the Boost
rather than the equivalent standard library.

[Glen Fernandes via Boost]

On Wed, Dec 2, 2020 at 9:20 AM Edward Diener via Boost
<bo...@lists.boost.org> wrote:
>
> On 12/2/2020 4:03 AM, Alexander Grund via Boost wrote:
> >
> > IMO it would be enough on a cost-benefit ratio to go to C++11 by
> > basically banning the use of MPL in Boost (the single-worst offender on
> > compile times) and reducing the use of type_traits to the absolute
> > minimum.
>

> Feel free to offer PRs to those C++98/C++03 libraries to transition them
> from MPL to mp11 and from Boost type traits to standard type traits so
> that they can become C++11 libraries.

+1.

Nothing is going to be banned, but Alex is encouraged to convince
library authors to update their libraries in this way, and encouraged
to offer to help them in doing so.

Glen

[Andrey Semashev via Boost]

On 12/2/20 5:06 PM, Mike via Boost wrote:
>> Gesendet: Mittwoch, 02. Dezember 2020 um 11:18 Uhr
>> Von: "Andrey Semashev via Boost" <bo...@lists.boost.org>
>>
>> On 12/2/20 12:43 AM, Antony Polukhin via Boost wrote:
>>>
>>> Would the bcp treat dependencies of include/boost/dll17 separately from
>>> include/boost/dll?
>>
>> AFAIR, bcp operates on file level, so yes, it should be able to select
>> individual headers used by some root source file, regardless of git
>> submodules.
>
> I believe this is true for the header files, but how would bcp know
> which subset of source files to include?

bcp gives you the header files included into a source file, and nothing
more. It also has the caveat that it doesn't preprocess files, so it may
miss includes that are obscured by macros. It does not give you the
source files for separately compiled libraries, which may be required to
implement components declared in those headers.

[Andrey Semashev via Boost]

On 12/2/20 5:08 PM, Edward Diener via Boost wrote:
> On 12/2/2020 5:12 AM, Andrey Semashev via Boost wrote:
>> On 12/2/20 1:21 AM, Edward Diener via Boost wrote:
>>>
>>> I believe the great majority of Boost libraries attempt to maintain
>>> ABI compatibility between releases.
>>
>> My impression is the opposite. Boost has never declared backward ABI
>> or API compatibility. There's a reason why binary distributions of
>> Boost append a version tag that matches Boost version to packages and
>> binaries.
>
> Whether Boost declares it or not I do not think Boost libraries change
> the API or ABI very often between releases and, if they do, they will
> notify the end-user about it.

No, not really. Internal changes are often not reflected in the release
notes at all, while they may affect ABI.

You may have an impression of stability because many Boost libraries
don't change that much (e.g. due to lack of maintenance). This is not a
result of a maintenance decision, but a product of the lack of
development. Hence this is not a guarantee or promise or whatever that
ABI/API is stable.

> So are you telling me that if I have gcc-10.2 I should be able to use
> the gcc-5.1 libstdc without any ABI problems ?

No, because a program compiled with gcc 10 may use symbols of the
standard library that were not available in gcc 5. But you could do the
other way around - have your program compiled by gcc 5 and run it with
libstdc++ from gcc 10. People do this rather often, when they install
pre-compiled binaries from external sources (i.e. not from the distro
repositories).

There are a few ABI changes that were made in gcc (the compiler, not
libstdc++), but there are options to highlight code affected by them or
switch to the older behavior. I did not research whether libstdc++ is
affected by those, but I would assume either not affected or the
necessary workarounds are in place.