Agree here.
submit one or two changes every second release.
To attract new developers, both employment and contributions, we should
use all stable features that exist in the compilers supported by the supported
distros of our codebase.
It seems the
mariadb.com job adverts on Senior C++ Database Engine Developer
have qualification "You use the C++20 standard since 2020 and C++17 since 2017.".
How disappointed are they going to be in employment when C++20 is a no
go and even C++17 construct usage is rare? Do you think staff will be retained up
until when C++20 becomes allowed is to be possible?
Insisting on code constructs that existed before many new developers are
born is a sure way to put them off. Thinking back to my early career (also a
a long time ago) I had no desire to work on COBOL or Fortran (even though
I didn't and still don't know anything about them). To avoid a "I worked on
those", this isn't a reflection of the technology, just I didn't, and still aren't,
in tech to work on "old stuff".
The Foundation goal of continuity and openness can only be met while people
are willing and able to work in the codebase.
6. complexity
Currently highlighted below, the variety of options is creating large complexity in the codebase.
We should trust, but validate via testing that C++ implementers can implement these appropriately.
They have great skills, and are typically employed by a distro or hardware platform company that has
easy access to those hardware professionals to validate an exceptionally optimal implementation.
As a highlight of an old PR of mine where we took a "we know better stance" and never re-revaluted
under a not accessible define, but still got effort better spent elsewhere put into it recently maintain
to conform to compatible behaviour).
As our current bug queue indicates that we've got enough to handle on the database layer of things
without maintaining, dare I exaggerate slightly not-invented-here, low level constructs well maintained
elsewhere.
...