It would be useful if there was a method of selecting the old
behaviour in the case of a breaking change.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2 March 2015 at 21:29, Douglas Boffey <douglas.boffey@gmail.com> wrote:
> It would be useful if there was a method of selecting the old
> behaviour in the case of a breaking change.


It also has apparent downsides, like making it easier to have partial
implementations.
A new standard replaces an older one, and that is more or less by design.
I don't expect proposals that support such techniques will receive
unanimous support,
and I somewhat expect them to be rejected. Implementations can of course support
such techniques.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

So you're expecting us to waste valuable time searching multi-million
line projects for every breaking change???

On 3/2/15, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> On 2 March 2015 at 21:29, Douglas Boffey <douglas.boffey@gmail.com> wrote:
>> It would be useful if there was a method of selecting the old
>> behaviour in the case of a breaking change.
>
>
> It also has apparent downsides, like making it easier to have partial
> implementations.
> A new standard replaces an older one, and that is more or less by design.
> I don't expect proposals that support such techniques will receive
> unanimous support,
> and I somewhat expect them to be rejected. Implementations can of course
> support
> such techniques.
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--089e011825c0dfe8c405105465b7
Content-Type: text/plain; charset=UTF-8

I think that this proposal should be a matter for compiler vendors.
Retro-compatibility support is certainly nice to have, but I fail to see
why it should be enforced by the standard.

Besides, breaking changes tend to be rejected, IIRC. So how often does this
actually become a problem during the lifetime of a project?

2015-03-02 17:45 GMT-03:00 Douglas Boffey <douglas.boffey@gmail.com>:

> So you're expecting us to waste valuable time searching multi-million
> line projects for every breaking change???
>
> On 3/2/15, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> > On 2 March 2015 at 21:29, Douglas Boffey <douglas.boffey@gmail.com>
> wrote:
> >> It would be useful if there was a method of selecting the old
> >> behaviour in the case of a breaking change.
> >
> >
> > It also has apparent downsides, like making it easier to have partial
> > implementations.
> > A new standard replaces an older one, and that is more or less by design.
> > I don't expect proposals that support such techniques will receive
> > unanimous support,
> > and I somewhat expect them to be rejected. Implementations can of course
> > support
> > such techniques.
> >
> > --
> >
> > ---
> > 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.
> > Visit this group at
> > http://groups.google.com/a/isocpp.org/group/std-proposals/.
> >
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e011825c0dfe8c405105465b7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think that this proposal should be a matter for compiler=
 vendors. Retro-compatibility support is certainly nice to have, but I fail=
 to see why it should be enforced by the standard.<div><br></div><div>Besid=
es, breaking changes tend to be rejected, IIRC. So how often does this actu=
ally become a problem during the lifetime of a project?</div></div><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote">2015-03-02 17:45 GMT-03:0=
0 Douglas Boffey <span dir=3D"ltr">&lt;<a href=3D"mailto:douglas.boffey@gma=
il.com" target=3D"_blank">douglas.boffey@gmail.com</a>&gt;</span>:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">So you&#39;re expecting us to waste valuable time=
 searching multi-million<br>
line projects for every breaking change???<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On 3/2/15, Ville Voutilainen &lt;<a href=3D"mailto:ville.voutilainen@gmail.=
com">ville.voutilainen@gmail.com</a>&gt; wrote:<br>
&gt; On 2 March 2015 at 21:29, Douglas Boffey &lt;<a href=3D"mailto:douglas=
..boffey@gmail.com">douglas.boffey@gmail.com</a>&gt; wrote:<br>
&gt;&gt; It would be useful if there was a method of selecting the old<br>
&gt;&gt; behaviour in the case of a breaking change.<br>
&gt;<br>
&gt;<br>
&gt; It also has apparent downsides, like making it easier to have partial<=
br>
&gt; implementations.<br>
&gt; A new standard replaces an older one, and that is more or less by desi=
gn.<br>
&gt; I don&#39;t expect proposals that support such techniques will receive=
<br>
&gt; unanimous support,<br>
&gt; and I somewhat expect them to be rejected. Implementations can of cour=
se<br>
&gt; support<br>
&gt; such techniques.<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; ---<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups<br>
&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an<br>
&gt; email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std=
-proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at<br>
&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
 target=3D"_blank">http://groups.google.com/a/isocpp.org/group/std-proposal=
