------=_Part_163_27773442.1369204277865
Content-Type: text/plain; charset=ISO-8859-1


Hello,

Can anyone point me to the discussion on "why not defining new keywords as
'real' keywords"?

For example, why can 'final' be used as a variable?
Surely it causes problems:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3539.html#1318


Ran.

--

---
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/?hl=en.



------=_Part_163_27773442.1369204277865
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div><div><br></div><div>Hello,</div><div><br></div><div>Can anyone point m=
e to the discussion on "why not defining new keywords as 'real' keywords"?<=
/div><div><br></div><div>For example, why can 'final' be used as a variable=
?</div><div>Surely it causes problems:</div><div>http://www.open-std.org/jt=
c1/sc22/wg21/docs/papers/2013/n3539.html#1318</div><div><br></div><div><br>=
</div><div>Ran.</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_163_27773442.1369204277865--

.

On Tue, May 21, 2013 at 11:31 PM, Ran Regev <regev.ran@gmail.com> wrote:
>
> Hello,
>
> Can anyone point me to the discussion on "why not defining new keywords as
> 'real' keywords"?

It's discussed with almost horrible frequency, but mostly not in
writing in public forums I'd guess.

The short version: it breaks existing code that uses them as
identifiers, and the C++ committee is (believe it or not) somewhat
strongly averse to breaking existing working code.

(Personally I'd prefer to add more keywords; fixing up the resulting
problems is worthwhile in my opinion.)

> For example, why can 'final' be used as a variable?
> Surely it causes problems:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3539.html#1318

Breaking all of the code that uses "final" as an identifier would also
cause problems.  As with almost all things, it's a trade-off, not a
good vs bad decision.  (In my limited checks, there are actually far
more uses of "override" than "final", but both are used somewhat
frequently in real C++98 code.)

In this particular case, there was pre-existing experience from
C++/CLI that using contextual keywords for these was workable -- and
the C++ committee does give some weight to implementation/usage
experience.

You might notice that the keywords added in C++11 are often rather
obscure: e.g., "nullptr" instead of "null".  A significant part of the
reason for that is to avoid clashes with existing code.

-- James

--

---
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/?hl=en.



.

------=_Part_505_4495646.1369304997834
Content-Type: text/plain; charset=ISO-8859-1


Thanks for the answer, backward compatibility was my initial guess.
I have two following questions:
1) Is it only me or that everyone must fix something when advancing a
compiler?
And if I'm not the only one, then what does it matter if we need to fix X
issues or X + 3?

2) How do c++ editors color the new keywords? Do they try to understand the
meaning of the words and color it accordingly, or ??

Ran.

On Wednesday, May 22, 2013 9:52:21 AM UTC+3, James Dennett wrote:
>
> On Tue, May 21, 2013 at 11:31 PM, Ran Regev <rege...@gmail.com<javascript:>>
> wrote:
> >
> > Hello,
> >
> > Can anyone point me to the discussion on "why not defining new keywords
> as
> > 'real' keywords"?
>
> It's discussed with almost horrible frequency, but mostly not in
> writing in public forums I'd guess.
>
> The short version: it breaks existing code that uses them as
> identifiers, and the C++ committee is (believe it or not) somewhat
> strongly averse to breaking existing working code.
>
> (Personally I'd prefer to add more keywords; fixing up the resulting
> problems is worthwhile in my opinion.)
>
> > For example, why can 'final' be used as a variable?
> > Surely it causes problems:
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3539.html#1318
>
> Breaking all of the code that uses "final" as an identifier would also
> cause problems.  As with almost all things, it's a trade-off, not a
> good vs bad decision.  (In my limited checks, there are actually far
> more uses of "override" than "final", but both are used somewhat
> frequently in real C++98 code.)
>
> In this particular case, there was pre-existing experience from
> C++/CLI that using contextual keywords for these was workable -- and
> the C++ committee does give some weight to implementation/usage
> experience.
>
> You might notice that the keywords added in C++11 are often rather
> obscure: e.g., "nullptr" instead of "null".  A significant part of the
> reason for that is to avoid clashes with existing code.
>
> -- James
>

--

---
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/?hl=en.



------=_Part_505_4495646.1369304997834
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div><br></div><div><div>Thanks for the answer, backward compatibility was =
my initial guess.</div><div>I have two following questions:</div><div>1) Is=
 it only me or that everyone must fix something when advancing a compiler?<=
