On Sunday, 27 November 2022 12:38:16 PST Mehmet Kayaalp wrote:
> > You're not addressing any of the comments of the problems with having such
> > a
> > pragma.
>
> Thiago, would you please remind me which problems that were raised I did
> not address?
> Thanks,
> --mehmet kayaalp

See Arthur's email about syntaxes changing.

It seems to me that you have a solution in search of a problem to solve.

Please invert your thinking and start by describing *why* we must have a
language choice. For example, you want to deprecate some features -- why?
What's the harm in them remaining present? Don't talk about cognitive load
unless the feature must be used and understood, not just something that
happens to be there that people have mostly forgotten about. What does
removing the feature enable?

Then make an overview of what granularity a language choice is useful for. Is
it per translation unit? Or per block? How about per library/module?

After you've shown conclusively that the choice per translation unit is viable
and useful, describe what choices exist. We can already configure in the
compiler's command-line, so what's the benefit of having it inside the
translation unit itself?

And only after you've concluded that, present the options for what that should
look like. This is the point where you introduce #pragma, but you should
consider other choices too. You should also address possible drawbacks. For
example: what happens to code above/before the #pragma?


As a library writer, I'm NOT AT ALL interested in this. My libraries must work
with whatever the user chose, provided they are above the minimum that my
libraries were coded for. Therefore, my code must adapt to whatever the user
choice and I already have the tools I need to know what that choice was: the
value in __cplusplus, the __cpp core language and library macros, and
__has_include.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering