On 6/4/22 1:59 AM, Daniela Engert via SG15 wrote:
> Am 03.06.2022 um 23:39 schrieb Gabriel Dos Reis via SG15:
>> You just reminded me why I discouraged WG21 from going with the future test macros train 😊
>>
>> I will repeat what I said back then, if you're compiling with a certain standard language version set, you should just accept that the feature is available instead of playing #ifdefry games with feature test macros. They have their own ways of backfiring.
>
> I think it was you who some time ago was pointing out to me that
> implementations are allowed to do "things" related to the
> specification document that mundane users are not. My interpretation
> is that an implementation can define the macros specified in the
> standard through invisible #include <standard-header> -> 'std'
> redirection just the same as long as the respective #include
> <standard-header> is present in the source. Or does the "as-if" rule
> not apply here?
>
> The same is clearly no the case with headers (and macros) outside of
> the standard. But then, it's the library developer to provide a module
> manifest (just to give it a name) that lists the library include files
> that a redirection to a BMI can replace. If library developers choose
> to implement some of the library interface through macros then they
> still can by providing a header file that must obviously not be listed
> in the manifest. Users need to opt into such a redirection, sans
> macros of course, and figure out what this means to their own source
> code. Thinking even farther: the manifest could list that library
> header that's providing the macro definitions that are part of the
> library interface, and should implicitly be read during redirection.
>
> I think such a mechanism would actually improve compatibility between
> the #include "lib/header" world and the import lib world because
> there's only one ground truth of all definitions: the BMI, compiled
> once and for all.
>
Some of this discussion reflects features available in Clang modules.

For those that haven't yet, I recommend reading the Clang modules
documentation. Specifically:

  * Module maps <https://clang.llvm.org/docs/Modules.html#module-maps>
  * Module Map Language
    <https://clang.llvm.org/docs/Modules.html#module-map-language>
  * Configuration macros declaration
    <https://clang.llvm.org/docs/Modules.html#configuration-macros-declaration>

These sections cover how multiple headers get associated with a single
module (via submodules) and what macros effect the interface exposed via
a BMI.

Tom.

> Just my thoughts worth of 0.0184 € given current inflation rates.
>
> Ciao
> Dani
>
>> -- Gaby
>>
>> -----Original Message-----
>> From: Daniel Ruoso<daniel_at_[hidden]>
>> Sent: Friday, June 3, 2022 2:01 PM
>> To: Gabriel Dos Reis<gdr_at_[hidden]>
>> Cc:sg15_at_[hidden]
>> Subject: Re: [SG15] "logical name" of importable headers
>>
>> Em sex., 3 de jun. de 2022 às 16:48, Gabriel Dos Reis
>> <gdr_at_[hidden]> escreveu:
>>> Do you see silent semantics change, or a loud compilation break?
>>> Any example?
>> One example is the version macros for specific things, such as
>> #define __cpp_lib_scoped_lock 201703
>> in the mutex header on libstdc++.
>>
>> If that macro is no longer in scope after the code says #include
>> <mutex>, it could silently change behavior if anyone has an #if on
>> that macro.
>>
>> daniel
>> _______________________________________________
>> SG15 mailing list
>> SG15_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
>
> --
> PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15