Topic: Draft Proposal of IO Operators
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Fri, 15 Feb 2019 05:45:19 +1000
Raw View
--000000000000be92220581dfe627
Content-Type: text/plain; charset="UTF-8"
This scribble fell out while I was working on a new fangled conceptified
constexpr newiostream proposal. Thoughts appreciated...
*Motivation*
C++ has the most verbose standard IO syntax of any popular language. We
propose to fix that.
*Specification*
Introduce new tokens `<<<` and `>>>`
Introduce new expressions:
output-expression:
expression <<< expression-seq
input-expression:
expression >>> expression-seq
expression-seq:
expression-seq expression
expression
An ambiguity can arrise between an expression and an expression-seq. Such
ambiguities are resolved in favor of the expression. [Example:
std::cout <<< 5 - 3;
is equivalanet to:
std::cout << 5 - 3;
not
std::cout << 5 << -3;
end example]
An output-expression of the form X <<< E1 E2 and so on up to En is
equivalent to X << E1 << E2 << and so on up to << En.
An input-expression of the form X >> E1 E2 and so on up to En is equivalent
to X >> E1 >> E2 >> and so on up to >> En.
*Example*
Before proposal:
std::cout << a << b << c << d << e;
std::cin >> a >> b >> c >> d >> e;
After proposal:
std::cin >>> a b c d e;
std::cout <<< a b c d e;
--
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/CAB%2B4KH%2BcVVU0uQfBQnO9zObT5hESUiKj0xkdmcijxpUMKCLvrQ%40mail.gmail.com.
--000000000000be92220581dfe627
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>This scribble fell out while I was working on a new f=
angled conceptified constexpr newiostream proposal.=C2=A0 Thoughts apprecia=
ted...</div><div><br></div><b>Motivation</b><div><br></div><div>C++ has the=
most verbose standard IO syntax of any popular language.=C2=A0 We propose =
to fix that.</div><div><b><br></b></div><div><b>Specification</b></div><div=
><br></div><div>Introduce new tokens `<<<` and `>>>`</div=
><div><br></div><div>Introduce new expressions:</div><div><br></div><div>=
=C2=A0 =C2=A0 output-expression:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 expr=
ession <<< expression-seq<br></div><div><br></div><div>=C2=A0 =C2=
=A0 input-expression:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 expression >=
>> expression-seq<br></div><div><br></div><div>=C2=A0 =C2=A0 expressi=
on-seq:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 expression-seq expression</di=
v><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 expression</div><div><br></div><div>An a=
mbiguity can arrise between an expression and an expression-seq.=C2=A0 Such=
ambiguities are resolved in favor of the expression.=C2=A0 [Example:</div>=
<div><br></div><div>=C2=A0 =C2=A0 std::cout <<< 5 - 3;</div><div><=
br></div><div>is equivalanet to:</div><div><br></div><div>=C2=A0 =C2=A0 std=
::cout << 5 - 3;</div><div><br></div><div>not</div><div><br></div><di=
v>=C2=A0 =C2=A0 std::cout << 5 << -3;</div><div><br></div><div>=
end example]</div><div><br></div><div>An output-expression of the form X &l=
t;<< E1 E2 and so on up to En is equivalent to X << E1 <<=
E2 << and so on up to << En.</div><div><br></div><div>An input=
-expression of the form X >> E1 E2 and so on up to En is equivalent t=
o X >> E1 >> E2 >> and so on up to >> En.</div><div=
><br></div><div><b>Example</b></div><div><br></div><div>Before proposal:</d=
iv><div><br></div><div>=C2=A0 =C2=A0 =C2=A0std::cout << a << b =
<< c << d << e;<br></div><div><div>=C2=A0 =C2=A0 =C2=A0st=
d::cin >> a >> b >> c >> d >> e;</div><br cla=
ss=3D"gmail-Apple-interchange-newline"></div><div>After proposal:</div><div=
><br></div><div>=C2=A0 =C2=A0 =C2=A0std::cin >>> a b c d e;</div><=
div>=C2=A0 =C2=A0 =C2=A0std::cout <<< a b c d e;</div><div><br></d=
iv></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KH%2BcVVU0uQfBQnO9zObT5hESUiKj=
0xkdmcijxpUMKCLvrQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KH%2Bc=
VVU0uQfBQnO9zObT5hESUiKj0xkdmcijxpUMKCLvrQ%40mail.gmail.com</a>.<br />
--000000000000be92220581dfe627--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 14 Feb 2019 12:57:22 -0800
Raw View
On Thursday, 14 February 2019 11:45:19 PST Andrew Tomazos wrote:
> C++ has the most verbose standard IO syntax of any popular language. We
> propose to fix that.
Hello Andrew
I beg to differ. The use of operator<< and >> can be surprising for those not
familiar with them, but they are certainly well-known to the C++ community by
now. And there are lots of libraries doing better formatting, especially with
internationalisation support. You don't have to use operator<<.
So what problem are you solving?
Also note how <<< and >>> are merge conflict markers. Some compilers are smart
enough to produce an error message telling you about them, instead of a lex
choke on <<<. Text editors and IDEs often recognise them as well, launching
into conflict-resolution mode. Moreover, by making <<< and >>> an actual
token, you can accidentally cause conflicted code to become valid (though the
=== would remain).
> An ambiguity can arrise between an expression and an expression-seq. Such
> ambiguities are resolved in favor of the expression. [Example:
>
> std::cout <<< 5 - 3;
>
> is equivalanet to:
>
> std::cout << 5 - 3;
std::cout <<< 5
#ifndef _NDEBUG
"Hello"
#endif
-3;
Sounds like a recipe for subtle bugs to me.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel System Software Products
--
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/1870897.2t52x6VRUp%40tjmaciei-mobl1.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 16 Feb 2019 19:39:02 -0800 (PST)
Raw View
------=_Part_216_1350239933.1550374742565
Content-Type: multipart/alternative;
boundary="----=_Part_217_1572015981.1550374742565"
------=_Part_217_1572015981.1550374742565
Content-Type: text/plain; charset="UTF-8"
On Thursday, February 14, 2019 at 3:57:34 PM UTC-5, Thiago Macieira wrote:
>
> On Thursday, 14 February 2019 11:45:19 PST Andrew Tomazos wrote:
> > C++ has the most verbose standard IO syntax of any popular language. We
> > propose to fix that.
>
> Hello Andrew
>
> I beg to differ. The use of operator<< and >> can be surprising for those
> not
> familiar with them, but they are certainly well-known to the C++ community
> by
> now. And there are lots of libraries doing better formatting, especially
> with
> internationalisation support. You don't have to use operator<<.
>
> So what problem are you solving?
>
> Also note how <<< and >>> are merge conflict markers. Some compilers are
> smart
> enough to produce an error message telling you about them, instead of a
> lex
> choke on <<<. Text editors and IDEs often recognise them as well,
> launching
> into conflict-resolution mode. Moreover, by making <<< and >>> an actual
> token, you can accidentally cause conflicted code to become valid (though
> the
> === would remain).
>
> > An ambiguity can arrise between an expression and an expression-seq.
> Such
> > ambiguities are resolved in favor of the expression. [Example:
> >
> > std::cout <<< 5 - 3;
> >
> > is equivalanet to:
> >
> > std::cout << 5 - 3;
>
> std::cout <<< 5
> #ifndef _NDEBUG
> "Hello"
> #endif
> -3;
>
> Sounds like a recipe for subtle bugs to me.
>
They're not even that subtle:
int *foo = ...;
std::cout <<< 5 *foo;
It's obvious what the user intended, but according to the ambiguity
resolution, that means to multiply a pointer and 5, which is ill-formed. Oh
sure, it becomes a compile error, but the only solution is to go back to
the "verbose" syntax.
C++ really doesn't need more "this syntax is better than the old one,
except for when it isn't" tools in its toolbox. If the new syntax cannot
100% subsume every use of the old one, then we shouldn't bother.
Also, it should be noted that the new text formatting library makes at
least half of the argument for this obsolete.
--
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/21013772-9554-4db3-83fc-f2f0ae5472b5%40isocpp.org.
------=_Part_217_1572015981.1550374742565
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, February 14, 2019 at 3:57:34 PM UTC-5=
, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu=
rsday, 14 February 2019 11:45:19 PST Andrew Tomazos wrote:
<br>> C++ has the most verbose standard IO syntax of any popular languag=
e. =C2=A0We
<br>> propose to fix that.
<br>
<br>Hello Andrew
<br>
<br>I beg to differ. The use of operator<< and >> can be surpri=
sing for those not=20
<br>familiar with them, but they are certainly well-known to the C++ commun=
ity by=20
<br>now. And there are lots of libraries doing better formatting, especiall=
y with=20
<br>internationalisation support. You don't have to use operator<<=
;.
<br>
<br>So what problem are you solving?
<br>
<br>Also note how <<< and >>> are merge conflict markers.=
Some compilers are smart=20
<br>enough to produce an error message telling you about them, instead of a=
lex=20
<br>choke on <<<. Text editors and IDEs often recognise them as we=
ll, launching=20
<br>into conflict-resolution mode. Moreover, by making <<< and >=
;>> an actual=20
<br>token, you can accidentally cause conflicted code to become valid (thou=
gh the=20
<br>=3D=3D=3D would remain).
<br>
<br>> An ambiguity can arrise between an expression and an expression-se=
q. =C2=A0Such
<br>> ambiguities are resolved in favor of the expression. =C2=A0[Exampl=
e:
<br>>=20
<br>> =C2=A0 =C2=A0 std::cout <<< 5 - 3;
<br>>=20
<br>> is equivalanet to:
<br>>=20
<br>> =C2=A0 =C2=A0 std::cout << 5 - 3;
<br>
<br>std::cout <<< 5
<br>#ifndef _NDEBUG
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"Hello"
<br>#endif
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-3;
<br>
<br>Sounds like a recipe for subtle bugs to me.
<br></blockquote><div><br></div><div>They're not even that subtle:<br><=
br><div style=3D"background-color: rgb(250, 250, 250); border-color: rgb(18=
7, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: break-=
word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">int</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">foo </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">...;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>std</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">cout </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y"><<<</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">5</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">foo</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">;</span></div></code></div><br>It'=
s obvious what the user intended, but according to the ambiguity resolution=
, that means to multiply a pointer and 5, which is ill-formed. Oh sure, it =
becomes a compile error, but the only solution is to go back to the "v=
erbose" syntax.<br><br>C++ really doesn't need more "this syn=
tax is better than the old one, except for when it isn't" tools in=
its toolbox. If the new syntax cannot 100% subsume every use of the old on=
e, then we shouldn't bother.</div><div><br></div><div>Also, it should b=
e noted that the new text formatting library makes at least half of the arg=
ument for this obsolete.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/21013772-9554-4db3-83fc-f2f0ae5472b5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/21013772-9554-4db3-83fc-f2f0ae5472b5=
%40isocpp.org</a>.<br />
------=_Part_217_1572015981.1550374742565--
------=_Part_216_1350239933.1550374742565--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sun, 17 Feb 2019 13:50:10 +1000
Raw View
--0000000000005b1aca05820ee895
Content-Type: text/plain; charset="UTF-8"
Yeah agreed. This hasn't been well-received. I think for new iostreams,
we will keep the existing syntax.
On Sun, Feb 17, 2019 at 1:39 PM Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Thursday, February 14, 2019 at 3:57:34 PM UTC-5, Thiago Macieira wrote:
>>
>> On Thursday, 14 February 2019 11:45:19 PST Andrew Tomazos wrote:
>> > C++ has the most verbose standard IO syntax of any popular language.
>> We
>> > propose to fix that.
>>
>> Hello Andrew
>>
>> I beg to differ. The use of operator<< and >> can be surprising for those
>> not
>> familiar with them, but they are certainly well-known to the C++
>> community by
>> now. And there are lots of libraries doing better formatting, especially
>> with
>> internationalisation support. You don't have to use operator<<.
>>
>> So what problem are you solving?
>>
>> Also note how <<< and >>> are merge conflict markers. Some compilers are
>> smart
>> enough to produce an error message telling you about them, instead of a
>> lex
>> choke on <<<. Text editors and IDEs often recognise them as well,
>> launching
>> into conflict-resolution mode. Moreover, by making <<< and >>> an actual
>> token, you can accidentally cause conflicted code to become valid (though
>> the
>> === would remain).
>>
>> > An ambiguity can arrise between an expression and an expression-seq.
>> Such
>> > ambiguities are resolved in favor of the expression. [Example:
>> >
>> > std::cout <<< 5 - 3;
>> >
>> > is equivalanet to:
>> >
>> > std::cout << 5 - 3;
>>
>> std::cout <<< 5
>> #ifndef _NDEBUG
>> "Hello"
>> #endif
>> -3;
>>
>> Sounds like a recipe for subtle bugs to me.
>>
>
> They're not even that subtle:
>
> int *foo = ...;
> std::cout <<< 5 *foo;
>
> It's obvious what the user intended, but according to the ambiguity
> resolution, that means to multiply a pointer and 5, which is ill-formed. Oh
> sure, it becomes a compile error, but the only solution is to go back to
> the "verbose" syntax.
>
> C++ really doesn't need more "this syntax is better than the old one,
> except for when it isn't" tools in its toolbox. If the new syntax cannot
> 100% subsume every use of the old one, then we shouldn't bother.
>
> Also, it should be noted that the new text formatting library makes at
> least half of the argument for this obsolete.
>
> --
> 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/21013772-9554-4db3-83fc-f2f0ae5472b5%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/21013772-9554-4db3-83fc-f2f0ae5472b5%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CAB%2B4KHKmsqOBV_ZRBkcUSsk%2BGKG0W8zUtcTpTQFWKCYsDkiVOg%40mail.gmail.com.
--0000000000005b1aca05820ee895
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Yeah agreed.=C2=A0 This hasn't been well-received.=C2=
=A0 I think for new iostreams, we will keep the existing syntax.</div><br><=
div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Feb=
17, 2019 at 1:39 PM Nicol Bolas <<a href=3D"mailto:jmckesson@gmail.com"=
>jmckesson@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><div dir=3D"ltr"><br><br>On Thursday, February 14, 2019=
at 3:57:34 PM UTC-5, Thiago Macieira wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">On Thursday, 14 February 2019 11:45:19 PST Andrew Tomazo=
s wrote:
<br>> C++ has the most verbose standard IO syntax of any popular languag=
e.=C2=A0 We
<br>> propose to fix that.
<br>
<br>Hello Andrew
<br>
<br>I beg to differ. The use of operator<< and >> can be surpri=
sing for those not=20
<br>familiar with them, but they are certainly well-known to the C++ commun=
ity by=20
<br>now. And there are lots of libraries doing better formatting, especiall=
y with=20
<br>internationalisation support. You don't have to use operator<<=
;.
<br>
<br>So what problem are you solving?
<br>
<br>Also note how <<< and >>> are merge conflict markers.=
Some compilers are smart=20
<br>enough to produce an error message telling you about them, instead of a=
lex=20
<br>choke on <<<. Text editors and IDEs often recognise them as we=
ll, launching=20
<br>into conflict-resolution mode. Moreover, by making <<< and >=
;>> an actual=20
<br>token, you can accidentally cause conflicted code to become valid (thou=
gh the=20
<br>=3D=3D=3D would remain).
<br>
<br>> An ambiguity can arrise between an expression and an expression-se=
q.=C2=A0 Such
<br>> ambiguities are resolved in favor of the expression. =C2=A0[Exampl=
e:
<br>>=20
<br>> =C2=A0 =C2=A0 std::cout <<< 5 - 3;
<br>>=20
<br>> is equivalanet to:
<br>>=20
<br>> =C2=A0 =C2=A0 std::cout << 5 - 3;
<br>
<br>std::cout <<< 5
<br>#ifndef _NDEBUG
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"Hello"
<br>#endif
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-3;
<br>
<br>Sounds like a recipe for subtle bugs to me.
<br></blockquote><div><br></div><div>They're not even that subtle:<br><=
br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187=
,187);border-style:solid;border-width:1px" class=3D"gmail-m_-62524337787926=
84690prettyprint"><code class=3D"gmail-m_-6252433778792684690prettyprint"><=
div class=3D"gmail-m_-6252433778792684690subprettyprint"><span style=3D"col=
or:rgb(0,0,136)" class=3D"gmail-m_-6252433778792684690styled-by-prettify">i=
nt</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-625243377879268=
4690styled-by-prettify"> </span><span style=3D"color:rgb(102,102,0)" class=
=3D"gmail-m_-6252433778792684690styled-by-prettify">*</span><span style=3D"=
color:rgb(0,0,0)" class=3D"gmail-m_-6252433778792684690styled-by-prettify">=
foo </span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-625243377=
8792684690styled-by-prettify">=3D</span><span style=3D"color:rgb(0,0,0)" cl=
ass=3D"gmail-m_-6252433778792684690styled-by-prettify"> </span><span style=
=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6252433778792684690styled-by-pr=
ettify">...;</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-62524=
33778792684690styled-by-prettify"><br>std</span><span style=3D"color:rgb(10=
2,102,0)" class=3D"gmail-m_-6252433778792684690styled-by-prettify">::</span=
><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6252433778792684690styl=
ed-by-prettify">cout </span><span style=3D"color:rgb(102,102,0)" class=3D"g=
mail-m_-6252433778792684690styled-by-prettify"><<<</span><span sty=
le=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6252433778792684690styled-by-pret=
tify"> </span><span style=3D"color:rgb(0,102,102)" class=3D"gmail-m_-625243=
3778792684690styled-by-prettify">5</span><span style=3D"color:rgb(0,0,0)" c=
lass=3D"gmail-m_-6252433778792684690styled-by-prettify"> </span><span style=
=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6252433778792684690styled-by-pr=
ettify">*</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-62524337=
78792684690styled-by-prettify">foo</span><span style=3D"color:rgb(102,102,0=
)" class=3D"gmail-m_-6252433778792684690styled-by-prettify">;</span></div><=
/code></div><br>It's obvious what the user intended, but according to t=
he ambiguity resolution, that means to multiply a pointer and 5, which is i=
ll-formed. Oh sure, it becomes a compile error, but the only solution is to=
go back to the "verbose" syntax.<br><br>C++ really doesn't n=
eed more "this syntax is better than the old one, except for when it i=
sn't" tools in its toolbox. If the new syntax cannot 100% subsume =
every use of the old one, then we shouldn't bother.</div><div><br></div=
><div>Also, it should be noted that the new text formatting library makes a=
t least half of the argument for this obsolete.<br></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/21013772-9554-4db3-83fc-f2f0ae5472b5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/21013772-9554-=
4db3-83fc-f2f0ae5472b5%40isocpp.org</a>.<br>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHKmsqOBV_ZRBkcUSsk%2BGKG0W8zU=
tcTpTQFWKCYsDkiVOg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHKmsq=
OBV_ZRBkcUSsk%2BGKG0W8zUtcTpTQFWKCYsDkiVOg%40mail.gmail.com</a>.<br />
--0000000000005b1aca05820ee895--
.