On Fri, May 26, 2023 at 5:56 PM Gabriel Dos Reis <gdr_at_[hidden]> wrote:

>
> - I would be much happier seeing compilers move to standard-mandated
> behavior, rather than changing the standard to match current behavior.
>
>
>
> Someone would need to do the work to prove out that hypothesis at scale.
>

What hypothesis is this? Are you arguing against this as a general
principle to follow, or are you arguing against it in the specific case I
was referring to? Specifically, that when you import a header it should
ignore the -D (and similar) flags passed on the importer's command line and
should only consider the flags used when compiling the importable header.
If you don't agree with that, what is your alternative rule?


>
> An example of that is when the MSVC team conducted the work needed to
> rectify the specification for operator<=>.
>
>
>
> -- Gaby
>
>
>
>
>
> *From:* SG15 <sg15-bounces_at_[hidden]> *On Behalf Of *Mathias
> Stearn via SG15
> *Sent:* Friday, May 26, 2023 6:29 AM
> *To:* Ben Boeckel <ben.boeckel_at_[hidden]>
> *Cc:* Mathias Stearn <redbeard0531_at_[hidden]>; Mathias Stearn via SG15 <
> sg15_at_[hidden]>; Tom Honermann <tom_at_[hidden]>
> *Subject:* Re: [SG15] P2898R0: Importable Headers are Not Universally
> Implementable
>
>
>
>
>
>
>
> On Fri, May 26, 2023 at 2:53 PM Ben Boeckel <ben.boeckel_at_[hidden]>
> wrote:
>
> On Fri, May 26, 2023 at 13:55:43 +0200, Mathias Stearn via SG15 wrote:
> > Given the note in http://eel.is/c++draft/cpp.import#5 applying to the
> > definition of the term "macro definition", we should probably change the
> > CWG2732 note to say something like "macro definitions and predefined
> > macros". While -D predefined macros are somewhat outside the scope of the
> > standard, and the standard has no concept of a build using different
> values
> > for the standardized predefined macros for different TUs (which is
> > unfortunately common practice), I think we should be clear (in a note)
> > that the predefined macros used for a header unit are those used when
> > compiling *its* TU, not the importer's.
>
> What about other flags that affect preprocessor state? This includes
> things like `-m` flags and `-f` flags that can affect things like
> `__x86_64__` definitions and `__has_builtin` queries.
>
> If we can get into the standard that a TU's flags that get used for a
> BMI are "trusted" (in some sense) it would seem to me that we'd be a lot
> closer to being able to build fewer BMIs for a given header unit. I
> suspect that such a thing is signing up implementations for a lot more
> work though.
>
>
>
> I _think_ the current normative wording already says that is the case*.
> However, given that that doesn't match the current compiler behavior that
> doesn't really help much. I will admit that my opinion of header units
> being useful, helpful, and practical does rely on that bit of the wording,
> and that it doesn't match compiler reality today. I would be much happier
> seeing compilers move to standard-mandated behavior, rather than changing
> the standard to match current behavior. Of course neither happening is
> worse, since a standard that isn't followed is worthless. But I assume
> since people from the 3 main compiler vendors were heavily involved in the
> wording, they believe it isn't too much work for their implementations to
> comply with it.
>
>
>
> * there is a much thornier question of mixing -std= flags. The standard is
> by necessity silent on that because normatively there is only one active
> standard. However, in practice implementations support both a) picking a
> standard other than the latest one, and b) mixing files compiled with
> different standards into the same program image (even if this is an
> ODR-violating Bad Idea). I have no idea what it means to import the C++23
> <vector> (eg) into a TU compiled for C++20, or vice versa. Both directions
> seem likely to be nonsensical since the C++N <vector> is likely to use
> language features that don't exist in C++(N-3), and a C++23 TU is likely to
> depend on vector features that aren't present in C++20. I think that at
> least for standard headers, they need to have different BMIs for different
> C++ versions. For non-std headers, I could imagine allowing cross-version
> usages, but there are a lot of unknowns, including what to do if they
> transitively import std headers. For C++20 modules it was easy because
> there could only be one (non-expirimental) -std= with modules, however,
> with C++23 that would no longer be the case. I had hoped that we would have
> figured this out in the 3 years between 20 and 23, but clearly that hasn't
> happened. And FWIW, I think the new std module has this same
> problem, although it can kick the can down the road for 3 more years.
>