> One of the SG10 guidelines is that feature test macros are generally only > needed if the programmer would write the code in two different ways depending > on the setting of the macro.
If the feature test macro is useful in a static_assert, I can see it being somewhat useful, but I don't know that that is currently an SG10 guideline. Regardless, if someone wants a feature test macro, I would like to see example code that demonstrates such use. A 60 second attempt on my part to come up with a static_assert for this macro didn't yield anything that would be useful. If re-ordering were permitted, then there could be a macro that is 0 when reordering is on, and something else when reordering is off, and not-present would be left non-portable. That's not the pitch though. ________________________________ From: SG10 <[email protected]> on behalf of John Spicer via SG10 <[email protected]> Sent: Sunday, November 1, 2020 10:08 AM To: Ville Voutilainen via SG10 <[email protected]> Cc: John Spicer <[email protected]> Subject: [EXTERNAL] Re: [SG10] P1847 Make declaration order layout mandated Having a feature test macro for this seems to be of limited usability. If the macro existed, EDG would probably use our configuration parameter (mentioned in the paper) to control the setting of the macro. But a user of the macro would probably have to assume that the macro not existing (as would be the case for pre-C++23 compilers) means that the order is the one expected by the paper. So if some older compiler did not use the expected layout, the macro wouldn’t help. One of the SG10 guidelines is that feature test macros are generally only needed if the programmer would write the code in two different ways depending on the setting of the macro. So, it doesn’t seem that helpful to me, but I have no objection to adding a macro for this if there is sufficient interest in doing so. John. On Nov 1, 2020, at 10:25 AM, Barry Revzin via SG10 <[email protected]<mailto:[email protected]>> wrote: Hi SG10, On Thu, Oct 29, 2020 at 7:05 AM Balog Pal via SG10 <[email protected]<mailto:[email protected]>> wrote: I asked guidance after the last meeting. I did not get a reply back then and concluded it as confirming the idea to NOT have the macro. If someone thinks it is needed after all, please say so. http://open-std.org/JTC1/SC22/WG21/docs/papers/2020/p1847r3.pdf<https://urldefense.com/v3/__http://open-std.org/JTC1/SC22/WG21/docs/papers/2020/p1847r3.pdf__;!!FbZ0ZwI3Qg!8coLj4r3m9uI_EA5hPolvKpSNn4z4A2Pcb8E4A-CykYcM8f3QSgSjqQ_xHGW$> I'd like to see some response to this question. It's kind of a novel one, as far as I can tell. Usually, we don't add feature-test macros where the motivation is to mandate the existence of the feature. As was described here: [Balog]: > I have one use case in mind. In my projects I usually have a > configuration/environments checking headers, that looks for compiler, > language version and platform attributes, with #error if anything is > not as expected. Especially for things that were assumed and built on. > > The paper imposes a strict and reliable order of members, that is not > unreasonable to assume. And that is easier to check with a related > than a more generic one. > > OTOH my argument in the was that no one is actually swapping. > > I'm not in live with the macro and happy to remove it, please make a > verdict before the postmailing deadline. And we typically don't add such a macro because for nearly all features, if you simply use the feature, that's mandating its existence, and a compiler that doesn't implement it will just error already. But in this case, "using" the feature doesn't change any code -- it just changes the code gen. On the other hand, as he points out, all the implementations already seem to implement this feature. Does anybody have an opinion on whether we should or should not have a macro for this feature? Barry -- SG10 mailing list [email protected]<mailto:[email protected]> https://lists.isocpp.org/mailman/listinfo.cgi/sg10<https://urldefense.com/v3/__https://lists.isocpp.org/mailman/listinfo.cgi/sg10__;!!FbZ0ZwI3Qg!8coLj4r3m9uI_EA5hPolvKpSNn4z4A2Pcb8E4A-CykYcM8f3QSgSjv-uAWcE$>
-- SG10 mailing list [email protected] https://lists.isocpp.org/mailman/listinfo.cgi/sg10