s/</a>.<br>
&gt;<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e011825c0dfe8c405105465b7--

.

--001a1139ba9429f02f0510548d5a
Content-Type: text/plain; charset=UTF-8

On 2 March 2015 at 14:45, Douglas Boffey <douglas.boffey@gmail.com> wrote:

> So you're expecting us to waste valuable time searching multi-million
> line projects for every breaking change???
>

Just about *every* change could be a breaking change, due to things like
SFINAE.  How do you plan on limiting the scope?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1139ba9429f02f0510548d5a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 2 March 2015 at 14:45, Douglas Boffey <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:douglas.boffey@gmail.com" target=3D"_blank">douglas.=
boffey@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So you&#39;re expecting=
 us to waste valuable time searching multi-million<br>
line projects for every breaking change???<br></blockquote><div><br></div><=
div>Just about <i>every</i>=C2=A0change could be a breaking change, due to =
things like SFINAE.=C2=A0 How do you plan on limiting the scope?</div></div=
>-- <br><div class=3D"gmail_signature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=
=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">=
nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404</div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1139ba9429f02f0510548d5a--

.

On 2 March 2015 at 22:45, Douglas Boffey <douglas.boffey@gmail.com> wrote:
> So you're expecting us to waste valuable time searching multi-million
> line projects for every breaking change???

I fail to see what you're referring to, or what you're talking about.
I personally
suggested to EWG that in the case of breaking changes, implementations
could be (when requested by a user) encouraged to compile code twice,
first under
the old rules, then under the new rules, and diagnose semantic
differences. I suggested
that as a quality-of-implementation matter, not a requirement for
every implementation.

How does this meta-proposal of yours find breaking changes in those
multi-million line projects?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

It doesn't - it allows us to continue using them.

On 3/2/15, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> On 2 March 2015 at 22:45, Douglas Boffey <douglas.boffey@gmail.com> wrote:
>> So you're expecting us to waste valuable time searching multi-million
>> line projects for every breaking change???
>
> I fail to see what you're referring to, or what you're talking about.
> I personally
> suggested to EWG that in the case of breaking changes, implementations
> could be (when requested by a user) encouraged to compile code twice,
> first under
> the old rules, then under the new rules, and diagnose semantic
> differences. I suggested
> that as a quality-of-implementation matter, not a requirement for
> every implementation.
>
> How does this meta-proposal of yours find breaking changes in those
> multi-million line projects?
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 3 March 2015 at 00:33, Douglas Boffey <douglas.boffey@gmail.com> wrote:
> It doesn't - it allows us to continue using them.

How does it know which things to grok in previous-standard-mode and which to
grok in new-standard-mode? How is it different from telling your implementation
which standard version you want to use?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_4201_928985603.1425345948360
Content-Type: multipart/alternative;
 boundary="----=_Part_4202_935155130.1425345948366"

------=_Part_4202_935155130.1425345948366
Content-Type: text/plain; charset=UTF-8



On Monday, March 2, 2015 at 5:33:40 PM UTC-5, Douglas Boffey wrote:
>
> It doesn't - it allows us to continue using them.
>

I'm trying to understand your reasoning, so feel free to respond with more
than just a sentence or two.

What you want is for the standards committee to publish a standard where
breaking changes are conditional.

Well, a breaking change is one of the following:

A) Old code that was legal is made into an explicit compile error.

B) Old code that was legal remains legal, but resolves to a different
result.

Category A is not a very big problem, since the compiler does all of that
searching-of-a-million-line-codebase stuff for you. Your problem seems to
be Category B: a *silent* breaking change.

OK, so explain a practical issue. How *exactly* would you expect the
compiler to know when it should use the old behavior instead of the new?

If your first thought is "compiler switch", think again. The standard has
no notion of any such thing. The standard defines what a compiler *must do*,
not what it might do given particular switches or somesuch. The standard
cannot define compiler switches or similar options.

Now, compiler switches can, and very often do, implement non-standard
behavior. The most famous being turning off strict aliasing (which is *not
optional* in the spec). So individual compilers can offer
backwards-compatibility switches for such cases.