/div><div>And if I'm not the only one, then what does it matter if we need =
to fix X issues or X + 3?</div><div><br></div><div>2) How do c++ editors co=
lor the new keywords? Do they try to understand the meaning of the words an=
d color it accordingly, or ??</div><div><br></div><div>Ran.</div><br>On Wed=
nesday, May 22, 2013 9:52:21 AM UTC+3, James Dennett wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;">On Tue, May 21, 2013 at 11:31 PM, Ran Regev &l=
t;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"wugDjn=
8dalwJ">rege...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt; Hello,
<br>&gt;
<br>&gt; Can anyone point me to the discussion on "why not defining new key=
words as
<br>&gt; 'real' keywords"?
<br>
<br>It's discussed with almost horrible frequency, but mostly not in
<br>writing in public forums I'd guess.
<br>
<br>The short version: it breaks existing code that uses them as
<br>identifiers, and the C++ committee is (believe it or not) somewhat
<br>strongly averse to breaking existing working code.
<br>
<br>(Personally I'd prefer to add more keywords; fixing up the resulting
<br>problems is worthwhile in my opinion.)
<br>
<br>&gt; For example, why can 'final' be used as a variable?
<br>&gt; Surely it causes problems:
<br>&gt; <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013=
/n3539.html#1318" target=3D"_blank">http://www.open-std.org/jtc1/<wbr>sc22/=
wg21/docs/papers/2013/<wbr>n3539.html#1318</a>
<br>
<br>Breaking all of the code that uses "final" as an identifier would also
<br>cause problems. &nbsp;As with almost all things, it's a trade-off, not =
a
<br>good vs bad decision. &nbsp;(In my limited checks, there are actually f=
ar
<br>more uses of "override" than "final", but both are used somewhat
<br>frequently in real C++98 code.)
<br>
<br>In this particular case, there was pre-existing experience from
<br>C++/CLI that using contextual keywords for these was workable -- and
<br>the C++ committee does give some weight to implementation/usage
<br>experience.
<br>
<br>You might notice that the keywords added in C++11 are often rather
<br>obscure: e.g., "nullptr" instead of "null". &nbsp;A significant part of=
 the
<br>reason for that is to avoid clashes with existing code.
<br>
<br>-- James
<br></blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_505_4495646.1369304997834--

.

------=_Part_136_12758614.1369316210439
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, May 23, 2013 3:29:57 AM UTC-7, Ran Regev wrote:
>
>
> Thanks for the answer, backward compatibility was my initial guess.
> I have two following questions:
> 1) Is it only me or that everyone must fix something when advancing a
> compiler?
> And if I'm not the only one, then what does it matter if we need to fix X
> issues or X + 3?
>

Most legal C++ code compiles just fine under C++11. While there certainly
are some issues that need fixing, you want to *minimize* those issues as
much as possible. You don't just make changes willy-nilly and tell people
to "fix it yourself". Doing that leads to people simply not adopting C++11.

Just look at the "smoothness" of the transition from Python 2.x to Python
3.x. And by "transition", I mean "balkanization of the community". That's
what happens if you don't try to minimize breaking changes.

We're talking about a situation where the *only* thing you get from making
them full-fledged keywords is *breaking code*. Why would you want to break
code when you *don't* have to?

2) How do c++ editors color the new keywords? Do they try to understand the
> meaning of the words and color it accordingly, or ??
>

That's up to IDEs, not the standards committee.

--

---
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/?hl=en.



------=_Part_136_12758614.1369316210439
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thursday, May 23, 2013 3:29:57 AM UTC-7, Ran Regev wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div><br></div><div><div>Thanks for the answe=
r, backward compatibility was my initial guess.</div><div>I have two follow=
ing questions:</div><div>1) Is it only me or that everyone must fix somethi=
ng when advancing a compiler?</div><div>And if I'm not the only one, then w=
hat does it matter if we need to fix X issues or X + 3?</div></div></blockq=
uote><div><br>Most legal C++ code compiles just fine under C++11. While the=
re certainly are some issues that need fixing, you want to <i>minimize</i> =
those issues as much as possible. You don't just make changes willy-nilly a=
nd tell people to "fix it yourself". Doing that leads to people simply not =
adopting C++11.<br><br>Just look at the "smoothness" of the transition from=
 Python 2.x to Python 3.x. And by "transition", I mean "balkanization of th=
e community". That's what happens if you don't try to minimize breaking cha=
nges.<br><br>We're talking about a situation where the <i>only</i> thing yo=
u get from making them full-fledged keywords is <i>breaking code</i>. Why w=
ould you want to break code when you <i>don't</i> have to?<br><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div><div>2) How do c++ editors c=
olor the new keywords? Do they try to understand the meaning of the words a=
nd color it accordingly, or ??<br></div></div></blockquote><div><br>That's =
up to IDEs, not the standards committee.</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_136_12758614.1369316210439--

.