Proposal to start process towards C++20 baseline

[tinko92]

I propose to start work towards moving the C++ baseline to C++20 (except modules because their implementation is still ongoing), specifically

1. Designate a future Boost Release for which C++14 compatibility will be dropped. Based on precedent, I propose 1.96 (December 2027) or 1.97 (April 2028).
2. Add a deprecation to the release notes and headers in the next version ("next" as in after resolution of this discussion if the proposal is accepted), e.g. 1.93.
3. Allow PRs relying on C++20 features to be merged after the picking of the release branch for the last version before dropping C++14 (e.g. after 1.95).
4. Add a CI job now that compiles with C++20 to avoid any changes in the mean time that would break in c++20 (unlikely to happen but there are some new keywords and deprecations).

Motivation

Major refactoring opportunities using features that standardize what we already do, such as concepts (replacing macros/BCCL), constraints (replacing a lot of SFINAE), constexpr if (replacing a lot of partially specialized on bools wrapper structs with apply methods. (click for details)

BG is a library that heavily utilizes template metaprogramming and many of the techniques and library facilities it has been using for a long time have received native language support by C++20. Relying on this standard allows refactoring several verbose and complicated constructs that are used heavily in the library into concise and modern-C++-idiomatic expressions that make their intent clear on first glance. Besides shorter and clearer code, this also drops Boost-internal dependences. The useful new features for refactoring since C++14 include mainly:

• Concepts (C++20): Concepts are currently emulated using the BCCL and macros. Native concepts can be written more directly and can be used to constrain functions from an overload set (instead of using SFINAE/enable_if) or (partial) template specializations. Most importantly, native C++20 concepts can give nicer error messages that in many cases fit into a single console buffer or even screen.
• constexpr if (C++17): Already used behind a macro-guard to suppress warnings about compile-time constant if conditions but their main advantage is that they allow code in the non-selected branch that would be ill-formed otherwise, i.e. code that we would currently need to move out into members of partially speciliased template structs, even if the conditional code is just one line for each case.
• Fold Expressions (C++17): Express very concisely what would otherwise require template recursion
• fewer needs for typename (C++20): Naturally that keyword features heavily in the codebase.
• Ranges (C++20): They are a core part of geometry concepts and are used heavily in algorithms. rtree query iterators model filtered ranges in some way already.

New feature opportunities such as coroutines and execution policies for parallel algorithms.

• BG algorithms already have a notion of policies, C++17 brought execution policies (sequenced, parallel, unsequenced (C++20), parallel_unsequenced), which may be useful for some of them
• Coroutines: I think, that abstraction would make some sense in overlay (lazy discovery of turns)/traversal, have not tried, though.

Cost and Risk

Compiler Support

The main cost is dropping support for older compilers.

• GCC: drops 7, 8, 9, maybe 10 (a few misc features missing), baseline becomes 10 (released 2020) or 11 (released 2021).
• Clang: drops 6 - 11 for most features, up to 15 if we want fewer typename, [[likely]], [[unlikely]] and some other features. Baseline becomes 12 (2021) or 16 (2023).
• MSVC: drops everything before VS 2019 16.11, if I read their inscrutable versioning system correctly, so the baseline becomes VS 2019 16.11 (2021).
  EDG, Intel and nvidia are currently not tested in CI but supporting versions exist.

Reverse dependencies

Since this is a header-only library, this choice affects every library that 1) depends on Boost.Geometry and 2) tracks Boost releases (if it just packages a frozen working version, it doesn't matter). Here is what I found so far:

• MySQL: According to the 8.3 release notes, the boost version is bundled and "Changed the default standard C++ language version needed to compile MySQL from C++17 to C++20. (Bug #35781622)", and it seems to track new C++ versions quickly ( mysql/mysql-server@bfdb37c ).
• nGen: On C++20 https://github.com/NOAA-OWP/ngen/blob/master/doc/DEPENDENCIES.md#c-and-c-compiler
• HeavyDB: In the process of migrating pending the resolution of issues, heavyai/heavydb@1568520
• FreeCAD: C++20, https://github.com/FreeCAD/FreeCAD/blob/6add02aa6f8d63228a8a65a62e76b0e30767c65d/cMake/FreeCAD_Helpers/CompilerChecksAndSetups.cmake#L30
• osm2pgsql: Still on C++17, discussion (near fmt) implies they may switch in the future: Future of vendored libraries osm2pgsql-dev/osm2pgsql#2296
• Lanelet2: Still on C++14, I see no plans of that changing (based on a quick search)
• Autoware: On C++17, https://github.com/autowarefoundation/autoware_universe/blob/4e4e370ccfbd6e41b7a4a470a874a2956d8bb2f9/.clang-tidy-ci#L25, some code comments imply that they want to move to C++20 at some point
• pgRouting: On C++17, https://github.com/pgRouting/pgrouting/blob/471224018f17ffa3e7ef9a356389c125a48f3f54/CMakeLists.txt#L131

More than a year later, this will probably have improved more. This list is by no means complete, it's just what I could find quickly. If there are other users where it would be a major issue, a deprecation warning may motivate feedback on that.

Examples and Measurements

The following is based on using Codex with GPT 5.6 Sol to produce a demonstration of refactoring opportunities. It's certainly not complete (I had to reprompt with several obvious missed opportunities and more remain) but it gives some rough line numbers, allows compile time benchmarks and examples. The branches can be seen on my github:

• https://github.com/tinko92/geometry/tree/codex/geometry-cxx17-modernization
• https://github.com/tinko92/geometry/tree/codex/geometry-cxx17-no-legacy-types
• https://github.com/tinko92/geometry/tree/codex/geometry-cxx20-modernization
• https://github.com/tinko92/geometry/tree/codex/geometry-cxx20-no-legacy-types
• https://github.com/tinko92/geometry/tree/codex/geometry-cxx20-no-legacy-std-ranges

Examples

Concept (C++20) rewrite of Ring

template <typename Geometry>
concept ConstRing =
    std::same_as<tag_t<geometry_type_t<Geometry>>, ring_tag>
    && detail::ConstRandomAccessRange<geometry_type_t<Geometry>>
    && ConstPoint<point_type_t<geometry_type_t<Geometry>>>;


template <typename Geometry>
concept Ring =
    ! std::is_const_v<std::remove_reference_t<Geometry>>
    && ConstRing<Geometry>
    && Point<point_type_t<geometry_type_t<Geometry>>>
    && detail::MutableRange<geometry_type_t<Geometry>,
                            point_type_t<geometry_type_t<Geometry>>>;

Constraint (C++20) based dispatch of area

New

template <concepts::ConstBox Box, typename Strategies>
inline area_result_t<Box, Strategies>
area_impl(Box const& box, Strategies const& strategies)
{
    assert_dimension<Box, 2>();
    return strategies.area(box).apply(box);
}

template <concepts::ConstRing Ring, typename Strategies>
inline area_result_t<Ring, Strategies>
area_impl(Ring const& ring, Strategies const& strategies)
{
    using strategy_type = decltype(strategies.area(ring));

    static_assert(concepts::AreaStrategy<Ring, strategy_type>);
    assert_dimension<Ring, 2>();
    // ...
}

template <concepts::ConstPolygon Polygon, typename Strategies>
inline area_result_t<Polygon, Strategies>
area_impl(Polygon const& polygon, Strategies const& strategies)
{
    area_result_t<Polygon, Strategies> result
        = area_impl(exterior_ring(polygon), strategies);
    auto const& rings = interior_rings(polygon);
    for (auto it = boost::begin(rings); it != boost::end(rings); ++it)
    {
        result += area_impl(*it, strategies);
    }
    return result;
}

template <concepts::ConstMultiPolygon MultiPolygon, typename Strategies>
inline area_result_t<MultiPolygon, Strategies>
area_impl(MultiPolygon const& multi, Strategies const& strategies)
{
    area_result_t<MultiPolygon, Strategies> result = 0;
    for (auto it = boost::begin(multi); it != boost::end(multi); ++it)
    {
        result += area_impl(*it, strategies);
    }
    return result;
}

template <concepts::ConstGeometry Geometry, typename Strategies>
    requires (! concepts::ArealGeometry<Geometry>)
          && (! concepts::ConstDynamicGeometry<Geometry>)
          && (! concepts::ConstGeometryCollection<Geometry>)
inline auto area_impl(Geometry const& geometry, Strategies const& strategies)
{
    boost::ignore_unused(geometry, strategies);
    return area_result_t<Geometry, Strategies>();
}

Old

struct box_area
{
    template <typename Box, typename Strategies>
    static inline auto
    apply(Box const& box, Strategies const& strategies)
    {
        // Currently only works for 2D Cartesian boxes
        assert_dimension<Box, 2>();

        return strategies.area(box).apply(box);
    }
};


struct ring_area
{
    template <typename Ring, typename Strategies>
    static inline typename area_result<Ring, Strategies>::type
    apply(Ring const& ring, Strategies const& strategies)
    {
        using strategy_type = decltype(strategies.area(ring));

        BOOST_CONCEPT_ASSERT( (geometry::concepts::AreaStrategy<Ring, strategy_type>) );
        assert_dimension<Ring, 2>();
        // ...

        return strategy.result(state);
    }
};


}} // namespace detail::area