Most important of all is this. The standards committee does their level
best to *not* introduce breaking changes. And when they do, they do their
best to avoid introducing *silent* breaking changes. The number of these
cases is quite small (just check the C++11/14 standards). So if they do
introduce such a change, there is more often than not, a pretty good reason
why.

Which means that people are probably going to be relying on the new
behavior. Lots of people are going to be writing code that expects the new
behavior. Programmers are going to be *taught* the new behavior.

So what are you going to do, a few years down the line, when quite a few
programmers don't even remember what the old behavior even was?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_4202_935155130.1425345948366
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, March 2, 2015 at 5:33:40 PM UTC-5, Doug=
las Boffey wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">It doesn't - =
it allows us to continue using them.
<br></blockquote><div><br>I'm trying to understand your reasoning, so feel =
free to respond with more than just a sentence or two.<br><br>What you want=
 is for the standards committee to publish a standard where breaking change=
s are conditional.<br><br>Well, a breaking change is one of the following:<=
br><br>A) Old code that was legal is made into an explicit compile error.<b=
r><br>B) Old code that was legal remains legal, but resolves to a different=
 result.<br><br>Category A is not a very big problem, since the compiler do=
es all of that searching-of-a-million-line-codebase stuff for you. Your pro=
blem seems to be Category B: a <i>silent</i> breaking change.<br><br>OK, so=
 explain a practical issue. How <i>exactly</i> would you expect the compile=
r to know when it should use the old behavior instead of the new?<br><br>If=
 your first thought is "compiler switch", think again. The standard has no =
notion of any such thing. The standard defines what a compiler <i>must do</=
i>, not what it might do given particular switches or somesuch. The standar=
d cannot define compiler switches or similar options.<br><br>Now, compiler =
switches can, and very often do, implement non-standard behavior. The most =
famous being turning off strict aliasing (which is <i>not optional</i> in t=
he spec). So individual compilers can offer backwards-compatibility switche=
s for such cases.<br><br>Most important of all is this. The standards commi=
ttee does their level best to <i>not</i> introduce breaking changes. And wh=
en they do, they do their best to avoid introducing <i>silent</i> breaking =
changes. The number of these cases is quite small (just check the C++11/14 =
standards). So if they do introduce such a change, there is more often than=
 not, a pretty good reason why.<br><br>Which means that people are probably=
 going to be relying on the new behavior. Lots of people are going to be wr=
iting code that expects the new behavior. Programmers are going to be <i>ta=
ught</i> the new behavior.<br><br>So what are you going to do, a few years =
down the line, when quite a few programmers don't even remember what the ol=
d behavior even was?<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4202_935155130.1425345948366--
------=_Part_4201_928985603.1425345948360--

.

------=_Part_328_1326560106.1425383905915
Content-Type: multipart/alternative;
 boundary="----=_Part_329_320478388.1425383905915"

------=_Part_329_320478388.1425383905915
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Tuesday, 3 March 2015 01:25:48 UTC, Nicol Bolas wrote:=20
>
>
>
> On Monday, March 2, 2015 at 5:33:40 PM UTC-5, Douglas Boffey wrote:=20
>>
>> It doesn't - it allows us to continue using them.=20
>>
>
> I'm trying to understand your reasoning, so feel free to respond with mor=
e=20
> than just a sentence or two.
>
> My apologies=E2=80=94my mobile will only allow messages of 120 characters=
 (max). :(
=20

>  What you want is for the standards committee to publish a standard where=
=20
> breaking changes are conditional.
>
> Well, a breaking change is one of the following:
>
> A) Old code that was legal is made into an explicit compile error.
>
> B) Old code that was legal remains legal, but resolves to a different=20
> result.
>
> Category A is not a very big problem, since the compiler does all of that=
=20
> searching-of-a-million-line-codebase stuff for you. Your problem seems to=
=20
> be Category B: a *silent* breaking change.
>
> OK, so explain a practical issue. How *exactly* would you expect the=20
> compiler to know when it should use the old behavior instead of the new?
>
> If your first thought is "compiler switch", think again. The standard has=
=20
> no notion of any such thing. The standard defines what a compiler *must=
=20
> do*, not what it might do given particular switches or somesuch. The=20
> standard cannot define compiler switches or similar options.
>
A compiler switch, such as -std=3Dc++11, is, IMO, too coarse grained.  If a=
=20
file written in C++14, for example, #includes a file written in C++98, it=
=20
would be desireable for the compiler to use the different rulesets for the=
=20
different files, not for the different TUs.
=20
My initial thought would be to prepend each file with a pragma giving the=
=20
version it is written in, but I am open to ideas.
=20

