Re: State and plans for C++20 module support?

Hello Zack!

> 0) According to your "arewemodulesyet" site, neither GCC nor Clang fully
>     supports modules yet, so I would suggest that developer effort is
>     best spent there *first.*  Autotools probably *shouldn't* try to do
>     much of anything with incompletely implemented language features;
>     we've had bad luck with that in the past.

I think it is implemented so far that projects are asked to give it a 
try and provide feedback. Without build system support only tiny proof 
of concepts will be done.

> 1) Autoconf includes logic to probe for various compiler features and
>     for adequate support for various levels of the C and C++ standards.
>     These probes have a bunch of problems and they currently don't
>     include anything newer than about 2017 for either C or C++.

I think the probes have lost their relevance for more recent versions of 
C++. Most new features have preprocessor macros corresponding to C++ 
language features (like __cpp_modules).

>  However, the biggest problem with them is NOT that they
>     are out of date, but that they do not allow the package being
>     configured to declare which edition of the language standard they
>     want. That needs to be addressed *before* we add any more editions,
>     because the current behavior of selecting the most recent edition the
>     compiler supports is known to be troublesome for big important things
>     like Postgres, and we don't want to make it worse.

Again, can we work with preprocessor macros? __cplusplus together with a 
list of possible std= flags?

>     If you're interested in working on this yourself, or you know someone
>     who is, I would be happy to go into more detail.  As things stand,
>     if nobody steps up to do the work, it is unlikely to get done soon.

I want to document the status quo. Maybe I can spark interest with others.

> 2) Besides an "is this feature available" probe, I don't know if any
>     support for C++ 2020 modules is even *necessary*, because I don't
>     know how they work.  If any other changes are necessary, they would
>     probably need to happen in Automake and Libtool, not in Autoconf.

I expect different types of work for
1. using external libraries as modules within a Autotools project
2. using C++23 "import std"
3. Exposing modules from a Autotools project for others

Bye
Christoph

-- 
Most customers will not accept source code with compile errors in it.
                  Dan Saks, CppCon 2016 (https://youtu.be/D7Sd8A6_fYU)