// ...

namespace dispatch
{

template
<
    typename Geometry,
    typename Tag = tag_t<Geometry>
>
struct area : detail::calculate_null
{
    template <typename Strategy>
    static inline auto apply(Geometry const& geometry, Strategy const& strategy)
    {
        return calculate_null::apply
            <
                typename area_result<Geometry, Strategy>::type
            >(geometry, strategy);
    }
};


template <typename Geometry>
struct area<Geometry, box_tag> : detail::area::box_area
{};


template <typename Ring>
struct area<Ring, ring_tag>
    : detail::area::ring_area
{};


template <typename Polygon>
struct area<Polygon, polygon_tag> : detail::calculate_polygon_sum
{
    template <typename Strategy>
    static inline auto apply(Polygon const& polygon, Strategy const& strategy)
    {
        return calculate_polygon_sum::apply
            <
                typename area_result<Polygon, Strategy>::type,
                detail::area::ring_area
            >(polygon, strategy);
    }
};


template <typename MultiGeometry>
struct area<MultiGeometry, multi_polygon_tag> : detail::multi_sum
{
    template <typename Strategy>
    static inline auto apply(MultiGeometry const& multi, Strategy const& strategy)
    {
        return multi_sum::apply
               <
                   typename area_result<MultiGeometry, Strategy>::type,
                   area<typename boost::range_value<MultiGeometry>::type>
               >(multi, strategy);
    }
};


} // namespace dispatch

