Re: C++20 and gcc12/10

[Greg Troxel <gdt%lexort.com@localhost>]

David Holland <dholland-pkgtech%netbsd.org@localhost> writes:

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

Agreed; option 1 is the only path.

Further, I think for semantic sanity, c++14 should mean "really the
whole language", but c++14-base/c++14 vs c++14/c++14-full is somewhat a
paint color.   Using c++14 for "whole language" is also preferable for
when "less than c++14" becomes irrelevant.

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

I think we can do this operationally, understanding that we have and
will have rough edges about our understanding of the world, to be fixed
up as needed:

  c++20-base: the part of the language that gcc10 copes with

  c++20: the full language (that you need gcc12 for)

and then

  if we find there's a clang X that supports enough of c++20 to be
  useful building more than one or two programs that are in pkgsrc, but
  is less than what gcc10 supports, pivot base to mean the subset
  supported by both clang X and gcc 10.

    if further there are real programs that clang X isn't enough for,
    but gcc10 is, and it hurts to use gcc12 for them, figure out why and
    add a c++20-foo for that feature.

So this is basically aligning base to gcc10 and full to 12, but being
willing to adjust if we have to, and not worrying about the in-between
labels until needed.

(I think this idea is matches nia@'s opinion of not liking your option
2, as I read it.)


(This is all orthogonal to the "building with multiple compilers
considered harmful" discusion.  I ~always want to keep separate things
separate anyway.)