> =20
> Now, compiler switches can, and very often do, implement non-standard=20
> behavior. The most famous being turning off strict aliasing (which is *no=
t=20
> optional* in the spec). So individual compilers can offer=20
> backwards-compatibility switches for such cases.
>
> Most important of all is this. The standards committee does their level=
=20
> best to *not* introduce breaking changes. And when they do, they do their=
=20
> best to avoid introducing *silent* breaking changes. The number of these=
=20
> cases is quite small (just check the C++11/14 standards). So if they do=
=20
> introduce such a change, there is more often than not, a pretty good reas=
on=20
> why.
>
> True, there are few breaking changes, and even fewer silent breaking=20
changes, but they are not altogether absent.  My initial thoughts reach=20
back to the change of use of the =E2=80=98auto=E2=80=99 keyword in C++11.
=20

>  Which means that people are probably going to be relying on the new=20
> behavior. Lots of people are going to be writing code that expects the ne=
w=20
> behavior. Programmers are going to be *taught* the new behavior.
>
> True, but I would only expect this for legacy code.
=20

>  So what are you going to do, a few years down the line, when quite a few=
=20
> programmers don't even remember what the old behavior even was?
>
It may be that a conforming implementation should only be required to=20
recognise one or two generations of standards, by which time, the code base=
=20
should, hopefully, have been updated.
=20
I hope this is enough flesh on the bones to get a better idea of my=20
intentions.  If not, I would be delighted to elaborate.
=20

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_329_320478388.1425383905915
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><BR>On Tuesday, 3 March 2015 01:25:48 UTC, Nicol Bolas wro=
te:=20
<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>
<DIV dir=3Dltr><BR><BR>On Monday, March 2, 2015 at 5:33:40 PM UTC-5, Dougla=
s Boffey wrote:=20
<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>It doesn't - it allows us to conti=
nue using them. <BR></BLOCKQUOTE>
<DIV><BR>I'm trying to understand your reasoning, so feel free to respond w=
ith more than just a sentence or two.<BR><BR></DIV></DIV></BLOCKQUOTE>
<DIV>My apologies=E2=80=94my mobile will only allow messages of 120 charact=
ers (max). :(</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>
<DIV dir=3Dltr>
<DIV>What you want is for the standards committee to publish a standard whe=
re breaking changes are conditional.<BR><BR>Well, a breaking change is one =
of the following:<BR><BR>A) Old code that was legal is made into an explici=
t compile error.<BR><BR>B) Old code that was legal remains legal, but resol=
ves to a different result.<BR><BR>Category A is not a very big problem, sin=
ce the compiler does all of that searching-of-a-million-line-<WBR>codebase =
stuff for you. Your problem seems to be Category B: a <I>silent</I> breakin=
g change.<BR><BR>OK, so explain a practical issue. How <I>exactly</I> would=
 you expect the compiler to know when it should use the old behavior instea=
