On 2016-02-20 17:11, Ville Voutilainen wrote:
> On 20 February 2016 at 23:59, Sean Middleditch wrote:
>> I'd be way more okay with p0138 for example if anyone wanting the
>> feature had to declare `using experimental::p138r1;` in any scopes
>> utilizing the syntax change.
>
> Changing the language dialect per-namespace or via some other such
> mechanics has been floated as an idea, but never proposed. The response
> to such ideas was not welcoming.
>
>> Basically, I really really like HTML5's or Rust's per-feature opt-in
>> mechanism for experiemental/"unstable" evolutions... that approach
>> makes it a lot safer to quickly evolve and gather wide implementation
>> and user feedback without getting stuck with insufficiently
>> battle-tested designs. Far more so than the very coarse-grained "all
>
> Or python's "from __future__ import". Such mechanisms don't work all
> that well for getting wide user feedback, actually. And I somewhat doubt
> they work all that much better than using a -std=c++1z, coarse as that
> is. And hey, you can always use -std=c++1z on a per-file basis. I know,
> it has its problems.

If C++ were to have a something like an official "staging area" for
language features (i.e. something like a TS for language features),
compiler vendors could offer an option to turn on or off those features,
as is done for language level selection.

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
functional thing to appear in the TU. (Comments could be allowed, but
absolutely no meaningful C++, and possibly no (other) preprocessor either.)

--
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/nafahm%24gia%241%40ger.gmane.org.

.

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?

You pretty much need scopes to be involved at some point to work
around the textual inclusion behavior of preprocessor includes and
macro expansions. Legacy support strikes again. :)

If this discussion is going to continue, maybe we should start a new
thread for the new topic?

> functional thing to appear in the TU. (Comments could be allowed, but
> absolutely no meaningful C++, and possibly no (other) preprocessor either.)
>
> --
> Matthew
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/C9dRIVwxTZ0/unsubscribe.
> To unsubscribe from this group and all its topics, 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/nafahm%24gia%241%40ger.gmane.org.



--
Sean Middleditch
http://seanmiddleditch.com

--
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/CALQmNFjBqvFissFPHc%2BiHh%2BEEuiD4BT%2BFKGP0oA_1NMHBfkGCA%40mail.gmail.com.

.

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?
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?

When you opt in to language features, you need to ensure that the headers you
include are compatible. We had to fix libdbus-1 headers (a C library) because C
++11 changed the concatenation of string literals when one of them is behind a
macro.

--
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/15494100.dR7e8Tc6eJ%40tjmaciei-mobl4.

.