Re: C++20 and gcc12/10

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Wed, Apr 16, 2025 at 04:41:37PM -0400, Greg Troxel wrote:
 > yes, but if you actually try to make this work instead of constructing a
 > contrarian example, you'd end up with:
 > 
 >   USE_CXX_FEATURES+=	c++14-lite c++14-foo c++14-bar
 > 
 > for a program that needs:
 > 
 >   the ability to pass --std=c++14 (baseline as you say)
 > 
 >   the parts of c++14 that *in practice* are considered so core, such
 >   that essentially all compilers that accept --std=c++14.  Or really
 >   such that if a compiler doesn't implement them, it is reasonable to
 >   ignore it.
 > 
 >   the foo and bar features from c++14, but not the other features
 > 
 > and I do not find that confusing or semantically troubled.

I also didn't really follow exactly what you and jperkin were arguing
about, but I think there's two choices here:

(1) a feature c++14-base, then additional features c++14-frobnitz,
c++14-frobozz, c++14-fribnutz; or

(2) features c++14-frobnitz, c++14-frobozz, and c++14-fribnutz that
build on c++11 (rather than a c++14-base)

plus in both cases a feature c++14-full (or just c++14) that
encompasses everything.

ISTM that in general the c++14-base feature is necessary because
that's what guarantees that the response to being passed --std=c++14
is not "unable". Therefore, option (2) isn't good enough and we can
stop arguing about it.

However, for what we're talking about it seems perfectly reasonable to
define a c++20-gcc10 feature that specifically means "the subset of
c++20 that gcc10 handles successfully", and apply it in packages only
when it's been found to be sufficient.

That obviously will create problems if there are a lot of such
features and they start having intersections (like "the subset of
c++20 that gcc10 and clang21 but not clang20 handle successfully")
... but there is no evidence that this is a realistic problem or that
there are mountains of these special exception cases to worry about.

(Furthermore, this one only remains of interest as long as gcc10 is
still significantly relevant. At the point where gcc10 looks like say
gcc6 does now, the c++20-gcc10 feature can be removed and replaced
with just c++20. So it's not like we're committing to keeping this
extra frob forever.)

So I think chasing after exactly what gcc10 does and doesn't support
and trying to characterize it precisely in terms of language features
is a large waste of time.

-- 
David A. Holland
dholland%netbsd.org@localhost