d of the new?<BR><BR>If your first thought is "compiler switch", think agai=
n. The standard has no notion of any such thing. The standard defines what =
a compiler <I>must do</I>, not what it might do given particular switches o=
r somesuch. The standard cannot define compiler switches or similar options=
..<BR></DIV></DIV></BLOCKQUOTE>
<DIV>A compiler switch, such as -std=3Dc++11, is, IMO, too coarse grained.&=
nbsp; If a file written in C++14, for example, #includes a file written in =
C++98, it would be desireable for the compiler to use the different ruleset=
s for the different files, not for the different TUs.</DIV>
<DIV>&nbsp;</DIV>
<DIV>My initial thought would be to prepend each file with a pragma giving =
the version it is written in, but I am open to ideas.</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>
<DIV dir=3Dltr>
<DIV><BR>Now, compiler switches can, and very often do, implement non-stand=
ard behavior. The most famous being turning off strict aliasing (which is <=
I>not optional</I> in the spec). So individual compilers can offer backward=
s-compatibility switches for such cases.<BR><BR>Most important of all is th=
is. The standards committee does their level best to <I>not</I> introduce b=
reaking changes. And when they do, they do their best to avoid introducing =
<I>silent</I> breaking changes. The number of these cases is quite small (j=
ust check the C++11/14 standards). So if they do introduce such a change, t=
here is more often than not, a pretty good reason why.<BR><BR></DIV></DIV><=
/BLOCKQUOTE>
<DIV>True, there are few breaking changes, and even fewer silent breaking c=
hanges, but they are not altogether absent.&nbsp; My initial thoughts reach=
 back to the change of use of the =E2=80=98auto=E2=80=99 keyword in C++11.<=
/DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>
<DIV dir=3Dltr>
<DIV>Which means that people are probably going to be relying on the new be=
havior. Lots of people are going to be writing code that expects the new be=
havior. Programmers are going to be <I>taught</I> the new behavior.<BR><BR>=
</DIV></DIV></BLOCKQUOTE>
<DIV>True, but I would only expect this for legacy code.</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>
<DIV dir=3Dltr>
<DIV>So what are you going to do, a few years down the line, when quite a f=
ew programmers don't even remember what the old behavior even was?<BR></DIV=
></DIV></BLOCKQUOTE>
<DIV>It may be that a conforming implementation should only be required to =
recognise one or two generations of standards, by which time, the code base=
 should, hopefully, have been updated.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I hope this is enough flesh on the bones to get a better idea of my in=
tentions.&nbsp; If not, I would be delighted to elaborate.</DIV>
<DIV>&nbsp;</DIV></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_329_320478388.1425383905915--
------=_Part_328_1326560106.1425383905915--

.

> I fail to see what you're referring to, or what you're talking about.
> I personally suggested to EWG that in the case of breaking changes,
> implementations could be (when requested by a user) encouraged
> to compile code twice,

I guess that OP means something like that:

    using standard C++2047 {
    /* Here goes which uses some features from year 2047's
       standard, which is not backward-compatible to the
       previous standards. Within that block any possible
       breaking changes can be used. If the compiler is
       not that new, it must flag an error. If compiler
       is new and can handle newer standards (say, C++2051
       and C++2073), it degrades to the requested one. */
    }

    /* Default compatibility settings, as for C++14. */

=E2=80=94=E2=80=94=E2=80=94 Pavel Kretov.

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 3 March 2015 at 14:33, Pavel Kretov <firegurafiku@gmail.com> wrote:
>> I fail to see what you're referring to, or what you're talking about.
>> I personally suggested to EWG that in the case of breaking changes,
>> implementations could be (when requested by a user) encouraged
>> to compile code twice,
>
> I guess that OP means something like that:
>
>     using standard C++2047 {
>     /* Here goes which uses some features from year 2047's
>        standard, which is not backward-compatible to the
>        previous standards. Within that block any possible
>        breaking changes can be used. If the compiler is
>        not that new, it must flag an error. If compiler
>        is new and can handle newer standards (say, C++2051
>        and C++2073), it degrades to the requested one. */
>     }
>
>     /* Default compatibility settings, as for C++14. */

This particular solution hasn't ever been formally proposed as far as
I can remember,
but when the idea was floated the last time, it was summarily
rejected. Proposing
something like that will very likely be an uphill battle, due to the
motivation/cost
ratio.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Tuesday 03 March 2015 03:58:25 Douglas Boffey wrote:
> It may be that a conforming implementation should only be required to
> recognise one or two generations of standards, by which time, the code base
> should, hopefully, have been updated.
>
> I hope this is enough flesh on the bones to get a better idea of my
> intentions.  If not, I would be delighted to elaborate.

I think it's clear, but I don't see why this needs to be in the standard. It
can simply be a compiler extension, like the -std=c++0x and -std=c++1y options
were.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

As I said, I consider compiler flags too course grained.