namespace resolve_dynamic
{

template <typename Geometry, typename Tag = geometry::tag_t<Geometry>>
struct area
{
    template <typename Strategy>
    static inline auto apply(Geometry const& geometry, Strategy const& strategy)
    {
        return resolve_strategy::area<Strategy>::apply(geometry, strategy);
    }
};

template <typename Geometry>
struct area<Geometry, dynamic_geometry_tag>
{
    template <typename Strategy>
    static inline auto apply(Geometry const& geometry, Strategy const& strategy)
    {
        typename area_result<Geometry, Strategy>::type result = 0;
        traits::visit<Geometry>::apply([&](auto const& g)
        {
            result = area<util::remove_cref_t<decltype(g)>>::apply(g, strategy);
        }, geometry);
        return result;
    }
};

template <typename Geometry>
struct area<Geometry, geometry_collection_tag>
{
    template <typename Strategy>
    static inline auto apply(Geometry const& geometry, Strategy const& strategy)
    {
        typename area_result<Geometry, Strategy>::type result = 0;
        detail::visit_breadth_first([&](auto const& g)
        {
            result += area<util::remove_cref_t<decltype(g)>>::apply(g, strategy);
            return true;
        }, geometry);
        return result;
    }
};

} // namespace resolve_dynamic

constexpr if (C++17) based selection of distances strategy

