On 2016-02-22 11:35, Sean Middleditch wrote:
> On Mon, Feb 22, 2016 at 7:47 AM, Matthew Woehlke
> <mwoehlke.floss@gmail.com> wrote:
>> One easy way to do so at the file level would be if vendors implemented
>> something like a `#pragma language CPP17_EXT` that is allowed to appear
>> at the beginning of a TU. This seems at least vaguely plausible, and
>> wouldn't cause any scoping issues because it must be the first
>
> I'd thought of that one a lot over the last couple of years, but I'm
> pretty sure the preprocessor and headers will be the problem there.
> What happens if a header I include isn't compatible with the language
> mode I declare?

Too bad. (Fix it?) The idea is that the effect is the same as setting
the language level as a CLI flag when invoking the compiler, just
without having to muck about with the build system to do so.

Trying to toggle the language level for *portions* of a TU is likely to
be much harder to implement. As such, my idea does not try to solve this.

Note that I intentionally make it an error to change the language level
after text whose meaning could be affected has been processed.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nafdpo%24a49%241%40ger.gmane.org.

.

On 2016-02-22 13:41, Thiago Macieira wrote:
> On segunda-feira, 22 de fevereiro de 2016 08:35:47 PST Sean Middleditch wrote:
>> I'd thought of that one a lot over the last couple of years, but I'm
>> pretty sure the preprocessor and headers will be the problem there.
>> What happens if a header I include isn't compatible with the language
>> mode I declare?
>
> What happens if you include a header that uses auto in the old, C++98 meaning?

The same as if you try to build a source file that includes such a
header with -std=c++11 (or with non-ancient MSVC).

> What happens if you include a header that assumes a narrowing conversion is
> permitted in array initialisation? What happens if you include a C header that
> uses new or class as identifiers?

Same thing.

No *new* problems are created by my suggestion. The only difference is
that the language level annotation is in the source file rather than the
build system.

Being able to change the language level dynamically (e.g. for certain
scopes, or whatever) is better, sure. I never said otherwise. However,
I'm not convinced that it can be *done* readily.

Maybe I'm wrong about that? Let me rephrase the original suggestion: the
compiler is *permitted but not required* to reject such a request if
anything non-trivial has preceded the request. If it's easy for the
compiler to support dynamic switching, fine. If it's hard, well, the
compiler's allowed to refuse.

Anyway, you're focusing on the wrong part of the suggestion. The
*important* features/issues are:

1. Does there exist something TS-like for language features?
2. Can this be enabled / disabled using a source directive (as opposed
to a compiler flag)?

Without #1, this entire conversation is moot. #2 is nice to have but not
critical to #1. You're talking about something *almost* entirely orthogonal.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nafoni%24glq%241%40ger.gmane.org.

.

Am 22.02.2016 um 20:49 schrieb Matthew Woehlke:
> On 2016-02-22 13:41, Thiago Macieira wrote:
>> On segunda-feira, 22 de fevereiro de 2016 08:35:47 PST Sean Middleditch wrote:
>>> I'd thought of that one a lot over the last couple of years, but I'm
>>> pretty sure the preprocessor and headers will be the problem there.
>>> What happens if a header I include isn't compatible with the language
>>> mode I declare?
>> What happens if you include a header that uses auto in the old, C++98 meaning?
> The same as if you try to build a source file that includes such a
> header with -std=c++11 (or with non-ancient MSVC).
>
>> What happens if you include a header that assumes a narrowing conversion is
>> permitted in array initialisation? What happens if you include a C header that
>> uses new or class as identifiers?
> Same thing.
>
> No *new* problems are created by my suggestion. The only difference is
> that the language level annotation is in the source file rather than the
> build system.
>
> Being able to change the language level dynamically (e.g. for certain
> scopes, or whatever) is better, sure. I never said otherwise. However,
> I'm not convinced that it can be *done* readily.
>
> Maybe I'm wrong about that? Let me rephrase the original suggestion: the
> compiler is *permitted but not required* to reject such a request if
> anything non-trivial has preceded the request. If it's easy for the
> compiler to support dynamic switching, fine. If it's hard, well, the
> compiler's allowed to refuse.
>
> Anyway, you're focusing on the wrong part of the suggestion. The
> *important* features/issues are:
>
> 1. Does there exist something TS-like for language features?
> 2. Can this be enabled / disabled using a source directive (as opposed
> to a compiler flag)?
>
> Without #1, this entire conversation is moot. #2 is nice to have but not
> critical to #1. You're talking about something *almost* entirely orthogonal.
>
For what it's worth GLSL has preprocessor directives to control
non-standard extensions via

#extension EXT_something : enable
#extension EXT_something : require
#extension EXT_something : warn
#extension EXT_something : disable

at the top of a file. It controls the availability of language features
or additional library functions, see page 16 of
https://www.opengl.org/registry/doc/GLSLangSpec.4.50.pdf for details.
Maybe what Sean is looking for is something like this, but with the
ability to apply it to only a section of a translation unit with
#begin/#end, #push/#pop etc.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/56CB7618.9050603%40gmail.com.

.

On segunda-feira, 22 de fevereiro de 2016 14:49:06 PST Matthew Woehlke wrote:
> Being able to change the language level dynamically (e.g. for certain
> scopes, or whatever) is better, sure. I never said otherwise. However,
> I'm not convinced that it can be *done* readily.

I don't think it can be easily implemented in compilers. That also clashes
with SD-6 [1] / P0061 [2], which has preprocessor macros defined for features
available from the compiler. Having those macros be defined / undefined is
asking for trouble.

Precedent: GCC doesn't set __SSE3__ if you do:

#pragma GCC target("sse3")


[1] https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0061r1.html

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7211759.mjZ8eJ3YJ1%40tjmaciei-mobl4.

.