On 3/3/15, Thiago Macieira <thiago@macieira.org> wrote:
> On Tuesday 03 March 2015 03:58:25 Douglas Boffey wrote:
>> It may be that a conforming implementation should only be required to
>> recognise one or two generations of standards, by which time, the code
>> base
>> should, hopefully, have been updated.
>>
>> I hope this is enough flesh on the bones to get a better idea of my
>> intentions.  If not, I would be delighted to elaborate.
>
> I think it's clear, but I don't see why this needs to be in the standard. It
>
> can simply be a compiler extension, like the -std=c++0x and -std=c++1y
> options
> were.
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Tuesday 03 March 2015 16:58:12 Douglas Boffey wrote:
> As I said, I consider compiler flags too course grained.
>
> On 3/3/15, Thiago Macieira <thiago@macieira.org> wrote:
> > On Tuesday 03 March 2015 03:58:25 Douglas Boffey wrote:
> >> It may be that a conforming implementation should only be required to
> >> recognise one or two generations of standards, by which time, the code
> >> base
> >> should, hopefully, have been updated.
> >>
> >> I hope this is enough flesh on the bones to get a better idea of my
> >> intentions.  If not, I would be delighted to elaborate.
> >
> > I think it's clear, but I don't see why this needs to be in the standard.
> > It
> >
> > can simply be a compiler extension, like the -std=c++0x and -std=c++1y
> > options
> > were.

I didn't say they had to be compiler flags. I said they should be compiler
extensions, just like compiler flags like the ones I mentioned are compiler
extensions too.

So, for example:

#pragma GCC std push
#pragma GCC std "c++14"
.....
#pragma GCC std pop

The above syntax already works for the -W flags (pragma GCC diagnostic) and the
optimisation flags (pragma GCC optimize).

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_5697_1915513192.1425432526392
Content-Type: multipart/alternative;
 boundary="----=_Part_5698_1102865767.1425432526392"

------=_Part_5698_1102865767.1425432526392
Content-Type: text/plain; charset=UTF-8



On Tuesday, March 3, 2015 at 6:58:26 AM UTC-5, Douglas Boffey wrote:
>
> My initial thought would be to prepend each file with a pragma giving the
> version it is written in, but I am open to ideas.
>