New

if constexpr (detail::is_pp_v<Geometry1, Geometry2>)
    return strategy::distance::pythagoras<CalculationType>();
else if constexpr (detail::is_ps_v<Geometry1, Geometry2>)
    return strategy::distance::projected_point<...>();
else if constexpr (detail::is_pb_v<Geometry1, Geometry2>)
    return strategy::distance::pythagoras_point_box<CalculationType>();
else if constexpr (detail::is_sb_v<Geometry1, Geometry2>)
    return strategy::distance::cartesian_segment_box<...>();
else
    return strategy::distance::pythagoras_box_box<CalculationType>();

C++20 Concept error messages

boost::geometry::area(1);

error: no matching function for call to 'area'
note: candidate template ignored: constraints not satisfied [Geometry = int]
note: because 'int' does not satisfy 'ConstGeometry'
note: because 'concept_type<const geometry_type_t<int>>::value'
      evaluated to false

Refactoring measurements in lines

Develop to C++17 (keeps legacy type support for e.g. Boost.Variant): -871 lines
Develop to C++17 without legacy type (e.g. Boost.Variant which arguably becomes obsolete with std::variant) support: -2590 lines
Develop to C++20 with legacy type support: -4231 lines
Develop to C++20 without legacy type support: -6,929 lines

These refactorings are, as mentioned above, incomplete. I prompted Codex a couple of times with obvious oversights until I ran out of tokens, and I limited it to somewhat mechanical transformations (replacing partial specialisations on bools with constexpr if, sfinae with constraints, etc.).

Compile Time

With a big grain of salt because this is based purely on the incomplete LLM-refactorings and only two compiler versions compiling the full test suite, from develop to the C++20 branch:
Clang 22: no significant changes in compile time, 460MiB less RAM in total (-j20)
GCC 16: CPU time goes from 7064s to 6617s, RAM use from 31.44 GiB to 29.37 GiB, also -j20.
Roughly half the savings without dropping support for legacy types.

[barendgehrels]

Cool initiative. In case you're not aware, I researched it two years ago for this presentation:

https://www.youtube.com/watch?v=UcxD_ORaMM0

I don't think is identical to your proposal but there are apparently more options.

So I'm all in for using C++20 concepts!

[tinko92]

@awulkiew Yes, I wanted to get rid of that particular dependency from graph on BG because BG also depends on graph and they are two rather big libraries with a lot of dependencies.

We can probably somewhat estimate the number of users relying on a specific standard by searching for BG includes through Github and checking their (C)Make files. This is how found the examples in the opening post, if you expand the section below "Reverse Dependencies". Due to the Boost license without copyleft, we may not be able to know about proprietary users. I will try to do a wider search as soon as I find time (maybe in ~2 weeks).

For users of BG who depend on pre-C++20, it will only be an issue if they track new BG releases rather than depending on some frozen version checkout of it. Maybe this would be more common with Open Source users whose software builds as some distribution package that fetches its build dependencies through the respective package manager, but that's just a guess from me.

[vissarion]

I have used claude to search Sourcegraph's public index, which covers a subset of popular public GitHub repos rather than all of GitHub (median ~160 stars in this sample).

It has 521 repos (excluding forks, archived repos and packaging repos) that #include <boost/geometry...>. For each one I took the C++ standard set in the project's own build files (CMAKE_CXX_STANDARD, cxx_std_NN, -std=c++NN, etc.), ignoring vendored, test and example directories. That gave a standard for 350 of them. "Active" means a commit in the last 12 months; that filter only returned repos with 500+ stars.

Standard	All (350)	≥100 stars (237)	Active (75)
≤ C++11	20%	16%	0%
C++14	19%	21%	8%
C++17	32%	31%	40%
C++20	18%	19%	37%
≥ C++23	11%	13%	15%

Some examples among active projects:

• C++20+: ClickHouse, MySQL, FreeCAD, MongoDB, Milvus, HHVM, PrusaSlicer, OSRM, Valhalla, CARLA, ArangoDB, mapnik, maplibre-native, OpenROAD, organicmaps
• C++17: CGAL, OrcaSlicer/BambuStudio, Krita, LibreCAD, OceanBase, deal.II, osm2pgsql, pgRouting, Autoware, tilemaker, HeavyDB, SU2, Impala
• C++14: openedr, cinolib, opendr, OpenDungeons

In vcpkg, only 6 ports depend on boost-geometry: libmysql, dv-processing and mapnik (C++20+), and CGAL, libinterpolate and openturns (C++17). CGAL uses Boost.Geometry only in its WKT I/O headers (CGAL/IO/WKT*.h).

In general I'm in favour of the proposal. If we make the deprecation warning early (as Tinko proposed) then I guess that would be OK for most of the projects to react.

[barendgehrels]

@vissarion thanks for the interesting list, and the way how you got it!

So I agree, we can make the deprecation warning and start updating. The update might be major (especially the concepts), at this moment I'm not available for major support. But I assume we don't jump on it right away.

[awulkiew]

In other words, the % of users left without updates:

Standard	All (350)	≥100 stars (237)	Active (75)
C++17	39%	37%	8%
C++20	71%	68%	48%

[barendgehrels]

@awulkiew yes, we cannot avoid a % leaving without update. It now appears for C++17 there is no choice because we depend on Boost.Graph, and we have to do it soon.

So then there is a new choice:

• upgrade to C++20 immediately (at least state that in the deprecation warning)
• follow Boost.Graph's policy (but for us, C++17 is a minor profit. It's the concepts that we are missing)

[tinko92]

I noticed an event that may make this choice for us wrt to C++ version and release targeted:

Boost.Graph 1.95 will be C++17 , boostorg/graph#613

We are one of the three Boost libraries besides graph_parallel and mpi that depends on graph, and we depend on an actual algorithm.

Their corresponding reddit thread may be useful: https://www.reddit.com/r/cpp/comments/1wt531i/boostgraph_195_will_be_c17/ It e.g. points to the current MISRA standard being for C++17, which is industry-relevant and may include proprietary software users that we could not find by checking open repositories. I don't have any insight into how that standard develops, according to LLM-summary it might bump their C++ standard to 20 only in 2028/2029.

If we want to keep the Boost.Graph dependency, we may want to at least bump the requirement C++17 for Boost 1.95 and in that case already get the deprecation warning in for Boost 1.93 which closes for major changes in 3 weeks.

[tinko92]

I reached out to Boost.Graph and they kindly confirmed that C++17-requirements could be relevant for our use of Boost.Graph right away with 1.95, boostorg/graph#613 (comment) . So our safe options are:

• Keep using it and declare C++17 our baseline ourselves for 1.95. Then we probably want a deprecation warning for the upcoming release already, so we would want to make that decision within the next couple of weeks.
• Drop the Boost.Graph dependency ( @barendgehrels since this is your code, you could probably assess the risks/costs of this)
• Ask them for a path of less friction.

[barendgehrels]

Good point @tinko92 !

So there is no choice, and (worse) we cannot avoid the deprecation warning. It's soon.

Dropping the Boost.Graph dependency is not my preference: it is just there, solved a lot of issues, making the code much cleaner. Coding a Graph by hand (we don't use everything) might be possible but I don't think it's preferred, and I cannot make that anyway in 3 weeks.

So indeed we then should add deprecation warning for the upcoming release already. I'm still in favour of C++20.

I guess we can make that. Even if we don't have all desired C++20 (and C++17) features implemented by 1.95 - we can still upgrade then.

How can we add that deprecation warning (we did it earlier) and who could take care?

[tinko92]

I'll create a PR by tomorrow and follow the exact form that was used for the C++03 deprecation warning back for the switch to C++14 (notice in Readme, Doc, and conditional compiler pragma in the header based on missing C++17 feature macro).

[barendgehrels]

Super Tinko, thanks a lot!

[tinko92]

Resolved for now with #1496 .