Pragmas are not standard. They are a standard-defined mechanism that allows
you to pass what are effectively compile-time switches. But the standard
does not (and can't really) define what they do. Even things like #pragma
once are handled by general agreement among the compiler developers, not by
any standards process.

Even if that weren't an issue, the standard doesn't know what a "file" is.
It doesn't have that concept; all it sees are "translation units". So your
suggestion is more or less unworkable from outside of the file.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_5698_1102865767.1425432526392
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, March 3, 2015 at 6:58:26 AM UTC-5, Dou=
glas Boffey wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">My initial thought would be to prepend each file with a pragma giving =
the version it is written in, but I am open to ideas.
</div></blockquote><div><br>Pragmas are not standard. They are a standard-d=
efined mechanism that allows you to pass what are effectively compile-time =
switches. But the standard does not (and can't really) define what they do.=
 Even things like #pragma once are handled by general agreement among the c=
ompiler developers, not by any standards process.<br><br>Even if that weren=
't an issue, the standard doesn't know what a "file" is. It doesn't have th=
at concept; all it sees are "translation units". So your suggestion is more=
 or less unworkable from outside of the file.</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5698_1102865767.1425432526392--
------=_Part_5697_1915513192.1425432526392--

.

------=_Part_903_1499772894.1425664816853
Content-Type: multipart/alternative;
 boundary="----=_Part_904_1667464619.1425664816854"

------=_Part_904_1667464619.1425664816854
Content-Type: text/plain; charset=UTF-8

On Tuesday, March 3, 2015 at 8:42:48 AM UTC-8, Thiago Macieira wrote:
>
>
> I think it's clear, but I don't see why this needs to be in the standard.
> It
> can simply be a compiler extension, like the -std=c++0x and -std=c++1y
> options
> were.
>

This was something I thought about quite a bit in the past, but abandoned
because of an issue I'll mention in a moment.

The approach I was thinking of was a way to change the "language mode" of
the compiler. The C++ standard would only define one language mode and
leave it as an implementation option to offer other language modes. These
might be old versions of C++. These might be other languages like C or
Objective-C or Assembler or Fortran or whatever. Up to the implementation.
And of course with a feature detection macro to know if the language mode
is supported by the implementation. Since just about every C++ compiler
vendor already keeps back-compat for older versions, not to mention C, it
seems likely that it would be a common feature to support those, but a new
implementation should be required to implement multiple 1,300 page
specifications (including the standard library, remember!) of course.

And that's where it gets tricky. Standard library incompatibilities. Not
just in C++, but the other language modes, too.

And then macros. What happens if you define a macro in some C++98 code that
uses the 'auto' keyword for its old purpose or whatnot and then try to
expand that in a C++14 context?

And template instantiation contexts; what if the rules drastically change
there because we're "free" to break things, and then the way an old
template is meant to instantiate no longer works in newer contexts?

Revisiting the idea, I noticed that the biggest issue (in my book, anyway)
tends to be keywords. Having to pick things like 'decltype' instead of
'typeof' and so on. A more focused thought experiment/proposals that just
focuses on keywords across versions might be more practical.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_904_1667464619.1425664816854
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, March 3, 2015 at 8:42:48 AM UTC-8, Thiago Maci=
eira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>I think it's cl=
ear, but I don't see why this needs to be in the standard. It=20
<br>can simply be a compiler extension, like the -std=3Dc++0x and -std=3Dc+=
+1y options=20
<br>were.
<br></blockquote><div><br></div><div>This was something I thought about qui=
te a bit in the past, but abandoned because of an issue I'll mention in a m=
oment.</div><div><br></div><div>The approach I was thinking of was a way to=
 change the "language mode" of the compiler. The C++ standard would only de=
fine one language mode and leave it as an implementation option to offer ot=
her language modes. These might be old versions of C++. These might be othe=
r languages like C or Objective-C or Assembler or Fortran or whatever. Up t=
o the implementation. And of course with a feature detection macro to know =
if the language mode is supported by the implementation. Since just about e=
very C++ compiler vendor already keeps back-compat for older versions, not =
to mention C, it seems likely that it would be a common feature to support =
those, but a new implementation should be required to implement multiple 1,=
300 page specifications (including the standard library, remember!) of cour=
se.</div><div><br></div><div>And that's where it gets tricky. Standard libr=
ary incompatibilities. Not just in C++, but the other language modes, too.<=
/div><div><br></div><div>And then macros. What happens if you define a macr=
o in some C++98 code that uses the 'auto' keyword for its old purpose or wh=
atnot and then try to expand that in a C++14 context?</div><div><br></div><=
div>And template instantiation contexts; what if the rules drastically chan=
ge there because we're "free" to break things, and then the way an old temp=
late is meant to instantiate no longer works in newer contexts?</div><div><=
br></div><div>Revisiting the idea, I noticed that the biggest issue (in my =
book, anyway) tends to be keywords. Having to pick things like 'decltype' i=
nstead of 'typeof' and so on. A more focused thought experiment/proposals t=
hat just focuses on keywords across versions might be more practical.</div>=
</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_904_1667464619.1425664816854--
------=_Part_903_1499772894.1425664816853--

.

On Friday 06 March 2015 10:00:16 Sean Middleditch wrote:
> And that's where it gets tricky. Standard library incompatibilities. Not
> just in C++, but the other language modes, too.
>
> And then macros. What happens if you define a macro in some C++98 code that
> uses the 'auto' keyword for its old purpose or whatnot and then try to
> expand that in a C++14 context?
>
> And template instantiation contexts; what if the rules drastically change
> there because we're "free" to break things, and then the way an old
> template is meant to instantiate no longer works in newer contexts?
>
> Revisiting the idea, I noticed that the biggest issue (in my book, anyway)
> tends to be keywords. Having to pick things like 'decltype' instead of
> 'typeof' and so on. A more focused thought experiment/proposals that just
> focuses on keywords across versions might be more practical.

Agreed, those problems are rather difficult to solve.

The only thing that would make sense would be to have this close to the top of
the file, which would declare what language it is in. This way, I could mix
files from different languages and let the compiler determine how to parse it on
its own.

While we're at it, it would be nice to specify the source character encoding.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.