------=_Part_236_991685926.1425830081198
Content-Type: multipart/alternative;
 boundary="----=_Part_237_644773915.1425830081198"

------=_Part_237_644773915.1425830081198
Content-Type: text/plain; charset=UTF-8

Wouldn't it be better instead of taking one dummy parameter
the user-defined function which implements the post-fix ++ or -- operator
to have declaration similar to the form:

operator ~--()

I personally think that this is a lot more clear then:

operator --(int);

In which the only one function parameter of type 'int' will have a dummy
value of '0' when instanced.

What do you think?

--

---
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_237_644773915.1425830081198
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Wouldn't it be better instead of taking one dummy paramete=
r the&nbsp;user-defined function which implements the post-fix ++ or -- ope=
rator to have declaration similar to the form:<br><br><div class=3D"prettyp=
rint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word;=
 background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div cl=
ass=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">operator</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">~--()=
</span></div></code></div><div><br></div><div>I personally think that this =
is a lot more clear then:</div><div><br></div><div><div class=3D"prettyprin=
t" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; ba=
ckground-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">operator</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">--(</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">);</span></div></code>=
</div><br>In which the only one function parameter of type 'int' will have =
a dummy value of '0' when instanced.<br><br>What do you think?<br></div><di=
v><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_237_644773915.1425830081198--
------=_Part_236_991685926.1425830081198--

.

------=_Part_2312_1948565192.1425831689167
Content-Type: multipart/alternative;
 boundary="----=_Part_2313_409565194.1425831689167"

------=_Part_2313_409565194.1425831689167
Content-Type: text/plain; charset=UTF-8

Ship has sailed too long ago?

On Sunday, March 8, 2015 at 12:54:41 PM UTC-3, Alexander Nikolov wrote:
>
> Wouldn't it be better instead of taking one dummy parameter
> the user-defined function which implements the post-fix ++ or -- operator
> to have declaration similar to the form:
>
> operator ~--()
>
> I personally think that this is a lot more clear then:
>
> operator --(int);
>
> In which the only one function parameter of type 'int' will have a dummy
> value of '0' when instanced.
>
> What do you think?
>
>

--

---
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_2313_409565194.1425831689167
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Ship has sailed too long ago?<br><br>On Sunday, March 8, 2=
015 at 12:54:41 PM UTC-3, Alexander Nikolov wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr">Wouldn't it be better instead of takin=
g one dummy parameter the&nbsp;user-defined function which implements the p=
ost-fix ++ or -- operator to have declaration similar to the form:<br><br><=
div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;backgro=
und-color:rgb(250,250,250)"><code><div><span style=3D"color:#008">operator<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">~--()</=
span></div></code></div><div><br></div><div>I personally think that this is=
 a lot more clear then:</div><div><br></div><div><div style=3D"border:1px s=
olid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250=
)"><code><div><span style=3D"color:#008">operator</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#660">--(</span><span style=3D"color:#=
008">int</span><span style=3D"color:#660">);</span></div></code></div><br>I=
n which the only one function parameter of type 'int' will have a dummy val=
ue of '0' when instanced.<br><br>What do you think?<br></div><div><br></div=
></div></blockquote></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_2313_409565194.1425831689167--
------=_Part_2312_1948565192.1425831689167--

.

------=_Part_279_244895041.1425832703433
Content-Type: multipart/alternative;
 boundary="----=_Part_280_1372286435.1425832703433"

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

You mean that it is not worth fixing obvious idiotic decisions?

If compatibility is you concern - you may note that it's lost gone and=20
everybody knows that.

=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 8 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=
=B3., 18:21:29 UTC+2, Matheus Izvekov =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:
>
> Ship has sailed too long ago?
>
> On Sunday, March 8, 2015 at 12:54:41 PM UTC-3, Alexander Nikolov wrote:
>>
>> Wouldn't it be better instead of taking one dummy parameter=20
>> the user-defined function which implements the post-fix ++ or -- operato=
r=20
>> to have declaration similar to the form:
>>
>> operator ~--()
>>
>> I personally think that this is a lot more clear then:
>>
>> operator --(int);
>>
>> In which the only one function parameter of type 'int' will have a dummy=
=20
>> value of '0' when instanced.
>>
>> What do you think?
>>
>>

--=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_280_1372286435.1425832703433
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">You mean that it is not worth fixing obvious idiotic decis=
ions?<div><br></div><div>If&nbsp;compatibility&nbsp;is you concern - you ma=
y note that it's lost gone and everybody knows that.<br><br>=D0=BD=D0=B5=D0=
=B4=D0=B5=D0=BB=D1=8F, 8 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 18:21:29 UT=
C+2, Matheus Izvekov =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">Ship has sailed too long ago?<=
br><br>On Sunday, March 8, 2015 at 12:54:41 PM UTC-3, Alexander Nikolov wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Wouldn't it be =
better instead of taking one dummy parameter the&nbsp;user-defined function=
 which implements the post-fix ++ or -- operator to have declaration simila=
r to the form:<br><br><div style=3D"border:1px solid rgb(187,187,187);word-=
wrap:break-word;background-color:rgb(250,250,250)"><code><div><span style=
=3D"color:#008">operator</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#660">~--()</span></div></code></div><div><br></div><div>I pers=
onally think that this is a lot more clear then:</div><div><br></div><div><=
div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;backgro=
und-color:rgb(250,250,250)"><code><div><span style=3D"color:#008">operator<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">--(</sp=
an><span style=3D"color:#008">int</span><span style=3D"color:#660">);</span=
></div></code></div><br>In which the only one function parameter of type 'i=
nt' will have a dummy value of '0' when instanced.<br><br>What do you think=
?<br></div><div><br></div></div></blockquote></div></blockquote></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_280_1372286435.1425832703433--
------=_Part_279_244895041.1425832703433--

.

------=_Part_318_253559934.1425834048455
Content-Type: multipart/alternative;
 boundary="----=_Part_319_974255090.1425834048455"

------=_Part_319_974255090.1425834048455
Content-Type: text/plain; charset=UTF-8

Well, it's not that simple. You may as well submit a formal proposal and
see how it fares.
I am sure though that something like this has already been discussed.

Would you propose that the (int) form be deprecated?
If so, you might ask how much code will need to be fixed.
If not, you have to factor in the extra complexity and confusion caused by
both forms living in the wild.
Is it worth it for this simple issue?

--

---
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_319_974255090.1425834048455
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Well, it's not that simple. You may as well submit a forma=
l proposal and see how it fares.<br>I am sure though that something like th=
is has already been discussed.<br><br>Would you propose that the (int) form=
 be deprecated?<br>If so, you might ask how much code will need to be fixed=
..<br>If not, you have to factor in the extra complexity and confusion cause=
d by both forms living in the wild.<br>Is it worth it for this simple issue=
?<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 />

------=_Part_319_974255090.1425834048455--
------=_Part_318_253559934.1425834048455--

.

On 8 March 2015 at 19:00, Matheus Izvekov <mizvekov@gmail.com> wrote:
> Well, it's not that simple. You may as well submit a formal proposal and see
> how it fares.
> I am sure though that something like this has already been discussed.

I doubt it has, partly because I fail to see the point of such a
microscopic addition.
We can't replace the existing syntax, so adding an alternative would serve
little purpose.

--

---
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/.

.

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

Before calling the decision "idiotic", you should read *The Design and
Evolution of C++* and understand for yourself the factors under
consideration at the time.

On Sun, Mar 8, 2015 at 9:38 AM, Alexander Nikolov <sasho648@mail.bg> wrote:

> You mean that it is not worth fixing obvious idiotic decisions?
>
> If compatibility is you concern - you may note that it's lost gone and
> everybody knows that.
>
> =D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 8 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=
=B3., 18:21:29 UTC+2, Matheus Izvekov =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:
>
>> Ship has sailed too long ago?
>>
>> On Sunday, March 8, 2015 at 12:54:41 PM UTC-3, Alexander Nikolov wrote:
>>>
>>> Wouldn't it be better instead of taking one dummy parameter
>>> the user-defined function which implements the post-fix ++ or -- operat=
or
>>> to have declaration similar to the form:
>>>
>>> operator ~--()
>>>
>>> I personally think that this is a lot more clear then:
>>>
>>> operator --(int);
>>>
>>> In which the only one function parameter of type 'int' will have a dumm=
y
>>> value of '0' when instanced.
>>>
>>> What do you think?
>>>
>>>  --
>
> ---
> 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/.
>



--=20
*Brian Bi*

--=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/.

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

<div dir=3D"ltr">Before calling the decision &quot;idiotic&quot;, you shoul=
d read <i>The Design and Evolution of C++</i> and understand for yourself t=
he factors under consideration at the time.<br><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote">On Sun, Mar 8, 2015 at 9:38 AM, Alexander Nik=
olov <span dir=3D"ltr">&lt;<a href=3D"mailto:sasho648@mail.bg" target=3D"_b=
lank">sasho648@mail.bg</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr">You mean that it is not worth fixing obvious idiotic d=
ecisions?<div><br></div><div>If=C2=A0compatibility=C2=A0is you concern - yo=
u may note that it&#39;s lost gone and everybody knows that.<br><br>=D0=BD=
=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 8 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 18=
:21:29 UTC+2, Matheus Izvekov =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<div><di=
v class=3D"h5"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Shi=
p has sailed too long ago?<br><br>On Sunday, March 8, 2015 at 12:54:41 PM U=
TC-3, Alexander Nikolov wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr">Wouldn&#39;t it be better instead of taking one dummy parameter=
 the=C2=A0user-defined function which implements the post-fix ++ or -- oper=
ator to have declaration similar to the form:<br><br><div style=3D"border:1=
px solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,250=
,250)"><code><div><span style=3D"color:#008">operator</span><span style=3D"=
color:#000"> </span><span style=3D"color:#660">~--()</span></div></code></d=
iv><div><br></div><div>I personally think that this is a lot more clear the=
n:</div><div><br></div><div><div style=3D"border:1px solid rgb(187,187,187)=
;word-wrap:break-word;background-color:rgb(250,250,250)"><code><div><span s=
tyle=3D"color:#008">operator</span><span style=3D"color:#000"> </span><span=
 style=3D"color:#660">--(</span><span style=3D"color:#008">int</span><span =
style=3D"color:#660">);</span></div></code></div><br>In which the only one =
function parameter of type &#39;int&#39; will have a dummy value of &#39;0&=
#39; when instanced.<br><br>What do you think?<br></div><div><br></div></di=
v></blockquote></div></blockquote></div></div></div></div><div class=3D"HOE=
nZb"><div class=3D"h5">

<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" 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>
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><br clear=3D"all"><br>-- <br><div class=
=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><font color=3D"=
#c0c0c0"><i>Brian Bi</i></font><br><div></div><div></div><div></div></div><=
/div></div></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 />

--001a1134df96c0a8b00510ccfb31--

.

------=_Part_453_1872207078.1425852531278
Content-Type: multipart/alternative;
 boundary="----=_Part_454_1253964102.1425852531278"

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



=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 8 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=
=B3., 22:44:33 UTC+2, Brian Bi =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:
>
> Before calling the decision "idiotic", you should read *The Design and=20
> Evolution of C++* and understand for yourself the factors under=20
> consideration at the time.
>
> On Sun, Mar 8, 2015 at 9:38 AM, Alexander Nikolov <sash...@mail.bg=20
> <javascript:>> wrote:
>
>> You mean that it is not worth fixing obvious idiotic decisions?
>>
>> If compatibility is you concern - you may note that it's lost gone and=
=20
>> everybody knows that.
>>
>> =D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 8 =D0=BC=D0=B0=D1=80=D1=82 2015 =
=D0=B3., 18:21:29 UTC+2, Matheus Izvekov =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=
=B0:
>>
>>> Ship has sailed too long ago?
>>>
>>> On Sunday, March 8, 2015 at 12:54:41 PM UTC-3, Alexander Nikolov wrote:
>>>>
>>>> Wouldn't it be better instead of taking one dummy parameter=20
>>>> the user-defined function which implements the post-fix ++ or -- opera=
tor=20
>>>> to have declaration similar to the form:
>>>>
>>>> operator ~--()
>>>>
>>>> I personally think that this is a lot more clear then:
>>>>
>>>> operator --(int);
>>>>
>>>> In which the only one function parameter of type 'int' will have a=20
>>>> dummy value of '0' when instanced.
>>>>
>>>> What do you think?
>>>>
>>>>  --=20
>>
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>
>
> --=20
> *Brian Bi*
>

OK - I read it and as far as I can see he (Bjarne Stroustrup) considered=20
adding new keywords - 'prefix' and 'postfix' but didn't choice to make them=
=20
because he 'received the usual howl of outrage from people who dislike new=
=20
keywords.'. He also considered a variant in which the post-fix operator=20
functions would look like this:

++operator()

--operator()

Although he never mentioned why this was not implemented I can make a guess=
=20
that the reason is some kind of interpreter ambiguity or possibly difficult=
=20
implementation.

However my idea was never mentioned - using this special combination of 2=
=20
operators - ~ and -- which is neither harder to implement or creates any=20
kind of ambiguity. So I guess you are the one who haven't read this book or=
=20
else I don't know what your arguments are. However the important part is if=
=20
we can change this now.

Even he says that:

These explanations are needed because the mechanism is unique and therefore=
=20
> a
> bit of a wart.=20
> *Given a choice, I would probably have introduced the prefix andpostfix=
=20
> keywords, but that didn't appear feasible at the time.* However, the only
> really important point is that the mechanism works and can be understood=
=20
> and used
> by the few programmers. who really need it.

--=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_454_1253964102.1425852531278
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 8 =D0=BC=D0=
=B0=D1=80=D1=82 2015 =D0=B3., 22:44:33 UTC+2, Brian Bi =D0=BD=D0=B0=D0=BF=
=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">Before calling the decision "idiotic", you should read <i>The Design =
and Evolution of C++</i> and understand for yourself the factors under cons=
ideration at the time.<br><div><br><div class=3D"gmail_quote">On Sun, Mar 8=
, 2015 at 9:38 AM, Alexander Nikolov <span dir=3D"ltr">&lt;<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"c1Y5Fir8ohUJ" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"th=
is.href=3D'javascript:';return true;">sash...@mail.bg</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">You mean that it is not=
 worth fixing obvious idiotic decisions?<div><br></div><div>If&nbsp;compati=
bility&nbsp;is you concern - you may note that it's lost gone and everybody=
 knows that.<br><br>=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 8 =D0=BC=D0=B0=D1=
=80=D1=82 2015 =D0=B3., 18:21:29 UTC+2, Matheus Izvekov =D0=BD=D0=B0=D0=BF=
=D0=B8=D1=81=D0=B0:<div><div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">Ship has sailed too long ago?<br><br>On Sunday, March 8, 2015 at=
 12:54:41 PM UTC-3, Alexander Nikolov wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr">Wouldn't it be better instead of taking one dummy=
 parameter the&nbsp;user-defined function which implements the post-fix ++ =
or -- operator to have declaration similar to the form:<br><br><div style=
=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-color=
:rgb(250,250,250)"><code><div><span style=3D"color:#008">operator</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#660">~--()</span></di=
v></code></div><div><br></div><div>I personally think that this is a lot mo=
re clear then:</div><div><br></div><div><div style=3D"border:1px solid rgb(=
187,187,187);word-wrap:break-word;background-color:rgb(250,250,250)"><code>=
<div><span style=3D"color:#008">operator</span><span style=3D"color:#000"> =
</span><span style=3D"color:#660">--(</span><span style=3D"color:#008">int<=
/span><span style=3D"color:#660">);</span></div></code></div><br>In which t=
he only one function parameter of type 'int' will have a dummy value of '0'=
 when instanced.<br><br>What do you think?<br></div><div><br></div></div></=
blockquote></div></blockquote></div></div></div></div><div><div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
c1Y5Fir8ohUJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';ret=
urn true;" onclick=3D"this.href=3D'javascript:';return true;">std-proposal.=
...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"c1Y5Fir8ohUJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:=
';return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';return true=
;" onclick=3D"this.href=3D'http://groups.google.com/a/isocpp.org/group/std-=
proposals/';return true;">http://groups.google.com/a/<wbr>isocpp.org/group/=
std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><div><div d=
ir=3D"ltr"><div><div dir=3D"ltr"><font color=3D"#c0c0c0"><i>Brian Bi</i></f=
ont></div></div></div></div></div></div></blockquote><div><br></div><div>OK=
 - I read it and as far as I can see he (Bjarne Stroustrup) considered addi=
ng new keywords - 'prefix' and 'postfix' but didn't choice to make them bec=
ause he 'received the usual howl of outrage from people who dislike new key=
words.'. He also considered a variant in which the post-fix operator functi=
ons would look like this:<br><br><div></div></div><div class=3D"prettyprint=
" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; bac=
kground-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">++</span><span style=3D"color: #008;" class=3D"styled-by-prettify">opera=
tor</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">--</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">operator</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">()</span></div></code></div=
><div><br></div><div>Although he never mentioned why this was not implement=
ed I can make a guess that the reason is some kind of interpreter ambiguity=
 or possibly difficult implementation.</div><div><br></div><div>However my =
idea was never mentioned - using this special combination of 2 operators - =
~ and -- which is neither harder to implement or creates any kind of ambigu=
ity. So I guess you are the one who haven't read this book or else I don't =
know what your arguments are. However the important part is if we can chang=
e this now.</div><div><br></div><div>Even he says that:</div><div><br><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-lef=
t-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: sol=
id; padding-left: 1ex;">These explanations are needed because the mechanism=
 is unique and therefore a<br>bit of a wart. <b>Given a choice, I would pro=
bably have introduced the prefix and<br>postfix keywords, but that didn't a=
ppear feasible at the time.</b> However, the only<br>really important point=
 is that the mechanism works and can be understood and used<br>by the few p=
rogrammers. who really need it.</blockquote></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_454_1253964102.1425852531278--
------=_Part_453_1872207078.1425852531278--

.

On Sunday 08 March 2015 15:08:51 Alexander Nikolov wrote:
> However my idea was never mentioned - using this special combination of 2
> operators - ~ and -- which is neither harder to implement or creates any
> kind of ambiguity.

Because it creates a new token to be parsed, one you can't use anywhere else.
So I doubt you can say "is neither harder to implement".

> So I guess you are the one who haven't read this book or
> else I don't know what your arguments are. However the important part is if
> we can change this now.

We could, but I don't think we should. You said in your original email that
operator ~--() would be more clear. I disagree with you: the existing form is
a lot more clear because that's what we've been teaching for 25 years and it's
an operator--.

Other reasons have been given by others in the thread. I remind you especially
of the one that said that we cannot remove operator--(int) from the language
for (at least) 15 years, we'll still need to teach new developers of the
existing ways. And, of course, there's a cost associated with a porting effort.

--
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_6_1968566483.1425891267276
Content-Type: multipart/alternative;
 boundary="----=_Part_7_1563814099.1425891267277"

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



=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 9 =D0=BC=D0=
=B0=D1=80=D1=82 2015 =D0=B3., 8:42:13 UTC+2, Thiago Macieira =D0=BD=D0=B0=
=D0=BF=D0=B8=D1=81=D0=B0:
>
> On Sunday 08 March 2015 15:08:51 Alexander Nikolov wrote:=20
> > However my idea was never mentioned - using this special combination of=
=20
> 2=20
> > operators - ~ and -- which is neither harder to implement or creates an=
y=20
> > kind of ambiguity.=20
>
> Because it creates a new token to be parsed, one you can't use anywhere=
=20
> else.=20
> So I doubt you can say "is neither harder to implement".=20
>
> > So I guess you are the one who haven't read this book or=20
> > else I don't know what your arguments are. However the important part i=
s=20
> if=20
> > we can change this now.=20
>
> We could, but I don't think we should. You said in your original email=20
> that=20
> operator ~--() would be more clear. I disagree with you: the existing for=
m=20
> is=20
> a lot more clear because that's what we've been teaching for 25 years and=
=20
> it's=20
> an operator--.=20
>

Because you've used to it but for new programmers it is confusing and=20
'wart' including for me. Why should we keep such odd constructs just=20
because of an legacy?
=20

>
> Other reasons have been given by others in the thread. I remind you=20
> especially=20
> of the one that said that we cannot remove operator--(int) from the=20
> language=20
> for (at least) 15 years, we'll still need to teach new developers of the=
=20
> existing ways. And, of course, there's a cost associated with a porting=
=20
> effort.=20
>
>
I don't think there is many code using this rare post-fix operator=20
overloading but even if there are - do you think that compiler vendors=20
wouldn't at least warn or even auto-correct this form?

I believe we should keep the C++ language basis which everyone understands=
=20
and not try keeping odd design decisions. I'm sure that most of the people=
=20
don't even know this form even if they had used it.

Readability and some 'natural' understanding of the code is more important=
=20
then compatibility.

Maintaining old code should be responsibility to compilers or some other=20
software.

Otherwise you'll surely come to a situation that understanding the code=20
will took you hours or you will just give it up as thing become more and=20
more complex. It's easy to keep in mind a few rules which to know that=20
apply everywhere rather then them plus a one hundred of exceptions. For=20
example I know that variables can be declared inside and outside functions=
=20
and that in 'if' statement I can put an expression which depending on it's=
=20
'bool' representation (not sure in the terms used) will either execute the=
=20
code in it's body or not and I'm absolutely sure in this. But then suddenly=
=20
I see this code:

if(int a =3D Func()) {
}

And I'm actually really confused. What's the logic here - why an 'if'=20
expression will take a variable declaration and what does it compares?

Better make programmers life easier and remove such odd things. The simple=
=20
- the better.

The case with my pre-fix operator overloading form. One decent C++=20
developer which sees this for example:

class T
{
public:
      void operator ~++() { ++a; }

      void operator ++() { ++a; }

      int a;
}

Is more likely to deduce the meaning of it then using the existing form:

class T
{
public:
      void operator ++(int arg) { ++a; }

      void operator ++() { ++a; }

      int a;
}

In which he will surely get confused by this single unused parameter and=20
without investigating the matter I highly doubt that he would get the=20
meaning of it.

--=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_7_1563814099.1425891267277
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=
=D0=B8=D0=BA, 9 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 8:42:13 UTC+2, Thiag=
o Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">On Sunday 08 March 2015 15:08:51 Alexander Nikolov wrote:
<br>&gt; However my idea was never mentioned - using this special combinati=
on of 2=20
<br>&gt; operators - ~ and -- which is neither harder to implement or creat=
es any=20
<br>&gt; kind of ambiguity.=20
<br>
<br>Because it creates a new token to be parsed, one you can't use anywhere=
 else.=20
<br>So I doubt you can say "is neither harder to implement".
<br>
<br>&gt; So I guess you are the one who haven't read this book or=20
<br>&gt; else I don't know what your arguments are. However the important p=
art is if
<br>&gt; we can change this now.
<br>
<br>We could, but I don't think we should. You said in your original email =
that=20
<br>operator ~--() would be more clear. I disagree with you: the existing f=
orm is=20
<br>a lot more clear because that's what we've been teaching for 25 years a=
nd it's=20
<br>an operator--.
<br></blockquote><div><br></div><div>Because you've used to it but for new =
programmers it is confusing and 'wart' including for me. Why should we keep=
 such odd constructs just because of an legacy?</div><div>&nbsp;</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">
<br>Other reasons have been given by others in the thread. I remind you esp=
ecially=20
<br>of the one that said that we cannot remove operator--(int) from the lan=
guage=20
<br>for (at least) 15 years, we'll still need to teach new developers of th=
e=20
<br>existing ways. And, of course, there's a cost associated with a porting=
 effort.
<br><br></blockquote><div><br></div><div>I don't think there is many code u=
sing this rare post-fix operator overloading but even if there are - do you=
 think that compiler vendors wouldn't at least warn or even auto-correct th=
is form?</div><div><br></div><div>I believe we should keep the C++ language=
 basis which everyone understands and not try keeping odd design decisions.=
 I'm sure that most of the people don't even know this form even if they ha=
d used it.</div><div><br></div><div>Readability and some 'natural' understa=
nding of the code is more important then compatibility.</div><div><br></div=
><div>Maintaining old code should be responsibility to compilers or some ot=
her software.<br></div><div><br></div><div>Otherwise you'll surely come to =
a situation that understanding the code will took you hours or you will jus=
t give it up as thing become more and more complex. It's easy to keep in mi=
nd a few rules which to know that apply everywhere rather then them plus a =
one hundred of exceptions. For example I know that variables can be declare=
d inside and outside functions and that in 'if' statement I can put an expr=
ession which depending on it's 'bool' representation (not sure in the terms=
&nbsp;used) will either execute the code in it's body or not and I'm absolu=
tely sure in this. But then suddenly I see this code:<br><br></div><div cla=
ss=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap=
: break-word; background-color: rgb(250, 250, 250);"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">if</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Func</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">())</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"styl=
ed-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">}</span></div></code></div><div><br></div><div>And I'm actually r=
eally confused. What's the logic here - why an 'if' expression will take a =
variable declaration and what does it compares?</div><div><br></div><div>Be=
tter make programmers life easier and remove such odd things. The simple - =
the better.</div><div><br></div><div>The case with my pre-fix operator over=
loading form. One decent C++ developer which sees this for example:<br><br>=
</div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 1=
87); word-wrap: break-word; background-color: rgb(250, 250, 250);"><code cl=
ass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> T<br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">public</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
&nbsp; &nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">oper=
ator</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">~++()</span><sp=
an 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"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">++</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">a</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>&nbsp; =
&nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">operator</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"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><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-b=
y-prettify">a</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br><br>&nbsp; &nbsp; &n=
bsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">}</span></div></code></div><div><b=
r></div><div>Is more likely to deduce the meaning of it then using the exis=
ting form:<br><br><div class=3D"prettyprint" style=3D"border: 1px solid rgb=
(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 250=
);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> T<br></span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">public</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>&nbsp; &nbsp; &nbsp; </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">operator</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
++(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> arg</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">)</span><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"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">++</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">a</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br><br>&nbsp; &nbsp; &n=
bsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">void<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">operator</span><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"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">{</span><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-prettif=
y">a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br><br>&nbsp; &nbsp; &nbsp; </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> a</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">}</span></div></code></div><span class=3D"s=
tyled-by-prettify" style=3D"font-family: monospace; color: rgb(102, 102, 0)=
; background-color: rgb(250, 250, 250);"><br></span>In which he will surely=
 get confused by this single unused parameter and without investigating the=
 matter I highly doubt that he would get the meaning of it.</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_7_1563814099.1425891267277--
------=_Part_6_1968566483.1425891267276--

.

------=_Part_8_1709517659.1425892331265
Content-Type: multipart/alternative;
 boundary="----=_Part_9_679581600.1425892331265"

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

The fact is that compatibility with older C++ versions is long gone and=20
even worse - C++ code can be legal for both older and newer versions of the=
=20
standard but behave differently which can cause a lot of trouble with=20
unexpected results. You can search stackoverflow for hundreds of such=20
examples but here is a recent one I was looking at=20
<http://stackoverflow.com/questions/23047198/can-c-code-be-valid-in-both-c0=
3-and-c11-but-do-different-things>
..

I understand if this was an low-level assembly language (as x86 for=20
example) where binaries are directly executed on the machine and no=20
pre-fetching, converting can be done easily but this is an high-level=20
abstraction which is provided for the ease of humans after all.

=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 9 =D0=BC=D0=
=B0=D1=80=D1=82 2015 =D0=B3., 10:54:27 UTC+2, Alexander Nikolov =D0=BD=D0=
=B0=D0=BF=D0=B8=D1=81=D0=B0:
>
>
>
> =D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 9 =D0=BC=D0=
=B0=D1=80=D1=82 2015 =D0=B3., 8:42:13 UTC+2, Thiago Macieira =D0=BD=D0=B0=
=D0=BF=D0=B8=D1=81=D0=B0:
>>
>> On Sunday 08 March 2015 15:08:51 Alexander Nikolov wrote:=20
>> > However my idea was never mentioned - using this special combination o=
f=20
>> 2=20
>> > operators - ~ and -- which is neither harder to implement or creates=
=20
>> any=20
>> > kind of ambiguity.=20
>>
>> Because it creates a new token to be parsed, one you can't use anywhere=
=20
>> else.=20
>> So I doubt you can say "is neither harder to implement".=20
>>
>> > So I guess you are the one who haven't read this book or=20
>> > else I don't know what your arguments are. However the important part=
=20
>> is if=20
>> > we can change this now.=20
>>
>> We could, but I don't think we should. You said in your original email=
=20
>> that=20
>> operator ~--() would be more clear. I disagree with you: the existing=20
>> form is=20
>> a lot more clear because that's what we've been teaching for 25 years an=
d=20
>> it's=20
>> an operator--.=20
>>
>
> Because you've used to it but for new programmers it is confusing and=20
> 'wart' including for me. Why should we keep such odd constructs just=20
> because of an legacy?
> =20
>
>>
>> Other reasons have been given by others in the thread. I remind you=20
>> especially=20
>> of the one that said that we cannot remove operator--(int) from the=20
>> language=20
>> for (at least) 15 years, we'll still need to teach new developers of the=
=20
>> existing ways. And, of course, there's a cost associated with a porting=
=20
>> effort.=20
>>
>>
> I don't think there is many code using this rare post-fix operator=20
> overloading but even if there are - do you think that compiler vendors=20
> wouldn't at least warn or even auto-correct this form?
>
> I believe we should keep the C++ language basis which everyone understand=
s=20
> and not try keeping odd design decisions. I'm sure that most of the peopl=
e=20
> don't even know this form even if they had used it.
>
> Readability and some 'natural' understanding of the code is more importan=
t=20
> then compatibility.
>
> Maintaining old code should be responsibility to compilers or some other=
=20
> software.
>
> Otherwise you'll surely come to a situation that understanding the code=
=20
> will took you hours or you will just give it up as thing become more and=
=20
> more complex. It's easy to keep in mind a few rules which to know that=20
> apply everywhere rather then them plus a one hundred of exceptions. For=
=20
> example I know that variables can be declared inside and outside function=
s=20
> and that in 'if' statement I can put an expression which depending on it'=
s=20
> 'bool' representation (not sure in the terms used) will either execute th=
e=20
> code in it's body or not and I'm absolutely sure in this. But then sudden=
ly=20
> I see this code:
>
> if(int a =3D Func()) {
> }
>
> And I'm actually really confused. What's the logic here - why an 'if'=20
> expression will take a variable declaration and what does it compares?
>
> Better make programmers life easier and remove such odd things. The simpl=
e=20
> - the better.
>
> The case with my pre-fix operator overloading form. One decent C++=20
> developer which sees this for example:
>
> class T
> {
> public:
>       void operator ~++() { ++a; }
>
>       void operator ++() { ++a; }
>
>       int a;
> }
>
> Is more likely to deduce the meaning of it then using the existing form:
>
> class T
> {
> public:
>       void operator ++(int arg) { ++a; }
>
>       void operator ++() { ++a; }
>
>       int a;
> }
>
> In which he will surely get confused by this single unused parameter and=
=20
> without investigating the matter I highly doubt that he would get the=20
> meaning of it.
>

--=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_9_679581600.1425892331265
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The fact is that compatibility with older C++ versions is =
long gone and even worse - C++ code can be legal for both older and newer v=
ersions of the standard but behave differently which can cause a lot of tro=
uble with unexpected results. You can search&nbsp;stackoverflow for hundred=
s of such examples but here is a recent one I was looking <a href=3D"http:/=
/stackoverflow.com/questions/23047198/can-c-code-be-valid-in-both-c03-and-c=
11-but-do-different-things">at</a>.<div><br></div><div>I understand if this=
 was an low-level assembly language (as x86 for example) where binaries are=
 directly executed on the machine and no pre-fetching, converting can be do=
ne easily but this is an high-level abstraction which is provided for the e=
ase of humans after all.<br><br>=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=
=D0=BD=D0=B8=D0=BA, 9 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 10:54:27 UTC+2=
, Alexander Nikolov =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><br><br>=D0=BF=D0=BE=D0=BD=D0=
=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 9 =D0=BC=D0=B0=D1=80=D1=82 2015 =
=D0=B3., 8:42:13 UTC+2, Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=
=B0:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex">On Sunday 08 March 2015 15:08:5=
1 Alexander Nikolov wrote:
<br>&gt; However my idea was never mentioned - using this special combinati=
on of 2=20
<br>&gt; operators - ~ and -- which is neither harder to implement or creat=
es any=20
<br>&gt; kind of ambiguity.=20
<br>
<br>Because it creates a new token to be parsed, one you can't use anywhere=
 else.=20
<br>So I doubt you can say "is neither harder to implement".
<br>
<br>&gt; So I guess you are the one who haven't read this book or=20
<br>&gt; else I don't know what your arguments are. However the important p=
art is if
<br>&gt; we can change this now.
<br>
<br>We could, but I don't think we should. You said in your original email =
that=20
<br>operator ~--() would be more clear. I disagree with you: the existing f=
orm is=20
<br>a lot more clear because that's what we've been teaching for 25 years a=
nd it's=20
<br>an operator--.
<br></blockquote><div><br></div><div>Because you've used to it but for new =
programmers it is confusing and 'wart' including for me. Why should we keep=
 such odd constructs just because of an legacy?</div><div>&nbsp;</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
<br>Other reasons have been given by others in the thread. I remind you esp=
ecially=20
<br>of the one that said that we cannot remove operator--(int) from the lan=
guage=20
<br>for (at least) 15 years, we'll still need to teach new developers of th=
e=20
<br>existing ways. And, of course, there's a cost associated with a porting=
 effort.
<br><br></blockquote><div><br></div><div>I don't think there is many code u=
sing this rare post-fix operator overloading but even if there are - do you=
 think that compiler vendors wouldn't at least warn or even auto-correct th=
is form?</div><div><br></div><div>I believe we should keep the C++ language=
 basis which everyone understands and not try keeping odd design decisions.=
 I'm sure that most of the people don't even know this form even if they ha=
d used it.</div><div><br></div><div>Readability and some 'natural' understa=
nding of the code is more important then compatibility.</div><div><br></div=
><div>Maintaining old code should be responsibility to compilers or some ot=
her software.<br></div><div><br></div><div>Otherwise you'll surely come to =
a situation that understanding the code will took you hours or you will jus=
t give it up as thing become more and more complex. It's easy to keep in mi=
nd a few rules which to know that apply everywhere rather then them plus a =
one hundred of exceptions. For example I know that variables can be declare=
d inside and outside functions and that in 'if' statement I can put an expr=
ession which depending on it's 'bool' representation (not sure in the terms=
&nbsp;used) will either execute the code in it's body or not and I'm absolu=
tely sure in this. But then suddenly I see this code:<br><br></div><div sty=
le=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-col=
or:rgb(250,250,250)"><code><div><span style=3D"color:#008">if</span><span s=
tyle=3D"color:#660">(</span><span style=3D"color:#008">int</span><span styl=
e=3D"color:#000"> a </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> </span><span style=3D"color:#606">Func</span><span style=
=3D"color:#660">())</span><span style=3D"color:#000"> </span><span style=3D=
"color:#660">{</span><span style=3D"color:#000"><br></span><span style=3D"c=
olor:#660">}</span></div></code></div><div><br></div><div>And I'm actually =
really confused. What's the logic here - why an 'if' expression will take a=
 variable declaration and what does it compares?</div><div><br></div><div>B=
etter make programmers life easier and remove such odd things. The simple -=
 the better.</div><div><br></div><div>The case with my pre-fix operator ove=
rloading form. One decent C++ developer which sees this for example:<br><br=
></div><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word=
;background-color:rgb(250,250,250)"><code><div><span style=3D"color:#008">c=
lass</span><span style=3D"color:#000"> T<br></span><span style=3D"color:#66=
0">{</span><span style=3D"color:#000"><br></span><span style=3D"color:#008"=
>public</span><span style=3D"color:#660">:</span><span style=3D"color:#000"=
><br>&nbsp; &nbsp; &nbsp; </span><span style=3D"color:#008">void</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#008">operator</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#660">~++()</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#660">{</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#660">++</span><span style=
=3D"color:#000">a</span><span style=3D"color:#660">;</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#660">}</span><span style=3D"color:=
#000"><br><br>&nbsp; &nbsp; &nbsp; </span><span style=3D"color:#008">void</=
span><span style=3D"color:#000"> </span><span style=3D"color:#008">operator=
</span><span style=3D"color:#000"> </span><span style=3D"color:#660">++()</=
span><span style=3D"color:#000"> </span><span style=3D"color:#660">{</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#660">++</span><spa=
n style=3D"color:#000">a</span><span style=3D"color:#660">;</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#660">}</span><span style=3D=
"color:#000"><br><br>&nbsp; &nbsp; &nbsp; </span><span style=3D"color:#008"=
>int</span><span style=3D"color:#000"> a</span><span style=3D"color:#660">;=
</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">}</=
span></div></code></div><div><br></div><div>Is more likely to deduce the me=
aning of it then using the existing form:<br><br><div style=3D"border:1px s=
olid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250=
)"><code><div><span style=3D"color:#008">class</span><span style=3D"color:#=
000"> T<br></span><span style=3D"color:#660">{</span><span style=3D"color:#=
000"><br></span><span style=3D"color:#008">public</span><span style=3D"colo=
r:#660">:</span><span style=3D"color:#000"><br>&nbsp; &nbsp; &nbsp; </span>=
<span style=3D"color:#008">void</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#008">operator</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#660">++(</span><span style=3D"color:#008">int</span><=
span style=3D"color:#000"> arg</span><span style=3D"color:#660">)</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#660">{</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#660">++</span><span style=
=3D"color:#000">a</span><span style=3D"color:#660">;</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#660">}</span><span style=3D"color:=
#000"><br><br>&nbsp; &nbsp; &nbsp; </span><span style=3D"color:#008">void</=
span><span style=3D"color:#000"> </span><span style=3D"color:#008">operator=
</span><span style=3D"color:#000"> </span><span style=3D"color:#660">++()</=
span><span style=3D"color:#000"> </span><span style=3D"color:#660">{</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#660">++</span><spa=
n style=3D"color:#000">a</span><span style=3D"color:#660">;</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#660">}</span><span style=3D=
"color:#000"><br><br>&nbsp; &nbsp; &nbsp; </span><span style=3D"color:#008"=
>int</span><span style=3D"color:#000"> a</span><span style=3D"color:#660">;=
</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">}</=
span></div></code></div><span style=3D"font-family:monospace;color:rgb(102,=
102,0);background-color:rgb(250,250,250)"><br></span>In which he will surel=
y get confused by this single unused parameter and without investigating th=
e matter I highly doubt that he would get the meaning of it.</div></div></b=
lockquote></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_9_679581600.1425892331265--
------=_Part_8_1709517659.1425892331265--

.

> Wouldn't it be better instead of taking one dummy parameter
> the user-defined function which implements the post-fix ++ or -- operator
> to have declaration similar to the form:
>
>     operator ~--()
>
> I personally think that this is a lot more clear then:
>
>     operator --(int);
>
> In which the only one function parameter of type 'int' will have a dummy
> value of '0' when instanced.
>
> What do you think?

If you ask me, I think "~--" token is a bit ugly. (Also, can it be=20
written as (~)++ and ++(~), with parentheses?)

If I was to reinvent operator overloading syntax, I'd make "this" a=20
reference, not pointer, and chose something like that:

     Class& operator ++this;
     Class  operator this++;
     Class& operator this + const Class& other;

then I'd allow user to specify custom operators with arbitrary priority=20
they want:

     Class& operator this /+++/ const Class& other
         priority (+); //<-- the same as for operator+

and, of course, make operator[] take arbitrary numbers of arguments just=20
like operator():

     Something& operator this [int ix, int iy, int iz];

and all of these with optional "const" and "noexcept" specifiers (where=20
possible).

Your proposal is too small to really make things better, but more=20
fundamental fix will be rejected too. Where is lot of room for=20
improvement in C++, but many of them cannot be done without inventing=20
another language.

=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/.

.

------=_Part_126_1629711590.1425898041034
Content-Type: multipart/alternative;
 boundary="----=_Part_127_1556259292.1425898041034"

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



=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 9 =D0=BC=D0=
=B0=D1=80=D1=82 2015 =D0=B3., 11:32:58 UTC+2, Pavel Kretov =D0=BD=D0=B0=D0=
=BF=D0=B8=D1=81=D0=B0:
>
> > Wouldn't it be better instead of taking one dummy parameter=20
> > the user-defined function which implements the post-fix ++ or --=20
> operator=20
> > to have declaration similar to the form:=20
> >=20
> >     operator ~--()=20
> >=20
> > I personally think that this is a lot more clear then:=20
> >=20
> >     operator --(int);=20
> >=20
> > In which the only one function parameter of type 'int' will have a dumm=
y=20
> > value of '0' when instanced.=20
> >=20
> > What do you think?=20
>
> If you ask me, I think "~--" token is a bit ugly. (Also, can it be=20
> written as (~)++ and ++(~), with parentheses?)=20
>
> If I was to reinvent operator overloading syntax, I'd make "this" a=20
> reference, not pointer, and chose something like that:=20
>
>      Class& operator ++this;=20
>      Class  operator this++;=20
>      Class& operator this + const Class& other;=20
>
> then I'd allow user to specify custom operators with arbitrary priority=
=20
> they want:=20
>
>      Class& operator this /+++/ const Class& other=20
>          priority (+); //<-- the same as for operator+=20
>
> and, of course, make operator[] take arbitrary numbers of arguments just=
=20
> like operator():=20
>
>      Something& operator this [int ix, int iy, int iz];=20
>
> and all of these with optional "const" and "noexcept" specifiers (where=
=20
> possible).=20
>

Those are some nice ideas actually. But maybe instead of 'this' we could=20
use the class name like that:

Class operator Class++()

And also if operator priority for a class can be defined - wouldn't it be=
=20
more appropriate it to be implicitly deduced from the order in which those=
=20
operator overload functions are declared?
=20

>
> Your proposal is too small to really make things better, but more=20
> fundamental fix will be rejected too. Where is lot of room for=20
> improvement in C++, but many of them cannot be done without inventing=20
> another language.=20
>

True that but I believe C++ still got potential and improving it to some=20
extend have purpose.

--=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_127_1556259292.1425898041034
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=
=D0=B8=D0=BA, 9 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 11:32:58 UTC+2, Pave=
l Kretov =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">&gt; Wouldn't it be better instead of taking one dummy para=
meter
<br>&gt; the user-defined function which implements the post-fix ++ or -- o=
perator
<br>&gt; to have declaration similar to the form:
<br>&gt;
<br>&gt; &nbsp; &nbsp; operator ~--()
<br>&gt;
<br>&gt; I personally think that this is a lot more clear then:
<br>&gt;
<br>&gt; &nbsp; &nbsp; operator --(int);
<br>&gt;
<br>&gt; In which the only one function parameter of type 'int' will have a=
 dummy
<br>&gt; value of '0' when instanced.
<br>&gt;
<br>&gt; What do you think?
<br>
<br>If you ask me, I think "~--" token is a bit ugly. (Also, can it be=20
<br>written as (~)++ and ++(~), with parentheses?)
<br>
<br>If I was to reinvent operator overloading syntax, I'd make "this" a=20
<br>reference, not pointer, and chose something like that:
<br>
<br>&nbsp; &nbsp; &nbsp;Class&amp; operator ++this;
<br>&nbsp; &nbsp; &nbsp;Class &nbsp;operator this++;
<br>&nbsp; &nbsp; &nbsp;Class&amp; operator this + const Class&amp; other;
<br>
<br>then I'd allow user to specify custom operators with arbitrary priority=
=20
<br>they want:
<br>
<br>&nbsp; &nbsp; &nbsp;Class&amp; operator this /+++/ const Class&amp; oth=
er
<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;priority (+); //&lt;-- the same as fo=
r operator+
<br>
<br>and, of course, make operator[] take arbitrary numbers of arguments jus=
t=20
<br>like operator():
<br>
<br>&nbsp; &nbsp; &nbsp;Something&amp; operator this [int ix, int iy, int i=
z];
<br>
<br>and all of these with optional "const" and "noexcept" specifiers (where=
=20
<br>possible).
<br></blockquote><div><br></div><div>Those are some nice ideas actually. Bu=
t maybe instead of 'this' we could use the class name like that:<br><br><di=
v class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word=
-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Class</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">operator</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">C=
lass</span><span style=3D"color: #660;" class=3D"styled-by-prettify">++()</=
span></div></code></div><br>And also if operator priority for a class can b=
e defined - wouldn't it be more appropriate it to be implicitly deduced fro=
m the order in which those operator overload functions are declared?<br>&nb=
sp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Your proposal is too small to really make things better, but more=20
<br>fundamental fix will be rejected too. Where is lot of room for=20
<br>improvement in C++, but many of them cannot be done without inventing=
=20
<br>another language.
<br></blockquote><div><br></div><div>True that but I believe C++ still got =
potential and improving it to some extend have purpose.</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_127_1556259292.1425898041034--
------=_Part_126_1629711590.1425898041034--

.

On Monday 09 March 2015 09:54:27 Alexander Nikolov wrote:
> But then suddenly
> I see this code:
>
> if(int a = Func()) {
> }
>
> And I'm actually really confused.

You are confused. I am delighted at the elegance.

--
Marc Mutz <marc.mutz@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions

.

------=_Part_312_1767088347.1425904100428
Content-Type: multipart/alternative;
 boundary="----=_Part_313_1902493666.1425904100428"

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

Honestly, a solution that would have been clear and simple would have been=
=20
to add magic tag types, I will call them `std::prefix` and `std::postfix`=
=20
and add them to a commonly included header, like `<cstddef>`.
The only downside would have been the inclusion of a header, but it would=
=20
have been easy to teach and easy to use (and easy to search for in a file)=
=20
without introducing new keywords.

Le dimanche 8 mars 2015 16:54:41 UTC+1, Alexander Nikolov a =C3=A9crit :
>
> Wouldn't it be better instead of taking one dummy parameter=20
> the user-defined function which implements the post-fix ++ or -- operator=
=20
> to have declaration similar to the form:
>
> operator ~--()
>
> I personally think that this is a lot more clear then:
>
> operator --(int);
>
> In which the only one function parameter of type 'int' will have a dummy=
=20
> value of '0' when instanced.
>
> What do you think?
>
>

--=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_313_1902493666.1425904100428
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Honestly, a solution that would have been clear and simple=
 would have been to add magic tag types, I will call them `std::prefix` and=
 `std::postfix` and add them to a commonly included header, like `&lt;cstdd=
ef&gt;`.<br>The only downside would have been the inclusion of a header, bu=
t it would have been easy to teach and easy to use (and easy to search for =
in a file) without introducing new keywords.<br><br>Le dimanche 8 mars 2015=
 16:54:41 UTC+1, Alexander Nikolov a =C3=A9crit&nbsp;:<blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr">Wouldn't it be better instead of t=
aking one dummy parameter the&nbsp;user-defined function which implements t=
he post-fix ++ or -- operator to have declaration similar to the form:<br><=
br><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;bac=
kground-color:rgb(250,250,250)"><code><div><span style=3D"color:#008">opera=
tor</span><span style=3D"color:#000"> </span><span style=3D"color:#660">~--=
()</span></div></code></div><div><br></div><div>I personally think that thi=
s is a lot more clear then:</div><div><br></div><div><div style=3D"border:1=
px solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,250=
,250)"><code><div><span style=3D"color:#008">operator</span><span style=3D"=
color:#000"> </span><span style=3D"color:#660">--(</span><span style=3D"col=
or:#008">int</span><span style=3D"color:#660">);</span></div></code></div><=
br>In which the only one function parameter of type 'int' will have a dummy=
 value of '0' when instanced.<br><br>What do you think?<br></div><div><br><=
/div></div></blockquote></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_313_1902493666.1425904100428--
------=_Part_312_1767088347.1425904100428--

.

------=_Part_3623_649723901.1425908793633
Content-Type: multipart/alternative;
 boundary="----=_Part_3624_2102742759.1425908793633"

------=_Part_3624_2102742759.1425908793633
Content-Type: text/plain; charset=UTF-8


On Monday, March 9, 2015 at 5:12:11 AM UTC-4, Alexander Nikolov wrote:
>
> The fact is that compatibility with older C++ versions is long gone and
> even worse - C++ code can be legal for both older and newer versions of the
> standard but behave differently which can cause a lot of trouble with
> unexpected results. You can search stackoverflow for hundreds of such
> examples but here is a recent one I was looking at
> <http://stackoverflow.com/questions/23047198/can-c-code-be-valid-in-both-c03-and-c11-but-do-different-things>
> .
>

And in each of those cases, the committee weighed the cost of the change
vs. the impact.

What you're talking about is *syntactic sugar*, nothing more. If a
programmer wants to look up how to overload postfix ++, they can. If a
programmer sees 'operator ++(int)' in a program, they can look up why that
is there and what it's for.

And you yourself said that this will have little impact when you stated
that not many people overload the postfix operators to begin with. Unless
you honestly think that the reason they don't is because they don't know
how. Generally speaking, most people don't want to overload postfix
operators, since they don't need it for their particular application (and
they can have wonky semantics).

So, by your own admission, the impact will be minor. The cost of the change
would be *breaking lots of code* (assuming you would be removing the old
way). That is an unacceptable trade-off.

Is it a language wart? Yes. But quite frankly, C++ has *tons* of these;
this one is way too minor to spend time on.

--

---
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_3624_2102742759.1425908793633
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&nbsp;<iframe style=3D"padding: 0px; position: absolute; t=
op: 0px; left: 0px; width: 600px; height: 188px; visibility: hidden;" frame=
border=3D"0"></iframe><br>On Monday, March 9, 2015 at 5:12:11 AM UTC-4, Ale=
xander Nikolov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">The fact is that compatibility with older C++ versions is long gon=
e and even worse - C++ code can be legal for both older and newer versions =
of the standard but behave differently which can cause a lot of trouble wit=
h unexpected results. You can search&nbsp;stackoverflow for hundreds of suc=
h examples but here is a recent one I was looking <a href=3D"http://stackov=
erflow.com/questions/23047198/can-c-code-be-valid-in-both-c03-and-c11-but-d=
o-different-things" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.=
href=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fques=
tions%2F23047198%2Fcan-c-code-be-valid-in-both-c03-and-c11-but-do-different=
-things\46sa\75D\46sntz\0751\46usg\75AFQjCNF3oQFOjTMgLR5-iUF7ztmo8l2yyg';re=
turn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2=
F%2Fstackoverflow.com%2Fquestions%2F23047198%2Fcan-c-code-be-valid-in-both-=
c03-and-c11-but-do-different-things\46sa\75D\46sntz\0751\46usg\75AFQjCNF3oQ=
FOjTMgLR5-iUF7ztmo8l2yyg';return true;">at</a>.</div></blockquote><div><br>=
And in each of those cases, the committee weighed the cost of the change vs=
.. the impact.<br><br>What you're talking about is <i>syntactic sugar</i>, n=
othing more. If a programmer wants to look up how to overload postfix ++, t=
hey can. If a programmer sees 'operator ++(int)' in a program, they can loo=
k up why that is there and what it's for.<br><br>And you yourself said that=
 this will have little impact when you stated that not many people overload=
 the postfix operators to begin with. Unless you honestly think that the re=
ason they don't is because they don't know how. Generally speaking, most pe=
ople don't want to overload postfix operators, since they don't need it for=
 their particular application (and they can have wonky semantics).<br><br>S=
o, by your own admission, the impact will be minor. The cost of the change =
would be <i>breaking lots of code</i> (assuming you would be removing the o=
ld way). That is an unacceptable trade-off.</div><br>Is it a language wart?=
 Yes. But quite frankly, C++ has <i>tons</i> of these; this one is way too =
minor to spend time on.<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 />

------=_Part_3624_2102742759.1425908793633--
------=_Part_3623_649723901.1425908793633--

.

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

On Mon, Mar 9, 2015 at 12:28 PM, Morwenn <morwenn29@gmail.com> wrote:

> Honestly, a solution that would have been clear and simple would have bee=
n
> to add magic tag types, I will call them `std::prefix` and `std::postfix`
> and add them to a commonly included header, like `<cstddef>`.
>

<cstddef> would be the wrong place=E2=80=94it is a C library.


> The only downside would have been the inclusion of a header, but it would
> have been easy to teach and easy to use (and easy to search for in a file=
)
> without introducing new keywords.
>
> Le dimanche 8 mars 2015 16:54:41 UTC+1, Alexander Nikolov a =C3=A9crit :
>
>> Wouldn't it be better instead of taking one dummy parameter
>> the user-defined function which implements the post-fix ++ or -- operato=
r
>> to have declaration similar to the form:
>>
>>  operator ~--()
>>
>> I personally think that this is a lot more clear then:
>>
>>  operator --(int);
>>
>> In which the only one function parameter of type 'int' will have a dummy
>> value of '0' when instanced.
>>
>> What do you think?
>>
>>  --
>
> ---
> 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/.
>

--=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/.

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

<br>
<div class=3D"gmail_quote">On Mon, Mar 9, 2015 at 12:28 PM, Morwenn <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:morwenn29@gmail.com" target=3D"_blank">mor=
wenn29@gmail.com</a>&gt;</span> wrote:<br>
<blockquote style=3D"BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PA=
DDING-LEFT:1ex" class=3D"gmail_quote">
<div dir=3D"ltr">Honestly, a solution that would have been clear and simple=
 would have been to add magic tag types, I will call them `std::prefix` and=
 `std::postfix` and add them to a commonly included header, like `&lt;cstdd=
ef&gt;`.<br></div></blockquote>
<div>=C2=A0</div>
<div>&lt;cstddef&gt; would be the wrong place=E2=80=94it is a C library.</d=
iv>
<div>=C2=A0</div>
<blockquote style=3D"BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PA=
DDING-LEFT:1ex" class=3D"gmail_quote">
<div dir=3D"ltr">The only downside would have been the inclusion of a heade=
r, but it would have been easy to teach and easy to use (and easy to search=
 for in a file) without introducing new keywords.<br><br>Le dimanche 8 mars=
 2015 16:54:41 UTC+1, Alexander Nikolov a =C3=A9crit=C2=A0:=20
<div>
<div class=3D"h5">
<blockquote style=3D"BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PA=
DDING-LEFT:1ex" class=3D"gmail_quote">
<div dir=3D"ltr">Wouldn&#39;t it be better instead of taking one dummy para=
meter the=C2=A0user-defined function which implements the post-fix ++ or --=
 operator to have declaration similar to the form:<br><br>
<div style=3D"BORDER-BOTTOM:rgb(187,187,187) 1px solid;BORDER-LEFT:rgb(187,=
187,187) 1px solid;BACKGROUND-COLOR:rgb(250,250,250);WORD-WRAP:break-word;B=
ORDER-TOP:rgb(187,187,187) 1px solid;BORDER-RIGHT:rgb(187,187,187) 1px soli=
d"><code>
<div><span style=3D"COLOR:#008">operator</span><span style=3D"COLOR:#000"> =
</span><span style=3D"COLOR:#660">~--()</span></div></code></div>
<div><br></div>
<div>I personally think that this is a lot more clear then:</div>
<div><br></div>
<div>
<div style=3D"BORDER-BOTTOM:rgb(187,187,187) 1px solid;BORDER-LEFT:rgb(187,=
187,187) 1px solid;BACKGROUND-COLOR:rgb(250,250,250);WORD-WRAP:break-word;B=
ORDER-TOP:rgb(187,187,187) 1px solid;BORDER-RIGHT:rgb(187,187,187) 1px soli=
d"><code>
<div><span style=3D"COLOR:#008">operator</span><span style=3D"COLOR:#000"> =
</span><span style=3D"COLOR:#660">--(</span><span style=3D"COLOR:#008">int<=
/span><span style=3D"COLOR:#660">);</span></div></code></div><br>In which t=
he only one function parameter of type &#39;int&#39; will have a dummy valu=
e of &#39;0&#39; when instanced.<br><br>What do you think?<br></div>
<div><br></div></div></blockquote></div></div></div>
<div class=3D"HOEnZb">
<div class=3D"h5">
<p></p>-- <br><br>--- <br>You received this message because you are subscri=
bed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; gr=
oup.<br>To unsubscribe from this group and stop receiving emails from it, s=
end an email to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" tar=
get=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>Visit this group at <a href=3D"ht=
tp://groups.google.com/a/isocpp.org/group/std-proposals/" target=3D"_blank"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br></div><=
/div></blockquote></div><br>

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

--001a11457f9659a5010510dbc7e4--

.

2015-03-09 15:23 GMT+01:00 Douglas Boffey <douglas.boffey@gmail.com>:
>
> On Mon, Mar 9, 2015 at 12:28 PM, Morwenn <morwenn29@gmail.com> wrote:
>>
>> Honestly, a solution that would have been clear and simple would have been
>> to add magic tag types, I will call them `std::prefix` and `std::postfix`
>> and add them to a commonly included header, like `<cstddef>`.
>
> <cstddef> would be the wrong place--it is a C library.

That is not quite right: <cstddef> is part of C++ only and could
contain additional or different entities compared to <stddef.h>.
Another comparable example is the fact that <ccomplex> is specified to
behave as if it included <complex>.

- Daniel

--

---
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_196_1453354364.1425913835728
Content-Type: multipart/alternative;
 boundary="----=_Part_197_1047794770.1425913835728"

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



Le lundi 9 mars 2015 15:23:33 UTC+1, Douglas Boffey a =C3=A9crit :
>
>
> On Mon, Mar 9, 2015 at 12:28 PM, Morwenn <morw...@gmail.com <javascript:>=
>=20
> wrote:
>
>> Honestly, a solution that would have been clear and simple would have=20
>> been to add magic tag types, I will call them `std::prefix` and=20
>> `std::postfix` and add them to a commonly included header, like `<cstdde=
f>`.
>>
> =20
> <cstddef> would be the wrong place=E2=80=94it is a C library.
>

It didn't stop people from adding std::nullptr_t to it.

--=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_197_1047794770.1425913835728
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Le lundi 9 mars 2015 15:23:33 UTC+1, Douglas Boffe=
y a =C3=A9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>
<div class=3D"gmail_quote">On Mon, Mar 9, 2015 at 12:28 PM, Morwenn <span d=
ir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"lEEPiBgtmmAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascrip=
t:';return true;" onclick=3D"this.href=3D'javascript:';return true;">morw..=
..@gmail.com</a>&gt;</span> wrote:<br>
<blockquote style=3D"BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PA=
DDING-LEFT:1ex" class=3D"gmail_quote">
<div dir=3D"ltr">Honestly, a solution that would have been clear and simple=
 would have been to add magic tag types, I will call them `std::prefix` and=
 `std::postfix` and add them to a commonly included header, like `&lt;cstdd=
ef&gt;`.<br></div></blockquote>
<div>&nbsp;</div>
<div>&lt;cstddef&gt; would be the wrong place=E2=80=94it is a C library.</d=
iv></div></blockquote><div><br>It didn't stop people from adding <span styl=
e=3D"font-family: courier new,monospace;">std::nullptr_t</span> to it.<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_197_1047794770.1425913835728--
------=_Part_196_1453354364.1425913835728--

.

------=_Part_672_1767916008.1425915261374
Content-Type: multipart/alternative;
 boundary="----=_Part_673_780606564.1425915261374"

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



=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 9 =D0=BC=D0=
=B0=D1=80=D1=82 2015 =D0=B3., 15:46:33 UTC+2, Nicol Bolas =D0=BD=D0=B0=D0=
=BF=D0=B8=D1=81=D0=B0:
>
> =20
> On Monday, March 9, 2015 at 5:12:11 AM UTC-4, Alexander Nikolov wrote:
>>
>> The fact is that compatibility with older C++ versions is long gone and=
=20
>> even worse - C++ code can be legal for both older and newer versions of =
the=20
>> standard but behave differently which can cause a lot of trouble with=20
>> unexpected results. You can search stackoverflow for hundreds of such=20
>> examples but here is a recent one I was looking at=20
>> <http://stackoverflow.com/questions/23047198/can-c-code-be-valid-in-both=
-c03-and-c11-but-do-different-things>
>> .
>>
>
> And in each of those cases, the committee weighed the cost of the change=
=20
> vs. the impact.
>
> What you're talking about is *syntactic sugar*, nothing more. If a=20
> programmer wants to look up how to overload postfix ++, they can. If a=20
> programmer sees 'operator ++(int)' in a program, they can look up why tha=
t=20
> is there and what it's for.
>
> And you yourself said that this will have little impact when you stated=
=20
> that not many people overload the postfix operators to begin with. Unless=
=20
> you honestly think that the reason they don't is because they don't know=
=20
> how. Generally speaking, most people don't want to overload postfix=20
> operators, since they don't need it for their particular application (and=
=20
> they can have wonky semantics).
>
> So, by your own admission, the impact will be minor. The cost of the=20
> change would be *breaking lots of code* (assuming you would be removing=
=20
> the old way). That is an unacceptable trade-off.
>
=20

In the same time 'most people don't want to overload postfix operators' and=
=20
'the change would be *breaking lots of code*'. This doesn't seems very=20
logical to me. In every case I presented my statement about this question.

I agree that this change would be very small to consider itself but if=20
someone decide to look up all C++ odd constructs and purpose a fix=20
including this one then it will be a lot bigger and meaningful. Maybe it=20
could also include some resolution to the misleading function and array=20
types as function parameters and return-value. And yep - it's a syntactic=
=20
sugar because people like so - we aren't machines after all.

--=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_673_780606564.1425915261374
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=
=D0=B8=D0=BA, 9 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 15:46:33 UTC+2, Nico=
l Bolas =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr">&nbsp;<br>On Monday, March 9, 2015 at 5:12:=
11 AM UTC-4, Alexander Nikolov wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr">The fact is that compatibility with older C++ versions i=
s long gone and even worse - C++ code can be legal for both older and newer=
 versions of the standard but behave differently which can cause a lot of t=
rouble with unexpected results. You can search&nbsp;stackoverflow for hundr=
eds of such examples but here is a recent one I was looking <a href=3D"http=
://stackoverflow.com/questions/23047198/can-c-code-be-valid-in-both-c03-and=
-c11-but-do-different-things" rel=3D"nofollow" target=3D"_blank" onmousedow=
n=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.=
com%2Fquestions%2F23047198%2Fcan-c-code-be-valid-in-both-c03-and-c11-but-do=
-different-things\46sa\75D\46sntz\0751\46usg\75AFQjCNF3oQFOjTMgLR5-iUF7ztmo=
8l2yyg';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\7=
5http%3A%2F%2Fstackoverflow.com%2Fquestions%2F23047198%2Fcan-c-code-be-vali=
d-in-both-c03-and-c11-but-do-different-things\46sa\75D\46sntz\0751\46usg\75=
AFQjCNF3oQFOjTMgLR5-iUF7ztmo8l2yyg';return true;">at</a>.</div></blockquote=
><div><br>And in each of those cases, the committee weighed the cost of the=
 change vs. the impact.<br><br>What you're talking about is <i>syntactic su=
gar</i>, nothing more. If a programmer wants to look up how to overload pos=
tfix ++, they can. If a programmer sees 'operator ++(int)' in a program, th=
ey can look up why that is there and what it's for.<br><br>And you yourself=
 said that this will have little impact when you stated that not many peopl=
e overload the postfix operators to begin with. Unless you honestly think t=
hat the reason they don't is because they don't know how. Generally speakin=
g, most people don't want to overload postfix operators, since they don't n=
eed it for their particular application (and they can have wonky semantics)=
..<br><br>So, by your own admission, the impact will be minor. The cost of t=
he change would be <i>breaking lots of code</i> (assuming you would be remo=
ving the old way). That is an unacceptable trade-off.</div></div></blockquo=
te><div>&nbsp;</div><div><br></div><div>In the same time 'most people don't=
 want to overload postfix operators' and 'the change would be&nbsp;<i>break=
ing lots of code</i>'. This doesn't seems very logical to me. In every case=
 I presented my statement about this question.</div><div><br></div><div>I a=
gree that this change would be very small to consider itself but if someone=
 decide to look up all C++ odd constructs and purpose a fix including this =
one then it will be a lot bigger and meaningful. Maybe it could also includ=
e some resolution to the misleading function and array types as function pa=
rameters and return-value. And yep - it's a syntactic sugar because people =
like so - we aren't machines after all.</div><div><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_673_780606564.1425915261374--
------=_Part_672_1767916008.1425915261374--

.

------=_Part_650_2097653019.1425915518854
Content-Type: multipart/alternative;
 boundary="----=_Part_651_15257534.1425915518854"

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

Honestly, I'm sick of magic types. I expect when something can be defined=
=20
in the standard library - that I can define it myself either. And actually=
=20
this was the case years ago - now all those magic stuff appeared and=20
everything became even more messed up.

=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 9 =D0=BC=D0=
=B0=D1=80=D1=82 2015 =D0=B3., 14:28:20 UTC+2, Morwenn =D0=BD=D0=B0=D0=BF=D0=
=B8=D1=81=D0=B0:
>
> Honestly, a solution that would have been clear and simple would have bee=
n=20
> to add magic tag types, I will call them `std::prefix` and `std::postfix`=
=20
> and add them to a commonly included header, like `<cstddef>`.
> The only downside would have been the inclusion of a header, but it would=
=20
> have been easy to teach and easy to use (and easy to search for in a file=
)=20
> without introducing new keywords.
>
> Le dimanche 8 mars 2015 16:54:41 UTC+1, Alexander Nikolov a =C3=A9crit :
>>
>> Wouldn't it be better instead of taking one dummy parameter=20
>> the user-defined function which implements the post-fix ++ or -- operato=
r=20
>> to have declaration similar to the form:
>>
>> operator ~--()
>>
>> I personally think that this is a lot more clear then:
>>
>> operator --(int);
>>
>> In which the only one function parameter of type 'int' will have a dummy=
=20
>> value of '0' when instanced.
>>
>> What do you think?
>>
>>

--=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_651_15257534.1425915518854
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Honestly, I'm sick of magic types. I expect when something=
 can be defined in the standard library - that I can define it myself eithe=
r. And actually this was the case years ago - now all those magic stuff app=
eared and everything became even more messed up.<br><br>=D0=BF=D0=BE=D0=BD=
=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 9 =D0=BC=D0=B0=D1=80=D1=82 2015=
 =D0=B3., 14:28:20 UTC+2, Morwenn =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Honestly, a solut=
ion that would have been clear and simple would have been to add magic tag =
types, I will call them `std::prefix` and `std::postfix` and add them to a =
commonly included header, like `&lt;cstddef&gt;`.<br>The only downside woul=
d have been the inclusion of a header, but it would have been easy to teach=
 and easy to use (and easy to search for in a file) without introducing new=
 keywords.<br><br>Le dimanche 8 mars 2015 16:54:41 UTC+1, Alexander Nikolov=
 a =C3=A9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
">Wouldn't it be better instead of taking one dummy parameter the&nbsp;user=
-defined function which implements the post-fix ++ or -- operator to have d=
eclaration similar to the form:<br><br><div style=3D"border:1px solid rgb(1=
87,187,187);word-wrap:break-word;background-color:rgb(250,250,250)"><code><=
div><span style=3D"color:#008">operator</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#660">~--()</span></div></code></div><div><br></=
div><div>I personally think that this is a lot more clear then:</div><div><=
br></div><div><div style=3D"border:1px solid rgb(187,187,187);word-wrap:bre=
ak-word;background-color:rgb(250,250,250)"><code><div><span style=3D"color:=
#008">operator</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">--(</span><span style=3D"color:#008">int</span><span style=3D"color=
:#660">);</span></div></code></div><br>In which the only one function param=
eter of type 'int' will have a dummy value of '0' when instanced.<br><br>Wh=
at do you think?<br></div><div><br></div></div></blockquote></div></blockqu=
ote></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_651_15257534.1425915518854--
------=_Part_650_2097653019.1425915518854--

.

------=_Part_768_1201991955.1425916241648
Content-Type: multipart/alternative;
 boundary="----=_Part_769_500120356.1425916241649"

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

On Monday, March 9, 2015 at 11:34:21 AM UTC-4, Alexander Nikolov wrote:
>
>
>
> =D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 9 =D0=BC=D0=
=B0=D1=80=D1=82 2015 =D0=B3., 15:46:33 UTC+2, Nicol Bolas =D0=BD=D0=B0=D0=
=BF=D0=B8=D1=81=D0=B0:
>>
>> =20
>> On Monday, March 9, 2015 at 5:12:11 AM UTC-4, Alexander Nikolov wrote:
>>>
>>> The fact is that compatibility with older C++ versions is long gone and=
=20
>>> even worse - C++ code can be legal for both older and newer versions of=
 the=20
>>> standard but behave differently which can cause a lot of trouble with=
=20
>>> unexpected results. You can search stackoverflow for hundreds of such=
=20
>>> examples but here is a recent one I was looking at=20
>>> <http://stackoverflow.com/questions/23047198/can-c-code-be-valid-in-bot=
h-c03-and-c11-but-do-different-things>
>>> .
>>>
>>
>> And in each of those cases, the committee weighed the cost of the change=
=20
>> vs. the impact.
>>
>> What you're talking about is *syntactic sugar*, nothing more. If a=20
>> programmer wants to look up how to overload postfix ++, they can. If a=
=20
>> programmer sees 'operator ++(int)' in a program, they can look up why th=
at=20
>> is there and what it's for.
>>
>> And you yourself said that this will have little impact when you stated=
=20
>> that not many people overload the postfix operators to begin with. Unles=
s=20
>> you honestly think that the reason they don't is because they don't know=
=20
>> how. Generally speaking, most people don't want to overload postfix=20
>> operators, since they don't need it for their particular application (an=
d=20
>> they can have wonky semantics).
>>
>> So, by your own admission, the impact will be minor. The cost of the=20
>> change would be *breaking lots of code* (assuming you would be removing=
=20
>> the old way). That is an unacceptable trade-off.
>>
> =20
>
> In the same time 'most people don't want to overload postfix operators'=
=20
> and 'the change would be *breaking lots of code*'. This doesn't seems=20
> very logical to me.
>

Why not? Just because something is fairly rare doesn't mean that removing=
=20
it won't have a big impact.

Qt is very big, for example, with tens of thousands of types. But if *even=
=20
one* of those types overloads the postfix ++, then your change will have=20
broken the *entire* Qt library.
=20

> In every case I presented my statement about this question.
>
> I agree that this change would be very small to consider itself but if=20
> someone decide to look up all C++ odd constructs and purpose a fix=20
> including this one then it will be a lot bigger and meaningful.
>

And it would break *even more code*. And thus have a far greater chance of=
=20
being rejected.

Really, it's best to make your peace with C++ as it is, rather than hope=20
that it will magically transform itself into what it could be.

--=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_769_500120356.1425916241649
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, March 9, 2015 at 11:34:21 AM UTC-4, Alexander N=
ikolov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<br><br>=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 9 =D0=
=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 15:46:33 UTC+2, Nicol Bolas =D0=BD=D0=
=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr">&nbsp;<br>On Monday, March 9, 2015 at 5:12:11 AM UTC-4, Alexander=
 Nikolov wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">The=
 fact is that compatibility with older C++ versions is long gone and even w=
orse - C++ code can be legal for both older and newer versions of the stand=
ard but behave differently which can cause a lot of trouble with unexpected=
 results. You can search&nbsp;stackoverflow for hundreds of such examples b=
ut here is a recent one I was looking <a href=3D"http://stackoverflow.com/q=
uestions/23047198/can-c-code-be-valid-in-both-c03-and-c11-but-do-different-=
things" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http=
://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fquestions%2F2304=
7198%2Fcan-c-code-be-valid-in-both-c03-and-c11-but-do-different-things\46sa=
\75D\46sntz\0751\46usg\75AFQjCNF3oQFOjTMgLR5-iUF7ztmo8l2yyg';return true;" =
onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackove=
rflow.com%2Fquestions%2F23047198%2Fcan-c-code-be-valid-in-both-c03-and-c11-=
but-do-different-things\46sa\75D\46sntz\0751\46usg\75AFQjCNF3oQFOjTMgLR5-iU=
F7ztmo8l2yyg';return true;">at</a>.</div></blockquote><div><br>And in each =
of those cases, the committee weighed the cost of the change vs. the impact=
..<br><br>What you're talking about is <i>syntactic sugar</i>, nothing more.=
 If a programmer wants to look up how to overload postfix ++, they can. If =
a programmer sees 'operator ++(int)' in a program, they can look up why tha=
t is there and what it's for.<br><br>And you yourself said that this will h=
ave little impact when you stated that not many people overload the postfix=
 operators to begin with. Unless you honestly think that the reason they do=
n't is because they don't know how. Generally speaking, most people don't w=
ant to overload postfix operators, since they don't need it for their parti=
cular application (and they can have wonky semantics).<br><br>So, by your o=
wn admission, the impact will be minor. The cost of the change would be <i>=
breaking lots of code</i> (assuming you would be removing the old way). Tha=
t is an unacceptable trade-off.</div></div></blockquote><div>&nbsp;</div><d=
iv><br></div><div>In the same time 'most people don't want to overload post=
fix operators' and 'the change would be&nbsp;<i>breaking lots of code</i>'.=
 This doesn't seems very logical to me.</div></div></blockquote><div><br>Wh=
y not? Just because something is fairly rare doesn't mean that removing it =
won't have a big impact.<br><br>Qt is very big, for example, with tens of t=
housands of types. But if <i>even one</i> of those types overloads the post=
fix ++, then your change will have broken the <i>entire</i> Qt library.<br>=
&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div>In every case I presented my statement about this question.</div><div><=
br></div><div>I agree that this change would be very small to consider itse=
lf but if someone decide to look up all C++ odd constructs and purpose a fi=
x including this one then it will be a lot bigger and meaningful.</div></di=
v></blockquote><div><br>And it would break <i>even more code</i>. And thus =
have a far greater chance of being rejected.<br><br>Really, it's best to ma=
ke your peace with C++ as it is, rather than hope that it will magically tr=
ansform itself into what it could be.</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 />

------=_Part_769_500120356.1425916241649--
------=_Part_768_1201991955.1425916241648--

.

------=_Part_2187_1319652417.1425916495759
Content-Type: multipart/alternative;
 boundary="----=_Part_2188_187066303.1425916495759"

------=_Part_2188_187066303.1425916495759
Content-Type: text/plain; charset=UTF-8

On Monday, March 9, 2015 at 11:38:38 AM UTC-4, Alexander Nikolov wrote:
>
> Honestly, I'm sick of magic types. I expect when something can be defined
> in the standard library - that I can define it myself either.
>

Why would you expect that? If a function takes a std::string, you can't
give it something other than a std::string (unless there's an overload for
it). That's not a "magic type"; it's a strongly-typed language. You've
never been able to "define it myself", unless the type itself is extensible.

More importantly, what does it *matter* if you can't replicate the behavior
of "magic type"? How does that negatively impact your code?

--

---
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_2188_187066303.1425916495759
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, March 9, 2015 at 11:38:38 AM UTC-4, Alexander N=
ikolov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
Honestly, I'm sick of magic types. I expect when something can be defined i=
n the standard library - that I can define it myself either.</div></blockqu=
ote><div><br>Why would you expect that? If a function takes a std::string, =
you can't give it something other than a std::string (unless there's an ove=
rload for it). That's not a "magic type"; it's a strongly-typed language. Y=
ou've never been able to "define it myself", unless the type itself is exte=
nsible.<br><br>More importantly, what does it <i>matter</i> if you can't re=
plicate the behavior of "magic type"? How does that negatively impact your =
code?<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_2188_187066303.1425916495759--
------=_Part_2187_1319652417.1425916495759--

.

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

On 8 March 2015 at 10:54, Alexander Nikolov <sasho648@mail.bg> wrote:

> Wouldn't it be better instead of taking one dummy parameter
> the user-defined function which implements the post-fix ++ or -- operator
> to have declaration similar to the form:
>
> operator ~--()
>
> I personally think that this is a lot more clear then:
>
> operator --(int);
>

I don't get it.  Why is changing from one obscure syntax to another equally
obscure syntax making anything better?
--
 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/.

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

<div dir=3D"ltr">On 8 March 2015 at 10:54, Alexander Nikolov <span dir=3D"l=
tr">&lt;<a href=3D"mailto:sasho648@mail.bg" target=3D"_blank">sasho648@mail=
..bg</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Wouldn&#39;t it be =
better instead of taking one dummy parameter the=C2=A0user-defined function=
 which implements the post-fix ++ or -- operator to have declaration simila=
r to the form:<br><br><div style=3D"border:1px solid rgb(187,187,187);word-=
wrap:break-word;background-color:rgb(250,250,250)"><code><div><span style=
=3D"color:#008">operator</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#660">~--()</span></div></code></div><div><br></div><div>I pers=
onally think that this is a lot more clear then:</div><div><br></div><div><=
div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;backgro=
und-color:rgb(250,250,250)"><code><div><span style=3D"color:#008">operator<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">--(</sp=
an><span style=3D"color:#008">int</span><span style=3D"color:#660">);</span=
></div></code></div></div></div></blockquote><div><br></div><div>I don&#39;=
t get it.=C2=A0 Why is changing from one obscure syntax to another equally =
obscure syntax making anything better?<br clear=3D"all"></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@ev=
iloverlord.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 />

--001a11c1f22885bb320510dd2c3e--

.

On Monday 09 March 2015 08:50:41 Nicol Bolas wrote:
> Qt is very big, for example, with tens of thousands of types. But if *even
> one* of those types overloads the postfix ++, then your change will have
> broken the *entire* Qt library.

$ git submodule foreach "git grep 'operator *++ *(int' || true" | wc -l
108

This is also catching some documentation headers about the postfix increment
operator, but I left them there since they are part of the porting effort too.

Add to the fact that we need to change qdoc and doxygen to understand the new
operator too.
--
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_632_1312509999.1425917697138
Content-Type: multipart/alternative;
 boundary="----=_Part_633_403531209.1425917697138"

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

This wasn't the best solution yet it seems but you can check the one=20
suggested by 'Pavel Kretov' which perhaps looks better.

=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 9 =D0=BC=D0=
=B0=D1=80=D1=82 2015 =D0=B3., 18:03:25 UTC+2, Nevin ":-)" Liber =D0=BD=D0=
=B0=D0=BF=D0=B8=D1=81=D0=B0:
>
> On 8 March 2015 at 10:54, Alexander Nikolov <sash...@mail.bg <javascript:=
>
> > wrote:
>
>> Wouldn't it be better instead of taking one dummy parameter=20
>> the user-defined function which implements the post-fix ++ or -- operato=
r=20
>> to have declaration similar to the form:
>>
>> operator ~--()
>>
>> I personally think that this is a lot more clear then:
>>
>> operator --(int);
>>
>
> I don't get it.  Why is changing from one obscure syntax to another=20
> equally obscure syntax making anything better?
> --=20
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>  (847)=
=20
> 691-1404
> =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_633_403531209.1425917697138
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">This wasn't the best solution yet it seems but you can che=
ck the one suggested by 'Pavel Kretov' which perhaps looks better.<br><br>=
=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 9 =D0=BC=D0=
=B0=D1=80=D1=82 2015 =D0=B3., 18:03:25 UTC+2, Nevin ":-)" Liber =D0=BD=D0=
=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr">On 8 March 2015 at 10:54, Alexander Nikolov <span dir=3D"ltr=
">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"PW=
pVi_6tP7cJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';retur=
n true;" onclick=3D"this.href=3D'javascript:';return true;">sash...@mail.bg=
</a>&gt;</span> wrote:<br><div><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">Wouldn't it be better instead of taking one =
dummy parameter the&nbsp;user-defined function which implements the post-fi=
x ++ or -- operator to have declaration similar to the form:<br><br><div st=
yle=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-co=
lor:rgb(250,250,250)"><code><div><span style=3D"color:#008">operator</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#660">~--()</span><=
/div></code></div><div><br></div><div>I personally think that this is a lot=
 more clear then:</div><div><br></div><div><div style=3D"border:1px solid r=
gb(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250)"><co=
de><div><span style=3D"color:#008">operator</span><span style=3D"color:#000=
"> </span><span style=3D"color:#660">--(</span><span style=3D"color:#008">i=
nt</span><span style=3D"color:#660">);</span></div></code></div></div></div=
></blockquote><div><br></div><div>I don't get it.&nbsp; Why is changing fro=
m one obscure syntax to another equally obscure syntax making anything bett=
er?<br clear=3D"all"></div></div>-- <br><div>&nbsp;Nevin ":-)" Liber&nbsp; =
&lt;mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"PWpVi_6tP7cJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:'=
;return true;" onclick=3D"this.href=3D'javascript:';return true;">ne...@evi=
loverlord.com</a><wbr>&gt;&nbsp; (847) 691-1404</div>
</div></div>
</blockquote></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_633_403531209.1425917697138--
------=_Part_632_1312509999.1425917697138--

.

On 2015-03-09 08:28, Morwenn wrote:
> Honestly, a solution that would have been clear and simple would have been
> to add magic tag types, I will call them `std::prefix` and `std::postfix`
> and add them to a commonly included header, like `<cstddef>`.

  namespace std
  {
    using prefix = void;
    using postfix = int;
  }

(Not tested; postfix should work, not sure about prefix...)

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

.

------=_Part_783_37332536.1425921721743
Content-Type: multipart/alternative;
 boundary="----=_Part_784_382707628.1425921721743"

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

It works :O. You must be the master. But the mechanism it uses include=20
another odd feature of the language which is the useless use of a single=20
unnamed 'void' parameter. It seems that the language strange features are=
=20
completing each other - lol.

=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 9 =D0=BC=D0=
=B0=D1=80=D1=82 2015 =D0=B3., 19:02:28 UTC+2, Matthew Woehlke =D0=BD=D0=B0=
=D0=BF=D0=B8=D1=81=D0=B0:
>
> On 2015-03-09 08:28, Morwenn wrote:=20
> > Honestly, a solution that would have been clear and simple would have=
=20
> been=20
> > to add magic tag types, I will call them `std::prefix` and=20
> `std::postfix`=20
> > and add them to a commonly included header, like `<cstddef>`.=20
>
>   namespace std=20
>   {=20
>     using prefix =3D void;=20
>     using postfix =3D int;=20
>   }=20
>
> (Not tested; postfix should work, not sure about prefix...)=20
>
> --=20
> Matthew=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_784_382707628.1425921721743
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It works :O. You must be the master. But the mechanism it =
uses include another odd feature of the language which is the useless use o=
f a single unnamed 'void' parameter. It seems that the language strange fea=
tures are completing each other - lol.<br><br>=D0=BF=D0=BE=D0=BD=D0=B5=D0=
=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 9 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3.,=
 19:02:28 UTC+2, Matthew Woehlke =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">On 2015-03-09 08:28, Morwenn wrote:
<br>&gt; Honestly, a solution that would have been clear and simple would h=
ave been=20
<br>&gt; to add magic tag types, I will call them `std::prefix` and `std::p=
ostfix`=20
<br>&gt; and add them to a commonly included header, like `&lt;cstddef&gt;`=
..
<br>
<br>&nbsp; namespace std
<br>&nbsp; {
<br>&nbsp; &nbsp; using prefix =3D void;
<br>&nbsp; &nbsp; using postfix =3D int;
<br>&nbsp; }
<br>
<br>(Not tested; postfix should work, not sure about prefix...)
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></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_784_382707628.1425921721743--
------=_Part_783_37332536.1425921721743--

.

------=_Part_4296_1176445179.1425943196157
Content-Type: multipart/alternative;
 boundary="----=_Part_4297_632185524.1425943196158"

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



On Monday, March 9, 2015 at 1:22:01 PM UTC-4, Alexander Nikolov wrote:
>
> It works :O. You must be the master. But the mechanism it uses include=20
> another odd feature of the language which is the useless use of a single=
=20
> unnamed 'void' parameter. It seems that the language=20
>
strange features are completing each other - lol.
>

Your problem, as I understood it, was with how it looked to the user. Well,=
=20
to the user it looks like:

void operator++(std::prefix);

They don't see the 'void' there. It's not "useless"; it's providing exactly=
=20
the semantic information you want.
=20

>
> =D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 9 =D0=BC=D0=
=B0=D1=80=D1=82 2015 =D0=B3., 19:02:28 UTC+2, Matthew Woehlke =D0=BD=D0=B0=
=D0=BF=D0=B8=D1=81=D0=B0:
>>
>> On 2015-03-09 08:28, Morwenn wrote:=20
>> > Honestly, a solution that would have been clear and simple would have=
=20
>> been=20
>> > to add magic tag types, I will call them `std::prefix` and=20
>> `std::postfix`=20
>> > and add them to a commonly included header, like `<cstddef>`.=20
>>
>>   namespace std=20
>>   {=20
>>     using prefix =3D void;=20
>>     using postfix =3D int;=20
>>   }=20
>>
>> (Not tested; postfix should work, not sure about prefix...)=20
>>
>> --=20
>> Matthew=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_4297_632185524.1425943196158
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, March 9, 2015 at 1:22:01 PM UTC-4, Alex=
ander Nikolov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">It works :O. You must be the master. But the mechanism it uses inc=
lude another odd feature of the language which is the useless use of a sing=
le unnamed 'void' parameter. It seems that the language </div></blockquote>=
<div></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">st=
range features are completing each other - lol.<br></div></blockquote><div>=
<br>Your problem, as I understood it, was with how it looked to the user. W=
ell, to the user it looks like:<br><br>void operator++(std::prefix);<br><br=
>They don't see the 'void' there. It's not "useless"; it's providing exactl=
y the semantic information you want.<br></div><div>&nbsp;</div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br>=D0=BF=D0=BE=D0=BD=D0=
=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 9 =D0=BC=D0=B0=D1=80=D1=82 2015 =
=D0=B3., 19:02:28 UTC+2, Matthew Woehlke =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=
=B0:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex">On 2015-03-09 08:28, Morwenn wr=
ote:
<br>&gt; Honestly, a solution that would have been clear and simple would h=
ave been=20
<br>&gt; to add magic tag types, I will call them `std::prefix` and `std::p=
ostfix`=20
<br>&gt; and add them to a commonly included header, like `&lt;cstddef&gt;`=
..
<br>
<br>&nbsp; namespace std
<br>&nbsp; {
<br>&nbsp; &nbsp; using prefix =3D void;
<br>&nbsp; &nbsp; using postfix =3D int;
<br>&nbsp; }
<br>
<br>(Not tested; postfix should work, not sure about prefix...)
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></div></blockquote></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_4297_632185524.1425943196158--
------=_Part_4296_1176445179.1425943196157--

.

------=_Part_4223_908676127.1425944606771
Content-Type: multipart/alternative;
 boundary="----=_Part_4224_1363452672.1425944606771"

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

It is useless in general. Why would you want to write:

<func-name>(void)

Instead of:

<func-name>()


The suggested solution have very big draw-backs however:


   1. Existing odd-looking code will still be still supported and thus=20
   eventually being written again.
   2. As those type-aliases are common - some 'smart' guy could start using=
=20
   them instead of 'void' and 'int' which will be a lot of strange too.



=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 10 =D0=BC=D0=B0=D1=80=D1=82 201=
5 =D0=B3., 1:19:56 UTC+2, Nicol Bolas =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:
>
>
>
> On Monday, March 9, 2015 at 1:22:01 PM UTC-4, Alexander Nikolov wrote:
>>
>> It works :O. You must be the master. But the mechanism it uses include=
=20
>> another odd feature of the language which is the useless use of a single=
=20
>> unnamed 'void' parameter. It seems that the language=20
>>
> strange features are completing each other - lol.
>>
>
> Your problem, as I understood it, was with how it looked to the user.=20
> Well, to the user it looks like:
>
> void operator++(std::prefix);
>
> They don't see the 'void' there. It's not "useless"; it's providing=20
> exactly the semantic information you want.
> =20
>
>>
>> =D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 9 =D0=BC=
=D0=B0=D1=80=D1=82 2015 =D0=B3., 19:02:28 UTC+2, Matthew Woehlke =D0=BD=D0=
=B0=D0=BF=D0=B8=D1=81=D0=B0:
>>>
>>> On 2015-03-09 08:28, Morwenn wrote:=20
>>> > Honestly, a solution that would have been clear and simple would have=
=20
>>> been=20
>>> > to add magic tag types, I will call them `std::prefix` and=20
>>> `std::postfix`=20
>>> > and add them to a commonly included header, like `<cstddef>`.=20
>>>
>>>   namespace std=20
>>>   {=20
>>>     using prefix =3D void;=20
>>>     using postfix =3D int;=20
>>>   }=20
>>>
>>> (Not tested; postfix should work, not sure about prefix...)=20
>>>
>>> --=20
>>> Matthew=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_4224_1363452672.1425944606771
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It is useless in general. Why would you want to write:<div=
><br></div><div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(1=
87, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 250);=
"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"=
color: #008;" class=3D"styled-by-prettify">&lt;func-name&gt;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">(void)</span></div></code=
></div><br>Instead of:<br><br><div class=3D"prettyprint" style=3D"border: 1=
px solid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(2=
50, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><=
span style=3D"color: #008;" class=3D"styled-by-prettify">&lt;func-name&gt;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">()</span></=
div></code></div><div><br></div><div><br></div><div>The suggested solution =
have very big draw-backs however:</div><div><br></div><div><ol><li><span st=
yle=3D"line-height: normal;">Existing odd-looking code will still be still =
supported and thus eventually being written again.</span></li><li><span sty=
le=3D"line-height: normal;">As those type-aliases are common - some 'smart'=
 guy could start using them instead of 'void' and 'int' which will be a lot=
 of strange too.</span></li></ol></div><br><br>=D0=B2=D1=82=D0=BE=D1=80=D0=
=BD=D0=B8=D0=BA, 10 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 1:19:56 UTC+2, N=
icol Bolas =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><br><br>On Monday, March 9, 2015 at 1:22=
:01 PM UTC-4, Alexander Nikolov wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr">It works :O. You must be the master. But the mechanism =
it uses include another odd feature of the language which is the useless us=
e of a single unnamed 'void' parameter. It seems that the language </div></=
blockquote><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr">strange features are completing each other - lol.<br></div></blockquote=
><div><br>Your problem, as I understood it, was with how it looked to the u=
ser. Well, to the user it looks like:<br><br>void operator++(std::prefix);<=
br><br>They don't see the 'void' there. It's not "useless"; it's providing =
exactly the semantic information you want.<br></div><div>&nbsp;</div><block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>=D0=BF=D0=BE=D0=BD=
=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 9 =D0=BC=D0=B0=D1=80=D1=82 2015=
 =D0=B3., 19:02:28 UTC+2, Matthew Woehlke =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=
=B0:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex">On 2015-03-09 08:28, Morwenn wr=
ote:
<br>&gt; Honestly, a solution that would have been clear and simple would h=
ave been=20
<br>&gt; to add magic tag types, I will call them `std::prefix` and `std::p=
ostfix`=20
<br>&gt; and add them to a commonly included header, like `&lt;cstddef&gt;`=
..
<br>
<br>&nbsp; namespace std
<br>&nbsp; {
<br>&nbsp; &nbsp; using prefix =3D void;
<br>&nbsp; &nbsp; using postfix =3D int;
<br>&nbsp; }
<br>
<br>(Not tested; postfix should work, not sure about prefix...)
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></div></blockquote></div></blockquote></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_4224_1363452672.1425944606771--
------=_Part_4223_908676127.1425944606771--

.

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

It sounds like you object to the idea of having language features that make
it possible to write confusing code. If that's the case, I suggest you
become a Java programmer instead of trying to change C++.

On Mon, Mar 9, 2015 at 4:43 PM, Alexander Nikolov <sasho648@mail.bg> wrote:

> It is useless in general. Why would you want to write:
>
> <func-name>(void)
>
> Instead of:
>
> <func-name>()
>
>
> The suggested solution have very big draw-backs however:
>
>
>    1. Existing odd-looking code will still be still supported and thus
>    eventually being written again.
>    2. As those type-aliases are common - some 'smart' guy could start
>    using them instead of 'void' and 'int' which will be a lot of strange =
too.
>
>
>
> =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 10 =D0=BC=D0=B0=D1=80=D1=82 2=
015 =D0=B3., 1:19:56 UTC+2, Nicol Bolas =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=
=B0:
>
>>
>>
>> On Monday, March 9, 2015 at 1:22:01 PM UTC-4, Alexander Nikolov wrote:
>>>
>>> It works :O. You must be the master. But the mechanism it uses include
>>> another odd feature of the language which is the useless use of a singl=
e
>>> unnamed 'void' parameter. It seems that the language
>>>
>> strange features are completing each other - lol.
>>>
>>
>> Your problem, as I understood it, was with how it looked to the user.
>> Well, to the user it looks like:
>>
>> void operator++(std::prefix);
>>
>> They don't see the 'void' there. It's not "useless"; it's providing
>> exactly the semantic information you want.
>>
>>
>>>
>>> =D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 9 =D0=BC=
=D0=B0=D1=80=D1=82 2015 =D0=B3., 19:02:28 UTC+2, Matthew Woehlke =D0=BD=D0=
=B0=D0=BF=D0=B8=D1=81=D0=B0:
>>>>
>>>> On 2015-03-09 08:28, Morwenn wrote:
>>>> > Honestly, a solution that would have been clear and simple would hav=
e
>>>> been
>>>> > to add magic tag types, I will call them `std::prefix` and
>>>> `std::postfix`
>>>> > and add them to a commonly included header, like `<cstddef>`.
>>>>
>>>>   namespace std
>>>>   {
>>>>     using prefix =3D void;
>>>>     using postfix =3D int;
>>>>   }
>>>>
>>>> (Not tested; postfix should work, not sure about prefix...)
>>>>
>>>> --
>>>> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>



--=20
*Brian Bi*

--=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/.

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

<div dir=3D"ltr">It sounds like you object to the idea of having language f=
eatures that make it possible to write confusing code. If that&#39;s the ca=
se, I suggest you become a Java programmer instead of trying to change C++.=
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Mar=
 9, 2015 at 4:43 PM, Alexander Nikolov <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:sasho648@mail.bg" target=3D"_blank">sasho648@mail.bg</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">It is useless in gen=
eral. Why would you want to write:<div><br></div><div><div style=3D"border:=
1px solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,25=
0,250)"><code><div><span style=3D"color:#008">&lt;func-name&gt;</span><span=
 style=3D"color:#000">(void)</span></div></code></div><br>Instead of:<br><b=
r><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;back=
ground-color:rgb(250,250,250)"><code><div><span style=3D"color:#008">&lt;fu=
nc-name&gt;</span><span style=3D"color:#000">()</span></div></code></div><d=
iv><br></div><div><br></div><div>The suggested solution have very big draw-=
backs however:</div><div><br></div><div><ol><li><span style=3D"line-height:=
normal">Existing odd-looking code will still be still supported and thus ev=
entually being written again.</span></li><li><span style=3D"line-height:nor=
mal">As those type-aliases are common - some &#39;smart&#39; guy could star=
t using them instead of &#39;void&#39; and &#39;int&#39; which will be a lo=
t of strange too.</span></li></ol></div><br><br>=D0=B2=D1=82=D0=BE=D1=80=D0=
=BD=D0=B8=D0=BA, 10 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 1:19:56 UTC+2, N=
icol Bolas =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<div><div class=3D"h5"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Monday, Mar=
ch 9, 2015 at 1:22:01 PM UTC-4, Alexander Nikolov wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">It works :O. You must be the master=
.. But the mechanism it uses include another odd feature of the language whi=
ch is the useless use of a single unnamed &#39;void&#39; parameter. It seem=
s that the language </div></blockquote><div></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr">strange features are completing each other =
- lol.<br></div></blockquote><div><br>Your problem, as I understood it, was=
 with how it looked to the user. Well, to the user it looks like:<br><br>vo=
id operator++(std::prefix);<br><br>They don&#39;t see the &#39;void&#39; th=
ere. It&#39;s not &quot;useless&quot;; it&#39;s providing exactly the seman=
tic information you want.<br></div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><br>=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=
=D0=BB=D0=BD=D0=B8=D0=BA, 9 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 19:02:28=
 UTC+2, Matthew Woehlke =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">On 2015-03-09 08:28, Morwenn wrote:
<br>&gt; Honestly, a solution that would have been clear and simple would h=
ave been=20
<br>&gt; to add magic tag types, I will call them `std::prefix` and `std::p=
ostfix`=20
<br>&gt; and add them to a commonly included header, like `&lt;cstddef&gt;`=
..
<br>
<br>=C2=A0 namespace std
<br>=C2=A0 {
<br>=C2=A0 =C2=A0 using prefix =3D void;
<br>=C2=A0 =C2=A0 using postfix =3D int;
<br>=C2=A0 }
<br>
<br>(Not tested; postfix should work, not sure about prefix...)
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></div></blockquote></div></blockquote></div></div></div></=
div><div class=3D"HOEnZb"><div class=3D"h5">

<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" 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>
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><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><font=
 color=3D"#c0c0c0"><i>Brian Bi</i></font><br><div></div><div></div><div></d=
iv></div></div></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 />

--089e0160a32023de510510e3b067--

.

------=_Part_1330_1021254531.1425945234662
Content-Type: multipart/alternative;
 boundary="----=_Part_1331_1535595693.1425945234662"

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



On Monday, March 9, 2015 at 7:43:26 PM UTC-4, Alexander Nikolov wrote:
>
> It is useless in general.
>

It's not supposed to be useful "in general". It's supposed to be useful in=
=20
the specific case under discussion. And it is. It solves exactly your=20
problem.
=20

> Why would you want to write:
>
> <func-name>(void)
>
> Instead of:
>
> <func-name>()
>
>
> The suggested solution have very big draw-backs however:
>
>
>    1. Existing odd-looking code will still be still supported and thus=20
>    eventually being written again.
>
> Some people would call "not breaking everyone's code" a feature. Other=20
people would call it a necessary precondition for something this=20
unimportant.

It seems that a compromise is not something you're willing to take part in.


>    1. As those type-aliases are common - some 'smart' guy could start=20
>    using them instead of 'void' and 'int' which will be a lot of strange =
too.
>
> ... so? If someone started doing that, then they're writing bad code. And=
=20
C++ is not in the business of actively preventing you from shooting=20
yourself in the foot.

You can write a function nowadays that takes a std::nullptr_t. Nobody does,=
=20
because there's no reason to do so.

Just because someone *could* do something stupid is not sufficient reason=
=20
alone to not have a feature.
=20

>
>
> =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 10 =D0=BC=D0=B0=D1=80=D1=82 2=
015 =D0=B3., 1:19:56 UTC+2, Nicol Bolas =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=
=B0:
>>
>>
>>
>> On Monday, March 9, 2015 at 1:22:01 PM UTC-4, Alexander Nikolov wrote:
>>>
>>> It works :O. You must be the master. But the mechanism it uses include=
=20
>>> another odd feature of the language which is the useless use of a singl=
e=20
>>> unnamed 'void' parameter. It seems that the language=20
>>>
>> strange features are completing each other - lol.
>>>
>>
>> Your problem, as I understood it, was with how it looked to the user.=20
>> Well, to the user it looks like:
>>
>> void operator++(std::prefix);
>>
>> They don't see the 'void' there. It's not "useless"; it's providing=20
>> exactly the semantic information you want.
>> =20
>>
>>>
>>> =D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 9 =D0=BC=
=D0=B0=D1=80=D1=82 2015 =D0=B3., 19:02:28 UTC+2, Matthew Woehlke =D0=BD=D0=
=B0=D0=BF=D0=B8=D1=81=D0=B0:
>>>>
>>>> On 2015-03-09 08:28, Morwenn wrote:=20
>>>> > Honestly, a solution that would have been clear and simple would hav=
e=20
>>>> been=20
>>>> > to add magic tag types, I will call them `std::prefix` and=20
>>>> `std::postfix`=20
>>>> > and add them to a commonly included header, like `<cstddef>`.=20
>>>>
>>>>   namespace std=20
>>>>   {=20
>>>>     using prefix =3D void;=20
>>>>     using postfix =3D int;=20
>>>>   }=20
>>>>
>>>> (Not tested; postfix should work, not sure about prefix...)=20
>>>>
>>>> --=20
>>>> Matthew=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_1331_1535595693.1425945234662
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, March 9, 2015 at 7:43:26 PM UTC-4, Alex=
ander Nikolov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">It is useless in general.</div></blockquote><div><br>It's not supp=
osed to be useful "in general". It's supposed to be useful in the specific =
case under discussion. And it is. It solves exactly your problem.<br>&nbsp;=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Why wou=
ld you want to write:<div><br></div><div><div style=3D"border:1px solid rgb=
(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250)"><code=
><div><span style=3D"color:#008">&lt;func-name&gt;</span><span style=3D"col=
or:#000">(void)</span></div></code></div><br>Instead of:<br><br><div style=
=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-color=
:rgb(250,250,250)"><code><div><span style=3D"color:#008">&lt;func-name&gt;<=
/span><span style=3D"color:#000">()</span></div></code></div><div><br></div=
><div><br></div><div>The suggested solution have very big draw-backs howeve=
r:</div><div><br></div><div><ol><li><span style=3D"line-height:normal">Exis=
ting odd-looking code will still be still supported and thus eventually bei=
ng written again.</span></li></ol></div></div></div></blockquote><div>Some =
people would call "not breaking everyone's code" a feature. Other people wo=
uld call it a necessary precondition for something this unimportant.<br><br=
>It seems that a compromise is not something you're willing to take part in=
..<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div><div><ol><li><span style=3D"line-height:normal">As those type-aliase=
s are common - some 'smart' guy could start using them instead of 'void' an=
d 'int' which will be a lot of strange too.</span></li></ol></div></div></d=
iv></blockquote><div>... so? If someone started doing that, then they're wr=
iting bad code. And C++ is not in the business of actively preventing you f=
rom shooting yourself in the foot.<br><br>You can write a function nowadays=
 that takes a std::nullptr_t. Nobody does, because there's no reason to do =
so.<br><br>Just because someone <i>could</i> do something stupid is not suf=
ficient reason alone to not have a feature.<br>&nbsp;</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br><br>=D0=B2=D1=82=D0=
=BE=D1=80=D0=BD=D0=B8=D0=BA, 10 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 1:19=
:56 UTC+2, Nicol Bolas =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Monday, March 9, 2015 =
at 1:22:01 PM UTC-4, Alexander Nikolov wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr">It works :O. You must be the master. But the mec=
hanism it uses include another odd feature of the language which is the use=
less use of a single unnamed 'void' parameter. It seems that the language <=
/div></blockquote><div></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">strange features are completing each other - lol.<br></div></blo=
ckquote><div><br>Your problem, as I understood it, was with how it looked t=
o the user. Well, to the user it looks like:<br><br>void operator++(std::pr=
efix);<br><br>They don't see the 'void' there. It's not "useless"; it's pro=
viding exactly the semantic information you want.<br></div><div>&nbsp;</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>=D0=BF=D0=BE=
=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 9 =D0=BC=D0=B0=D1=80=D1=
=82 2015 =D0=B3., 19:02:28 UTC+2, Matthew Woehlke =D0=BD=D0=B0=D0=BF=D0=B8=
=D1=81=D0=B0:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 2015-03-09 08:28, M=
orwenn wrote:
<br>&gt; Honestly, a solution that would have been clear and simple would h=
ave been=20
<br>&gt; to add magic tag types, I will call them `std::prefix` and `std::p=
ostfix`=20
<br>&gt; and add them to a commonly included header, like `&lt;cstddef&gt;`=
..
<br>
<br>&nbsp; namespace std
<br>&nbsp; {
<br>&nbsp; &nbsp; using prefix =3D void;
<br>&nbsp; &nbsp; using postfix =3D int;
<br>&nbsp; }
<br>
<br>(Not tested; postfix should work, not sure about prefix...)
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></div></blockquote></div></blockquote></div></div></blockq=
uote></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_1331_1535595693.1425945234662--
------=_Part_1330_1021254531.1425945234662--

.

On 3/8/2015 3:40 PM, Ville Voutilainen wrote:
> I doubt it has, partly because I fail to see the point of such a
> microscopic addition.
> We can't replace the existing syntax, so adding an alternative would serve
> little purpose.

Is it actually impossible to replace? It seems that it would be
relatively easy for automated tools to transform the old syntax into the
new, and compilers could support both syntaxes for a time.

I'm not sure it's worth cleaning up this bit of cruft, though. There are
surely more valuable things to work on.

- Jim


--

---
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_1303_1676559582.1425947242781
Content-Type: multipart/alternative;
 boundary="----=_Part_1304_803962387.1425947242782"

------=_Part_1304_803962387.1425947242782
Content-Type: text/plain; charset=UTF-8

On Monday, March 9, 2015 at 8:17:12 PM UTC-4, Jim Porter wrote:
>
> On 3/8/2015 3:40 PM, Ville Voutilainen wrote:
> > I doubt it has, partly because I fail to see the point of such a
> > microscopic addition.
> > We can't replace the existing syntax, so adding an alternative would
> serve
> > little purpose.
>
> Is it actually impossible to replace? It seems that it would be
> relatively easy for automated tools to transform the old syntax into the
> new, and compilers could support both syntaxes for a time.
>

Sadly, C++ developers don't seem to trust automated tools performing code
transformations on large codebases. Otherwise, someone would have
implemented an entirely new language that had the same semantic features as
C++, but with different syntax.

I would have thought that Clang would have helped speed things along, but
apparently not.

--

---
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_1304_803962387.1425947242782
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, March 9, 2015 at 8:17:12 PM UTC-4, Jim Porter w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">On 3/8/2015 3:40 PM, Vill=
e Voutilainen wrote:
<br>&gt; I doubt it has, partly because I fail to see the point of such a
<br>&gt; microscopic addition.
<br>&gt; We can't replace the existing syntax, so adding an alternative wou=
ld serve
<br>&gt; little purpose.
<br>
<br>Is it actually impossible to replace? It seems that it would be=20
<br>relatively easy for automated tools to transform the old syntax into th=
e=20
<br>new, and compilers could support both syntaxes for a time.<br></blockqu=
ote><div><br>Sadly, C++ developers don't seem to trust automated tools perf=
orming code transformations on large codebases. Otherwise, someone would ha=
ve implemented an entirely new language that had the same semantic features=
 as C++, but with different syntax.<br><br>I would have thought that Clang =
would have helped speed things along, but apparently not.</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 />

------=_Part_1304_803962387.1425947242782--
------=_Part_1303_1676559582.1425947242781--

.

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

On 9 March 2015 at 18:53, Nicol Bolas <jmckesson@gmail.com> wrote:

> You can write a function nowadays that takes a std::nullptr_t. Nobody
> does, because there's no reason to do so.
>

There are plenty of functions of the standard library which take a
std::nullptr_t.  For example, take a look at comparators, constructors and
assignment operators for smart pointers.


--
 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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 9 March 2015 at 18:53, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mail=
to:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div>You can write a function no=
wadays that takes a std::<span class=3D"il">nullptr_t</span>. Nobody does, =
because there&#39;s no reason to do so.<br></div></blockquote></div><br>The=
re are plenty of functions of the standard library which take a std::nullpt=
r_t.=C2=A0 For example, take a look at comparators, constructors and assign=
ment operators for smart pointers.<br><br clear=3D"all"><div><br></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 />

--089e0160a8daf7f41b0510e88896--

.

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

On Mon, Mar 9, 2015 at 12:02 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 8 March 2015 at 10:54, Alexander Nikolov <sasho648@mail.bg> wrote:
>
>> Wouldn't it be better instead of taking one dummy parameter
>> the user-defined function which implements the post-fix ++ or -- operator
>> to have declaration similar to the form:
>>
>> operator ~--()
>>
>> I personally think that this is a lot more clear then:
>>
>> operator --(int);
>>
>
> I don't get it.  Why is changing from one obscure syntax to another
> equally obscure syntax making anything better?
> --
>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404
>
> --
>
>

I had to write operator++ today.  I still can't remember which is which
without looking it up. :-(
I'd appreciate some syntax that made it more clear.  Not sure ~++ would be
that syntax.  Not sure it is worth worrying about.

Tony

--

---
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/.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Mar 9, 2015 at 12:02 PM, Nevin Liber <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.=
com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><span class=3D"">On 8 March 2015 at 10:54, Alexander Nikolov <span dir=3D=
"ltr">&lt;<a href=3D"mailto:sasho648@mail.bg" target=3D"_blank">sasho648@ma=
il.bg</a>&gt;</span> wrote:<br></span><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">Wouldn&#39;t it be better instead of taking one dummy parameter th=
e=C2=A0user-defined function which implements the post-fix ++ or -- operato=
r to have declaration similar to the form:<br><br><div style=3D"border:1px =
solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,250,25=
0)"><code><div><span style=3D"color:#008">operator</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#660">~--()</span></div></code></div>=
<div><br></div><div>I personally think that this is a lot more clear then:<=
/div><div><br></div><div><div style=3D"border:1px solid rgb(187,187,187);wo=
rd-wrap:break-word;background-color:rgb(250,250,250)"><code><div><span styl=
e=3D"color:#008">operator</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#660">--(</span><span style=3D"color:#008">int</span><span sty=
le=3D"color:#660">);</span></div></code></div></div></div></blockquote><div=
><br></div></span><div>I don&#39;t get it.=C2=A0 Why is changing from one o=
bscure syntax to another equally obscure syntax making anything better?<spa=
n class=3D"HOEnZb"><font color=3D"#888888"><br clear=3D"all"></font></span>=
</div></div><span class=3D"HOEnZb"><font color=3D"#888888">-- <br><div>=C2=
=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@evi=
loverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 <a hr=
ef=3D"tel:%28847%29%20691-1404" value=3D"+18476911404" target=3D"_blank">(8=
47) 691-1404</a></div>
</font></span></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br></div></div></blockquote><div><br><br></div><div>I had to write operato=
r++ today.=C2=A0 I still can&#39;t remember which is which without looking =
it up. :-(<br></div><div>I&#39;d appreciate some syntax that made it more c=
lear.=C2=A0 Not sure ~++ would be that syntax.=C2=A0 Not sure it is worth w=
orrying about.<br><br></div><div>Tony<br><br></div></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 />

--001a11c355766831fa0510e9d53b--

.

On 2015-03-10 03:09, Tony V E wrote:
> I had to write operator++ today.  I still can't remember which is which
> without looking it up. :-(
> I'd appreciate some syntax that made it more clear.  Not sure ~++ would be
> that syntax.  Not sure it is worth worrying about.

As noted elsewhere...

  Foo& operator++(std::prefix);
  Foo operator++(std::postfix):

Easy to remember, trivial library addition (or you could add the
typedefs in your own library)... I'm not sufficiently desperate to write
a proposal, but FWIW I think it would be a nice addition.

I'm not a fan of ~++ either; I fail to see why the '~' should imply
"postfix". (Maybe it's meant along the lines of the '++this / this++'
suggestion? But I'd much prefer 'this' vs. '~' if that's the intent, and
really don't see the need when std::prefix / std::postfix is even more
clear, and would be a trivial, library-only change...)

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

.

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

On 10 March 2015 at 02:09, Tony V E <tvaneerd@gmail.com> wrote:

> I had to write operator++ today.  I still can't remember which is which
> without looking it up. :-(
> I'd appreciate some syntax that made it more clear.
>

Shall we expect you to present a paper on this in Lenexa?
--
 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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra">On 10 March 2015 at 02:09, Tony=
 V E <span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"=
_blank">tvaneerd@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div>I had to write operator++ today.=C2=
=A0 I still can&#39;t remember which is which without looking it up. :-(<br=
></div><div>I&#39;d appreciate some syntax that made it more clear.</div></=
blockquote></div><br>Shall we expect you to present a paper on this in Lene=
xa?<br>-- <br><div class=3D"gmail_signature">=C2=A0Nevin &quot;:-)&quot; Li=
ber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_b=
lank">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 />

--001a1133d7caf102080510f09835--

.

On Monday 09 March 2015 17:27:22 Nicol Bolas wrote:
> > Is it actually impossible to replace? It seems that it would be
> > relatively easy for automated tools to transform the old syntax into the
> > new, and compilers could support both syntaxes for a time.
>
> Sadly, C++ developers don't seem to trust automated tools performing code
> transformations on large codebases. Otherwise, someone would have
> implemented an entirely new language that had the same semantic features as
> C++, but with different syntax.

The problem is that we don't have a time machine, so we can't go back and fix
code that existed before the feature.

Even I trusted a tool to do a global replacement in my own source code, which
I can inspect and confirm correctness for, and everyone else did the same,
there are plenty of old releases of all frameworks still in use and people
with legitimate reasons not to upgrade. I wouldn't run such tools it for third
party codebases and don't expect most people would either. It would be a
maintenance nightmare.

--
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/.

.

--047d7bb04ee419b8f20510fd95dd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I also would like a more intuitive syntax for the pre- and postfix
operators.
I really liked your suggestion with the using clauses, however, g++ (4.9)
does not like it:

+ g++ --std=3Dc++1y test_operator.cpp -o test_operator
test_operator.cpp:12:25: error: =E2=80=98<anonymous>=E2=80=99 has incomplet=
e type
    X& operator ++( std::prefix)
                         ^
test_operator.cpp:12:31: error: invalid use of =E2=80=98std::prefix {aka vo=
id}=E2=80=99
    X& operator ++( std::prefix)
                               ^
test_operator.cpp:12:31: error: postfix =E2=80=98X& X::operator++(<type err=
or>)=E2=80=99
must take =E2=80=98int=E2=80=99 as its argument

Using a typedef instead of 'using' results in the same error.
Specially the second error I find interesting: The compiler knows that
std::prefix equals void, and a prefix operator with a void parameter stated
explicitly compiles too, only the combination of using/typedef and prefix
operator is not accepted.


Regards,
Ren=C3=A9

2015-03-09 18:02 GMT+01:00 Matthew Woehlke <mw_triad@users.sourceforge.net>=
:

> On 2015-03-09 08:28, Morwenn wrote:
> > Honestly, a solution that would have been clear and simple would have
> been
> > to add magic tag types, I will call them `std::prefix` and `std::postfi=
x`
> > and add them to a commonly included header, like `<cstddef>`.
>
>   namespace std
>   {
>     using prefix =3D void;
>     using postfix =3D int;
>   }
>
> (Not tested; postfix should work, not sure about prefix...)
>
> --
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>



--=20

=E2=80=9CDubito ergo cogito; cogito ergo sum.
(I doubt, therefore I think; I think therefore I am)=E2=80=9D
Ren=C3=A9 Descartes

--=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/.

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

<div dir=3D"ltr"><div><div><div><div><div>I also would like a more intuitiv=
e syntax for the pre- and postfix operators.<br></div>I really liked your s=
uggestion with the using clauses, however, g++ (4.9) does not like it:<br><=
br><span style=3D"font-family:monospace,monospace">+ g++ --std=3Dc++1y test=
_operator.cpp -o test_operator<br>test_operator.cpp:12:25: error: =E2=80=98=
&lt;anonymous&gt;=E2=80=99 has incomplete type<br>=C2=A0=C2=A0=C2=A0 X&amp;=
 operator ++( std::prefix)<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 ^<br>test_operator.cpp:12:31: error: invalid use o=
f =E2=80=98std::prefix {aka void}=E2=80=99<br>=C2=A0=C2=A0=C2=A0 X&amp; ope=
rator ++( std::prefix)<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^<br>test_operato=
r.cpp:12:31: error: postfix =E2=80=98X&amp; X::operator++(&lt;type error&gt=
;)=E2=80=99 must take =E2=80=98int=E2=80=99 as its argument<br></span><br><=
/div>Using a typedef instead of &#39;using&#39; results in the same error.<=
br></div>Specially the second error I find interesting: The compiler knows =
that std::prefix equals void, and a prefix operator with a void parameter s=
tated explicitly compiles too, only the combination of using/typedef and pr=
efix operator is not accepted.<br><br><br></div>Regards,<br></div>Ren=C3=A9=
<br><div><div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">201=
5-03-09 18:02 GMT+01:00 Matthew Woehlke <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:mw_triad@users.sourceforge.net" target=3D"_blank">mw_triad@users.sourc=
eforge.net</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D=
"">On 2015-03-09 08:28, Morwenn wrote:<br>
&gt; Honestly, a solution that would have been clear and simple would have =
been<br>
&gt; to add magic tag types, I will call them `std::prefix` and `std::postf=
ix`<br>
&gt; and add them to a commonly included header, like `&lt;cstddef&gt;`.<br=
>
<br>
</span>=C2=A0 namespace std<br>
=C2=A0 {<br>
=C2=A0 =C2=A0 using prefix =3D void;<br>
=C2=A0 =C2=A0 using postfix =3D int;<br>
=C2=A0 }<br>
<br>
(Not tested; postfix should work, not sure about prefix...)<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Matthew<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><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><br clear=3D"all"><br>-- <br><div class=
=3D"gmail_signature"><br>=E2=80=9CDubito ergo cogito; cogito ergo sum.<br>(=
I doubt, therefore I think; I think therefore I am)=E2=80=9D<br>Ren=C3=A9 D=
escartes<br></div>
</div></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 />

--047d7bb04ee419b8f20510fd95dd--

.

The last of those can be fixed by making postfix a synonym for int.

using postfix =3D int;

On 3/11/15, Ren=C3=A9 Eng <gemini67@gmail.com> wrote:
> I also would like a more intuitive syntax for the pre- and postfix
> operators.
> I really liked your suggestion with the using clauses, however, g++ (4.9)
> does not like it:
>
> + g++ --std=3Dc++1y test_operator.cpp -o test_operator
> test_operator.cpp:12:25: error: =E2=80=98<anonymous>=E2=80=99 has incompl=
ete type
>     X& operator ++( std::prefix)
>                          ^
> test_operator.cpp:12:31: error: invalid use of =E2=80=98std::prefix {aka =
void}=E2=80=99
>     X& operator ++( std::prefix)
>                                ^
> test_operator.cpp:12:31: error: postfix =E2=80=98X& X::operator++(<type e=
rror>)=E2=80=99
> must take =E2=80=98int=E2=80=99 as its argument
>
> Using a typedef instead of 'using' results in the same error.
> Specially the second error I find interesting: The compiler knows that
> std::prefix equals void, and a prefix operator with a void parameter stat=
ed
> explicitly compiles too, only the combination of using/typedef and prefix
> operator is not accepted.
>
>
> Regards,
> Ren=C3=A9
>
> 2015-03-09 18:02 GMT+01:00 Matthew Woehlke
> <mw_triad@users.sourceforge.net>:
>
>> On 2015-03-09 08:28, Morwenn wrote:
>> > Honestly, a solution that would have been clear and simple would have
>> been
>> > to add magic tag types, I will call them `std::prefix` and
>> > `std::postfix`
>> > and add them to a commonly included header, like `<cstddef>`.
>>
>>   namespace std
>>   {
>>     using prefix =3D void;
>>     using postfix =3D int;
>>   }
>>
>> (Not tested; postfix should work, not sure about prefix...)
>>
>> --
>> Matthew
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/.
>>
>
>
>
> --
>
> =E2=80=9CDubito ergo cogito; cogito ergo sum.
> (I doubt, therefore I think; I think therefore I am)=E2=80=9D
> Ren=C3=A9 Descartes
>
> --
>
> ---
> 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/.
>

--=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/.

.

--047d7b86df563da04b0510fe8cba
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2015-03-11 8:35 GMT+01:00 Douglas Boffey <douglas.boffey@gmail.com>:

> The last of those can be fixed by making postfix a synonym for int.
>
> using postfix =3D int;
>
> On 3/11/15, Ren=C3=A9 Eng <gemini67@gmail.com> wrote:
> > I also would like a more intuitive syntax for the pre- and postfix
> > operators.
> > I really liked your suggestion with the using clauses, however, g++ (4.=
9)
> > does not like it:
> >
>
<snip>

Sorry, I was not precise in my wording:
Yes, sure, it works for postfix, both with using or typedef. It's just the
prefix case that does not work either way.

Regards
Ren=C3=A9

--=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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
2015-03-11 8:35 GMT+01:00 Douglas Boffey <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:douglas.boffey@gmail.com" target=3D"_blank">douglas.boffey@gmail.com<=
/a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex">The last of those can be =
fixed by making postfix a synonym for int.<br>
<br>
using postfix =3D int;<br>
<br>
On 3/11/15, Ren=C3=A9 Eng &lt;<a href=3D"mailto:gemini67@gmail.com">gemini6=
7@gmail.com</a>&gt; wrote:<br>
&gt; I also would like a more intuitive syntax for the pre- and postfix<br>
&gt; operators.<br>
&gt; I really liked your suggestion with the using clauses, however, g++ (4=
..9)<br>
&gt; does not like it:<br>
&gt;<br>
</blockquote><div>&lt;snip&gt;<br><br></div><div>Sorry, I was not precise i=
n my wording:<br></div><div>Yes, sure, it works for postfix, both with usin=
g or typedef. It&#39;s just the prefix case that does not work either way.<=
br><br></div><div>Regards<br></div><div>Ren=C3=A9<br></div></div></div></di=
v>

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

--047d7b86df563da04b0510fe8cba--

.

------=_Part_6500_1693905531.1426087810816
Content-Type: multipart/alternative;
 boundary="----=_Part_6501_279551238.1426087810816"

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

Works on GCC trunk. This=20
is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D33101

On Wednesday, March 11, 2015 at 3:52:25 AM UTC-4, Ren=C3=A9 Eng wrote:
>
>
> 2015-03-11 8:35 GMT+01:00 Douglas Boffey <douglas...@gmail.com=20
> <javascript:>>:
>
>> The last of those can be fixed by making postfix a synonym for int.
>>
>> using postfix =3D int;
>>
>> On 3/11/15, Ren=C3=A9 Eng <gemi...@gmail.com <javascript:>> wrote:
>> > I also would like a more intuitive syntax for the pre- and postfix
>> > operators.
>> > I really liked your suggestion with the using clauses, however, g++=20
>> (4.9)
>> > does not like it:
>> >
>>
> <snip>
>
> Sorry, I was not precise in my wording:
> Yes, sure, it works for postfix, both with using or typedef. It's just th=
e=20
> prefix case that does not work either way.
>
> Regards
> Ren=C3=A9
>

--=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_6501_279551238.1426087810816
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Works on GCC trunk. This is&nbsp;https://gcc.gnu.org/bugzi=
lla/show_bug.cgi?id=3D33101<div><div><br>On Wednesday, March 11, 2015 at 3:=
52:25 AM UTC-4, Ren=C3=A9 Eng wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div><br><div class=3D"gmail_quote">2015-03-11 8:35 =
GMT+01:00 Douglas Boffey <span dir=3D"ltr">&lt;<a href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"ZRoWcrwodH0J" rel=3D"nofollow" onmou=
sedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'j=
avascript:';return true;">douglas...@gmail.com</a>&gt;</span>:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">The last of those can be fixed by making postfix a sy=
nonym for int.<br>
<br>
using postfix =3D int;<br>
<br>
On 3/11/15, Ren=C3=A9 Eng &lt;<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"ZRoWcrwodH0J" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';retur=
n true;">gemi...@gmail.com</a>&gt; wrote:<br>
&gt; I also would like a more intuitive syntax for the pre- and postfix<br>
&gt; operators.<br>
&gt; I really liked your suggestion with the using clauses, however, g++ (4=
..9)<br>
&gt; does not like it:<br>
&gt;<br>
</blockquote><div>&lt;snip&gt;<br><br></div><div>Sorry, I was not precise i=
n my wording:<br></div><div>Yes, sure, it works for postfix, both with usin=
g or typedef. It's just the prefix case that does not work either way.<br><=
br></div><div>Regards<br></div><div>Ren=C3=A9<br></div></div></div></div>
</blockquote></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 />

------=_Part_6501_279551238.1426087810816--
------=_Part_6500_1693905531.1426087810816--

.

------=_Part_7198_430255379.1426101546031
Content-Type: multipart/alternative;
 boundary="----=_Part_7199_724715404.1426101546031"

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

I think this is best way to "fix" postfix increment/decrement. Easy to=20
implement and backward (and forward with small tweak) compatible.
Adding new syntax only made it worse. `operator~--` look more like=20
composition of two operations, decrement and binary negation, better is to=
=20
stick `operator-`, less typing, same effect :D

On Wednesday, March 11, 2015 at 8:35:28 AM UTC+1, Douglas Boffey wrote:
>
> The last of those can be fixed by making postfix a synonym for int.=20
>
> using postfix =3D int;=20
>
> On 3/11/15, Ren=C3=A9 Eng <gemi...@gmail.com <javascript:>> wrote:=20
> > I also would like a more intuitive syntax for the pre- and postfix=20
> > operators.=20
> > I really liked your suggestion with the using clauses, however, g++=20
> (4.9)=20
> > does not like it:=20
> >=20
> > + g++ --std=3Dc++1y test_operator.cpp -o test_operator=20
> > test_operator.cpp:12:25: error: =E2=80=98<anonymous>=E2=80=99 has incom=
plete type=20
> >     X& operator ++( std::prefix)=20
> >                          ^=20
> > test_operator.cpp:12:31: error: invalid use of =E2=80=98std::prefix {ak=
a void}=E2=80=99=20
> >     X& operator ++( std::prefix)=20
> >                                ^=20
> > test_operator.cpp:12:31: error: postfix =E2=80=98X& X::operator++(<type=
 error>)=E2=80=99=20
> > must take =E2=80=98int=E2=80=99 as its argument=20
> >=20
> > Using a typedef instead of 'using' results in the same error.=20
> > Specially the second error I find interesting: The compiler knows that=
=20
> > std::prefix equals void, and a prefix operator with a void parameter=20
> stated=20
> > explicitly compiles too, only the combination of using/typedef and=20
> prefix=20
> > operator is not accepted.=20
> >=20
> >=20
> > Regards,=20
> > Ren=C3=A9=20
> >=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_7199_724715404.1426101546031
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think this is best way to "fix" postfix increment/decrem=
ent. Easy to implement and backward (and forward with small tweak) compatib=
le.<br>Adding new syntax only made it worse. `operator~--` look more like c=
omposition of two operations, decrement and binary negation, better is to s=
tick `operator-`, less typing, same effect :D<br><br>On Wednesday, March 11=
, 2015 at 8:35:28 AM UTC+1, Douglas Boffey wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;">The last of those can be fixed by making postfix a synon=
ym for int.
<br>
<br>using postfix =3D int;
<br>
<br>On 3/11/15, Ren=C3=A9 Eng &lt;<a href=3D"javascript:" target=3D"_blank"=
 gdf-obfuscated-mailto=3D"J7cqt3RKqrwJ" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';r=
eturn true;">gemi...@gmail.com</a>&gt; wrote:
<br>&gt; I also would like a more intuitive syntax for the pre- and postfix
<br>&gt; operators.
<br>&gt; I really liked your suggestion with the using clauses, however, g+=
+ (4.9)
<br>&gt; does not like it:
<br>&gt;
<br>&gt; + g++ --std=3Dc++1y test_operator.cpp -o test_operator
<br>&gt; test_operator.cpp:12:25: error: =E2=80=98&lt;anonymous&gt;=E2=80=
=99 has incomplete type
<br>&gt; &nbsp; &nbsp; X&amp; operator ++( std::prefix)
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp;^
<br>&gt; test_operator.cpp:12:31: error: invalid use of =E2=80=98std::prefi=
x {aka void}=E2=80=99
<br>&gt; &nbsp; &nbsp; X&amp; operator ++( std::prefix)
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;^
<br>&gt; test_operator.cpp:12:31: error: postfix =E2=80=98X&amp; X::operato=
r++(&lt;type error&gt;)=E2=80=99
<br>&gt; must take =E2=80=98int=E2=80=99 as its argument
<br>&gt;
<br>&gt; Using a typedef instead of 'using' results in the same error.
<br>&gt; Specially the second error I find interesting: The compiler knows =
that
<br>&gt; std::prefix equals void, and a prefix operator with a void paramet=
er stated
<br>&gt; explicitly compiles too, only the combination of using/typedef and=
 prefix
<br>&gt; operator is not accepted.
<br>&gt;
<br>&gt;
<br>&gt; Regards,
<br>&gt; Ren=C3=A9
<br>&gt;
<br></blockquote></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_7199_724715404.1426101546031--
------=_Part_7198_430255379.1426101546031--

.

------=_Part_456_856795457.1426242619239
Content-Type: multipart/alternative;
 boundary="----=_Part_457_1283392664.1426242619239"

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

Then you'll use version of compiler (or option of the same) which will=20
compile your old legacy C++ code confirming older ISO C++ standard=20
versions. In this way you'll be able to translate only some C++ files while=
=20
still be able to compile the entire project. I believe every modern=20
compiler have already such option.=20

Even if you don't use automated tool for the translation (for example=20
clang-modernize <http://clang.llvm.org/extra/clang-modernize.html>) - you=
=20
can hire someone to do this job. He can translate file by file in the=20
original project without breaking existing files as both legacy and modern=
=20
code are supported, thus enabling parallel work on it. While he modernize=
=20
it - someone else could work on adding new features/fixing bugs, etc.

Ultimately it will be nice if some universal non-text binary representation=
=20
of the C++ code is standardized. This way user-experience wouldn't conflict=
=20
with functionality. But I highly doubt this would ever happen because being=
=20
a text-format language is one of the main C++ features.

=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 10 =D0=BC=D0=B0=D1=80=D1=82 201=
5 =D0=B3., 17:53:10 UTC+2, Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0:
>
> On Monday 09 March 2015 17:27:22 Nicol Bolas wrote:=20
> > > Is it actually impossible to replace? It seems that it would be=20
> > > relatively easy for automated tools to transform the old syntax into=
=20
> the=20
> > > new, and compilers could support both syntaxes for a time.=20
> >=20
> > Sadly, C++ developers don't seem to trust automated tools performing=20
> code=20
> > transformations on large codebases. Otherwise, someone would have=20
> > implemented an entirely new language that had the same semantic feature=
s=20
> as=20
> > C++, but with different syntax.=20
>
> The problem is that we don't have a time machine, so we can't go back and=
=20
> fix=20
> code that existed before the feature.=20
>
> Even I trusted a tool to do a global replacement in my own source code,=
=20
> which=20
> I can inspect and confirm correctness for, and everyone else did the same=
,=20
> there are plenty of old releases of all frameworks still in use and peopl=
e=20
> with legitimate reasons not to upgrade. I wouldn't run such tools it for=
=20
> third=20
> party codebases and don't expect most people would either. It would be a=
=20
> maintenance nightmare.=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>       PGP/GPG: 0x6EF45358; fingerprint:=20
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358=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_457_1283392664.1426242619239
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Then you'll use version of compiler (or option of the same=
) which will compile your old legacy C++ code confirming older ISO C++ stan=
dard versions. In this way you'll be able to translate only some C++ files =
while still be able to compile the entire project. I believe every modern c=
ompiler have already such option.&nbsp;<div><br></div><div>Even if you don'=
t use automated tool for the translation (for example&nbsp;<a href=3D"http:=
//clang.llvm.org/extra/clang-modernize.html">clang-modernize</a>) - you can=
 hire someone to do this job. He can translate file by file in the original=
 project without breaking existing files as both legacy and modern code are=
 supported, thus enabling parallel work on it. While he modernize it - some=
one else could work on adding new features/fixing bugs, etc.</div><div><br>=
</div><div>Ultimately it will be nice if some universal non-text binary rep=
resentation of the C++ code is standardized. This way user-experience would=
n't conflict with functionality. But I highly doubt this would ever happen =
because being a text-format language is one of the main C++ features.<br><d=
iv><br>=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 10 =D0=BC=D0=B0=D1=80=D1=
=82 2015 =D0=B3., 17:53:10 UTC+2, Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=
=D1=81=D0=B0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Monday 09 Marc=
h 2015 17:27:22 Nicol Bolas wrote:
<br>&gt; &gt; Is it actually impossible to replace? It seems that it would =
be=20
<br>&gt; &gt; relatively easy for automated tools to transform the old synt=
ax into the=20
<br>&gt; &gt; new, and compilers could support both syntaxes for a time.
<br>&gt;=20
<br>&gt; Sadly, C++ developers don't seem to trust automated tools performi=
ng code=20
<br>&gt; transformations on large codebases. Otherwise, someone would have=
=20
<br>&gt; implemented an entirely new language that had the same semantic fe=
atures as=20
<br>&gt; C++, but with different syntax.
<br>
<br>The problem is that we don't have a time machine, so we can't go back a=
nd fix=20
<br>code that existed before the feature.
<br>
<br>Even I trusted a tool to do a global replacement in my own source code,=
 which=20
<br>I can inspect and confirm correctness for, and everyone else did the sa=
me,=20
<br>there are plenty of old releases of all frameworks still in use and peo=
ple=20
<br>with legitimate reasons not to upgrade. I wouldn't run such tools it fo=
r third=20
<br>party codebases and don't expect most people would either. It would be =
a=20
<br>maintenance nightmare.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNE=
swDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg=
\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - th=
iago (AT) <a href=3D"http://kde.org" target=3D"_blank" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.org=
\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return tr=
ue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde=
..org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';retur=
n true;">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote></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 />

------=_Part_457_1283392664.1426242619239--
------=_Part_456_856795457.1426242619239--

.

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

I don't think that adding one more way of doing the same would help anyone
(people would still need to learn both) and even if you can migrate code
bases people would have to understand them if they want to move from one
codebase to another. Additionally, the strategy of using a compiler flag to
process some files one way and some files in another way is bogus.

A translation unit might be including multiple headers, each of which uses
one form of syntax... either you atomically change all your code base or
the compiler will need to support both... and you are still left with the
original problem of having to understand both syntaxes to work on legacy
code, maybe in the same or a different company.

Note that there are people that have to target multiple architectures and
cannot switch from one compiler to another just because they feel like it.
Support for C++11 compiler is not complete in Solaris/AIX own compilers,
for example. Evolution of a code base is a more complicated thing than you
may be realizing.

On Fri, Mar 13, 2015 at 6:30 AM, Alexander Nikolov <sasho648@mail.bg> wrote=
:

> Then you'll use version of compiler (or option of the same) which will
> compile your old legacy C++ code confirming older ISO C++ standard
> versions. In this way you'll be able to translate only some C++ files whi=
le
> still be able to compile the entire project. I believe every modern
> compiler have already such option.
>
> Even if you don't use automated tool for the translation (for example
> clang-modernize <http://clang.llvm.org/extra/clang-modernize.html>) - you
> can hire someone to do this job. He can translate file by file in the
> original project without breaking existing files as both legacy and moder=
n
> code are supported, thus enabling parallel work on it. While he modernize
> it - someone else could work on adding new features/fixing bugs, etc.
>
> Ultimately it will be nice if some universal non-text binary
> representation of the C++ code is standardized. This way user-experience
> wouldn't conflict with functionality. But I highly doubt this would ever
> happen because being a text-format language is one of the main C++ featur=
es.
>
> =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 10 =D0=BC=D0=B0=D1=80=D1=82 2=
015 =D0=B3., 17:53:10 UTC+2, Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0:
>
>> On Monday 09 March 2015 17:27:22 Nicol Bolas wrote:
>> > > Is it actually impossible to replace? It seems that it would be
>> > > relatively easy for automated tools to transform the old syntax into
>> the
>> > > new, and compilers could support both syntaxes for a time.
>> >
>> > Sadly, C++ developers don't seem to trust automated tools performing
>> code
>> > transformations on large codebases. Otherwise, someone would have
>> > implemented an entirely new language that had the same semantic
>> features as
>> > C++, but with different syntax.
>>
>> The problem is that we don't have a time machine, so we can't go back an=
d
>> fix
>> code that existed before the feature.
>>
>> Even I trusted a tool to do a global replacement in my own source code,
>> which
>> I can inspect and confirm correctness for, and everyone else did the
>> same,
>> there are plenty of old releases of all frameworks still in use and
>> people
>> with legitimate reasons not to upgrade. I wouldn't run such tools it for
>> third
>> party codebases and don't expect most people would either. It would be a
>> maintenance nightmare.
>>
>> --
>> 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/.
>

--=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/.

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

<div dir=3D"ltr">I don&#39;t think that adding one more way of doing the sa=
me would help anyone (people would still need to learn both) and even if yo=
u can migrate code bases people would have to understand them if they want =
to move from one codebase to another. Additionally, the strategy of using a=
 compiler flag to process some files one way and some files in another way =
is bogus. <br><br>A translation unit might be including multiple headers, e=
ach of which uses one form of syntax... either you atomically change all yo=
ur code base or the compiler will need to support both... and you are still=
 left with the original problem of having to understand both syntaxes to wo=
rk on legacy code, maybe in the same or a different company.<br><br>Note th=
at there are people that have to target multiple architectures and cannot s=
witch from one compiler to another just because they feel like it. Support =
for C++11 compiler is not complete in Solaris/AIX own compilers, for exampl=
e. Evolution of a code base is a more complicated thing than you may be rea=
lizing.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On F=
ri, Mar 13, 2015 at 6:30 AM, Alexander Nikolov <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:sasho648@mail.bg" target=3D"_blank">sasho648@mail.bg</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Then you&#39=
;ll use version of compiler (or option of the same) which will compile your=
 old legacy C++ code confirming older ISO C++ standard versions. In this wa=
y you&#39;ll be able to translate only some C++ files while still be able t=
o compile the entire project. I believe every modern compiler have already =
such option.=C2=A0<div><br></div><div>Even if you don&#39;t use automated t=
ool for the translation (for example=C2=A0<a href=3D"http://clang.llvm.org/=
extra/clang-modernize.html" target=3D"_blank">clang-modernize</a>) - you ca=
n hire someone to do this job. He can translate file by file in the origina=
l project without breaking existing files as both legacy and modern code ar=
e supported, thus enabling parallel work on it. While he modernize it - som=
eone else could work on adding new features/fixing bugs, etc.</div><div><br=
></div><div>Ultimately it will be nice if some universal non-text binary re=
presentation of the C++ code is standardized. This way user-experience woul=
dn&#39;t conflict with functionality. But I highly doubt this would ever ha=
ppen because being a text-format language is one of the main C++ features.<=
br><div><br>=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 10 =D0=BC=D0=B0=D1=
=80=D1=82 2015 =D0=B3., 17:53:10 UTC+2, Thiago Macieira =D0=BD=D0=B0=D0=BF=
=D0=B8=D1=81=D0=B0:<div><div class=3D"h5"><blockquote class=3D"gmail_quote"=
 style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">On Monday 09 March 2015 17:27:22 Nicol Bolas wrote:
<br>&gt; &gt; Is it actually impossible to replace? It seems that it would =
be=20
<br>&gt; &gt; relatively easy for automated tools to transform the old synt=
ax into the=20
<br>&gt; &gt; new, and compilers could support both syntaxes for a time.
<br>&gt;=20
<br>&gt; Sadly, C++ developers don&#39;t seem to trust automated tools perf=
orming code=20
<br>&gt; transformations on large codebases. Otherwise, someone would have=
=20
<br>&gt; implemented an entirely new language that had the same semantic fe=
atures as=20
<br>&gt; C++, but with different syntax.
<br>
<br>The problem is that we don&#39;t have a time machine, so we can&#39;t g=
o back and fix=20
<br>code that existed before the feature.
<br>
<br>Even I trusted a tool to do a global replacement in my own source code,=
 which=20
<br>I can inspect and confirm correctness for, and everyone else did the sa=
me,=20
<br>there are plenty of old releases of all frameworks still in use and peo=
ple=20
<br>with legitimate reasons not to upgrade. I wouldn&#39;t run such tools i=
t for third=20
<br>party codebases and don&#39;t expect most people would either. It would=
 be a=20
<br>maintenance nightmare.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"n=
ofollow" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http:=
//kde.org" rel=3D"nofollow" target=3D"_blank">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote></div></div></div></div></div><div class=3D"HOEnZb"><div c=
lass=3D"h5">

<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" 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>
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 />

--089e01227a18955abd05112a9870--

.

------=_Part_168_1803111098.1426356314479
Content-Type: multipart/alternative;
 boundary="----=_Part_169_1746481269.1426356314479"

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



=D0=BF=D0=B5=D1=82=D1=8A=D0=BA, 13 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 1=
4:25:31 UTC+2, David Rodr=C3=ADguez Ibeas =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=
=B0:
>
> I don't think that adding one more way of doing the same would help anyon=
e=20
> (people would still need to learn both)
>
and even if you can migrate code bases people would have to understand them=
=20
> if they want to move from one codebase to another. Additionally, the=20
> strategy of using a compiler flag to process some files one way and some=
=20
> files in another way is bogus.=20
>

> A translation unit might be including multiple headers, each of which use=
s=20
> one form of syntax... either you atomically change all your code base or=
=20
> the compiler will need to support both... and you are still left with the=
=20
> original problem of having to understand both syntaxes to work on legacy=
=20
> code, maybe in the same or a different company.
> =20
>
Note that there are people that have to target multiple architectures and=
=20
> cannot switch from one compiler to another just because they feel like it=
..=20
> Support for C++11 compiler is not complete in Solaris/AIX own compilers,=
=20
> for example. Evolution of a code base is a more complicated thing than yo=
u=20
> may be realizing.
>


Perhaps this would be true in the beginning but as time passes code bases=
=20
will be smoothly translated to the latest C++ standard and then nobody=20
would even need to know that C++ had those odd syntax constructs. Even=20
though that this wouldn't be such a problem anyway as the changes=20
introduced will be more like 'disabling' things then 'adding' new ones (in=
=20
most of the cases).

This way new 'C++' programmers will more easily understand, 'feel' the=20
language and I'm sure older ones will easily learn it too.

A recent example of 'C++' oddness, which is called 'Most-vexing parse=20
rule', that really confused a decent but not so professional programmer (I=
=20
mean that he hasn't read the whole ISO C++ documentation or life long=20
enough to discover those language dark holes) can be found here=20
<http://stackoverflow.com/questions/29051322/c-error-c2297-illegal-right-op=
erand-has-type-double-cdecl-doubl>
 .

It's that, construct like this, which look like creating object, are=20
actually declaring function:

std::string str(); //function named 'str' with no parameters which returns=
=20
'std::string'

std::string str2(str); // object 'str2' is constructed by 'str'

double str1(double (str) ); //function named 'str1' which takes a single=20
parameter of type 'double'

I suggest adding for example a new keyword 'func' which when used in=20
declaration states that it declares a function and not a variable. This=20
will avoid confusion as there wouldn't be that odd rule by which sometimes=
=20
variable constructed with brackets are something entirely different. The=20
newly introduced way of doing the same by braces add to the confusion and=
=20
not fix the problem! People now ask - should I go for braces or brackets -=
=20
what's the difference - and the answer is not that simple because sometimes=
=20
braces can't be used.

Using a keyword 'func' would definitely add some clarity and readability in=
=20
the above example:

func std::string str(); //function named 'str' with no parameters which=20
returns 'std::string'

std::string str2(str); // object 'str2' is constructed by 'str'

func double str1(double (str) ); //function named 'str1' which takes a=20
single parameter of type 'double'

This way nobody will be confused what is the type of those entities=20
(functions or variables) because it's just obvious.

--=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_169_1746481269.1426356314479
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>=D0=BF=D0=B5=D1=82=D1=8A=D0=BA, 13 =D0=BC=D0=B0=D1=
=80=D1=82 2015 =D0=B3., 14:25:31 UTC+2, David Rodr=C3=ADguez Ibeas =D0=BD=
=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr">I don't think that adding one more way of doing the same =
would help anyone (people would still need to learn both)</div></blockquote=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"> and even if=
 you can migrate code bases people would have to understand them if they wa=
nt to move from one codebase to another. Additionally, the strategy of usin=
g a compiler flag to process some files one way and some files in another w=
ay is bogus.&nbsp;</div></blockquote><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"ltr"><br>A translation unit might be including multiple =
headers, each of which uses one form of syntax... either you atomically cha=
nge all your code base or the compiler will need to support both... and you=
 are still left with the original problem of having to understand both synt=
axes to work on legacy code, maybe in the same or a different company.<br>&=
nbsp;<br></div></blockquote><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr">Note that there are people that have to target multiple arch=
itectures and cannot switch from one compiler to another just because they =
feel like it. Support for C++11 compiler is not complete in Solaris/AIX own=
 compilers, for example. Evolution of a code base is a more complicated thi=
ng than you may be realizing.</div></blockquote><div><br></div><div><br></d=
iv><div>Perhaps this would be true in the beginning but as time passes code=
 bases will be smoothly translated to the latest C++ standard and then nobo=
dy would even need to know that C++ had those odd syntax constructs. Even t=
hough that this wouldn't be such a problem anyway as the changes introduced=
 will be more like 'disabling' things then 'adding' new ones (in most of th=
e cases).</div><div><br></div><div>This way new 'C++' programmers will more=
 easily understand, 'feel' the language and I'm sure older ones will easily=
 learn it too.</div><div><br></div><div>A recent example of 'C++' oddness, =
which is called 'Most-vexing parse rule', that really confused a decent but=
 not so professional programmer (I mean that he hasn't read the whole ISO C=
++ documentation or life long enough to discover those language dark holes)=
 can be found <a href=3D"http://stackoverflow.com/questions/29051322/c-erro=
r-c2297-illegal-right-operand-has-type-double-cdecl-doubl">here</a>&nbsp;.<=
/div><div><br></div><div>It's that, construct like this, which look like cr=
eating object, are actually declaring function:<br><br></div><div class=3D"=
prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: brea=
k-word; background-color: rgb(250, 250, 250);"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-=
by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">::</span><span style=3D"color: #008;" class=3D"styled-by-prettify">st=
ring</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> str</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">//function named 'str' with =
no parameters which returns 'std::string'</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br><br>std</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">::</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">string</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> str2</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">str</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #800;" class=3D"styled-by-prettify">// object 'str2' i=
s constructed by 'str'</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">double</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> str1</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">double</=
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">str</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">)</span><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"styl=
ed-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">//function named 'str1' which takes a single parameter of type 'doub=
le'</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan></div></code></div><div><br></div><div>I suggest adding for example a n=
ew keyword 'func' which when used in declaration states that it declares a =
function and not a variable. This will avoid confusion as there wouldn't be=
 that odd rule by which sometimes variable constructed with brackets are so=
mething entirely different. The newly introduced way of doing the same by&n=
bsp;braces add to the confusion and not fix the problem! People now ask - s=
hould I go for braces or brackets - what's the difference - and the answer =
is not that simple because sometimes braces can't be used.</div><div><br></=
div><div>Using a keyword 'func' would definitely add some clarity and reada=
bility in the above example:<br><br></div><div><div class=3D"prettyprint" s=
tyle=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; backgr=
ound-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">f=
unc std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::<=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">string</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> str</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #800;" class=3D"styled-by-prettify">//function named 'str' with no parame=
ters which returns 'std::string'</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br>std</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">string</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> str2</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">s=
tr</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #800;" class=3D"styled-by-prettify">// object 'str2' is const=
ructed by 'str'</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br><br>func </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">double</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> str1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">double</sp=
an><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">str</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>//function named 'str1' which takes a single parameter of type 'double'</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></=
div></code></div><br></div><div>This way nobody will be confused what is th=
e type of those entities (functions or variables) because it's just obvious=
..</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_169_1746481269.1426356314479--
------=_Part_168_1803111098.1426356314479--

.

------=_Part_4110_1327665243.1426494588395
Content-Type: multipart/alternative;
 boundary="----=_Part_4111_1714646771.1426494588395"

------=_Part_4111_1714646771.1426494588395
Content-Type: text/plain; charset=UTF-8

I don't care for the syntax either, but I just do this somewhere:

using postfix_t = int;

So, the code ends up looking like this:

class thing
{
public:

    thing &operator ++ (postfix_t);
};

Readable? Maybe. Another stupid typedef to confuse newcomers? Yes.

My suggestion would be an alternative for any member operator:

class thing
{
public:
    thing &operator this++(); // postfix
    thing &operator ++this(); // prefix

    thing &operator this + (const thing &);
    thing &operator this / (const thing &);

    thing &operator * (const thing &); // allow old syntax, too...
};


--

---
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_4111_1714646771.1426494588395
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I don't care for the syntax either, but I just do this som=
ewhere:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(25=
0, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border=
-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">using</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> p=
ostfix_t </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><b=
r>So, the code ends up looking like this:<br><br><div class=3D"prettyprint"=
 style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187,=
 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><cod=
e class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> thing<br></span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">public</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br><br>&nbsp; &nbsp; thing </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&amp;</span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">operator</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">++</span><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">postfix_t</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span></div></code></div><br>Readabl=
e? Maybe. Another stupid typedef to confuse newcomers? Yes.<br><br>My sugge=
stion would be an alternative for any member operator:<br><br><div class=3D=
"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: =
rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: brea=
k-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> thing<br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">public</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>&nbsp; &nbsp; thing </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">operator</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">this</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">++();</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// =
postfix</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>&nbsp; &nbsp; thing </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&amp;</span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">operator</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">++</s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">this</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #800;" class=3D"styled-by-prettify">// prefix</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br><br>&nbsp; &nbsp; thing </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">operator</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">this</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">c=
onst</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> thing=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;);</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &=
nbsp; thing </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&amp;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">ope=
rator</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">this</span><sp=
an 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"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">const</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> thing </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&amp;);</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br><br>&nbsp; &nbsp; thing </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&amp;</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">operator</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> thing </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&amp;);</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #800;" class=3D"styled-by-prettify">// allow old syntax, too...</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></di=
v><br><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 />

------=_Part_4111_1714646771.1426494588395--
------=_Part_4110_1327665243.1426494588395--

.

------=_Part_3867_956864490.1426519296351
Content-Type: multipart/alternative;
 boundary="----=_Part_3868_1663934694.1426519296351"

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

+1.

Except supporting old construct.

=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 16 =D0=BC=D0=
=B0=D1=80=D1=82 2015 =D0=B3., 10:29:48 UTC+2, Chris Gary =D0=BD=D0=B0=D0=BF=
=D0=B8=D1=81=D0=B0:
>
> I don't care for the syntax either, but I just do this somewhere:
>
> using postfix_t =3D int;
>
> So, the code ends up looking like this:
>
> class thing
> {
> public:
>
>     thing &operator ++ (postfix_t);
> };
>
> Readable? Maybe. Another stupid typedef to confuse newcomers? Yes.
>
> My suggestion would be an alternative for any member operator:
>
> class thing
> {
> public:
>     thing &operator this++(); // postfix
>     thing &operator ++this(); // prefix
>
>     thing &operator this + (const thing &);
>     thing &operator this / (const thing &);
>
>     thing &operator * (const thing &); // allow old syntax, too...
> };
>
>
>

--=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_3868_1663934694.1426519296351
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">+1.<div><br></div><div>Except supporting old construct.<br=
><div><br>=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 16 =
=D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 10:29:48 UTC+2, Chris Gary =D0=BD=D0=
=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr">I don't care for the syntax either, but I just do this somew=
here:<br><br><div style=3D"background-color:rgb(250,250,250);border-color:r=
gb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><=
code><div><span style=3D"color:#008">using</span><span style=3D"color:#000"=
> postfix_t </span><span style=3D"color:#660">=3D</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#008">int</span><span style=3D"color:#=
660">;</span><span style=3D"color:#000"><br></span></div></code></div><br>S=
o, the code ends up looking like this:<br><br><div style=3D"background-colo=
r:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-=
width:1px;word-wrap:break-word"><code><div><span style=3D"color:#008">class=
</span><span style=3D"color:#000"> thing<br></span><span style=3D"color:#66=
0">{</span><span style=3D"color:#000"><br></span><span style=3D"color:#008"=
>public</span><span style=3D"color:#660">:</span><span style=3D"color:#000"=
><br><br>&nbsp; &nbsp; thing </span><span style=3D"color:#660">&amp;</span>=
<span style=3D"color:#008">operator</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#660">++</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#660">(</span><span style=3D"color:#000">postfix_t</span=
><span style=3D"color:#660">);</span><span style=3D"color:#000"><br></span>=
<span style=3D"color:#660">};</span><span style=3D"color:#000"><br></span><=
/div></code></div><br>Readable? Maybe. Another stupid typedef to confuse ne=
wcomers? Yes.<br><br>My suggestion would be an alternative for any member o=
perator:<br><br><div style=3D"background-color:rgb(250,250,250);border-colo=
r:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word=
"><code><div><span style=3D"color:#008">class</span><span style=3D"color:#0=
00"> thing<br></span><span style=3D"color:#660">{</span><span style=3D"colo=
r:#000"><br></span><span style=3D"color:#008">public</span><span style=3D"c=
olor:#660">:</span><span style=3D"color:#000"><br>&nbsp; &nbsp; thing </spa=
n><span style=3D"color:#660">&amp;</span><span style=3D"color:#008">operato=
r</span><span style=3D"color:#000"> </span><span style=3D"color:#008">this<=
/span><span style=3D"color:#660">++();</span><span style=3D"color:#000"> </=
span><span style=3D"color:#800">// postfix</span><span style=3D"color:#000"=
><br>&nbsp; &nbsp; thing </span><span style=3D"color:#660">&amp;</span><spa=
n style=3D"color:#008">operator</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#660">++</span><span style=3D"color:#008">this</span><sp=
an style=3D"color:#660">();</span><span style=3D"color:#000"> </span><span =
style=3D"color:#800">// prefix</span><span style=3D"color:#000"><br><br>&nb=
sp; &nbsp; thing </span><span style=3D"color:#660">&amp;</span><span style=
=3D"color:#008">operator</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#008">this</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">+</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">(</span><span style=3D"color:#008">const</span><span style=3D"co=
lor:#000"> thing </span><span style=3D"color:#660">&amp;);</span><span styl=
e=3D"color:#000"><br>&nbsp; &nbsp; thing </span><span style=3D"color:#660">=
&amp;</span><span style=3D"color:#008">operator</span><span style=3D"color:=
#000"> </span><span style=3D"color:#008">this</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#660">/</span><span style=3D"color:#000"> =
</span><span style=3D"color:#660">(</span><span style=3D"color:#008">const<=
/span><span style=3D"color:#000"> thing </span><span style=3D"color:#660">&=
amp;);</span><span style=3D"color:#000"><br><br>&nbsp; &nbsp; thing </span>=
<span style=3D"color:#660">&amp;</span><span style=3D"color:#008">operator<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">*</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">(</span><spa=
n style=3D"color:#008">const</span><span style=3D"color:#000"> thing </span=
><span style=3D"color:#660">&amp;);</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#800">// allow old syntax, too...</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#660">};</span><span style=
=3D"color:#000"><br></span></div></code></div><br><br></div></blockquote></=
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 />

------=_Part_3868_1663934694.1426519296351--
------=_Part_3867_956864490.1426519296351--

.

On 16 March 2015 at 17:21, Alexander Nikolov <sasho648@mail.bg> wrote:
> +1.
>
> Except supporting old construct.

Dropping support for the current way to define these operators is unacceptable.
That also means that the new syntax would actually need to be a compelling fix
for a real problem, which is not the case. I have no doubt this proposal will
be rejected by the committee. It's a microscopic fix looking for an
actual problem.

--

---
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_3925_109646012.1426527340641
Content-Type: multipart/alternative;
 boundary="----=_Part_3926_279554558.1426527340641"

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

I already pointed out the problem which is hardly understanding of existing=
=20
code and also hardly writing new one without taking time to understand this=
=20
odd construct.

Can you please point out the reasons why 'dropping support for the current=
=20
way to define these operators is unacceptable'? I already pointed out mine=
=20
for why not.

I'll be very happy if someone include this propose for syntax change=20
alongside fixes for other similar odd constructs. Because I just don't have=
=20
time for writing such things.

=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 16 =D0=BC=D0=
=B0=D1=80=D1=82 2015 =D0=B3., 17:27:37 UTC+2, Ville Voutilainen =D0=BD=D0=
=B0=D0=BF=D0=B8=D1=81=D0=B0:
>
> On 16 March 2015 at 17:21, Alexander Nikolov <sash...@mail.bg=20
> <javascript:>> wrote:=20
> > +1.=20
> >=20
> > Except supporting old construct.=20
>
> Dropping support for the current way to define these operators is=20
> unacceptable.=20
> That also means that the new syntax would actually need to be a compellin=
g=20
> fix=20
> for a real problem, which is not the case. I have no doubt this proposal=
=20
> will=20
> be rejected by the committee. It's a microscopic fix looking for an=20
> actual problem.=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_3926_279554558.1426527340641
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I already pointed out the problem which is hardly understa=
nding of existing code and also hardly writing new one without taking time =
to understand this odd construct.<div><br></div><div>Can you please point o=
ut the reasons why 'dropping support for the current way to define these op=
erators is unacceptable'? I already pointed out mine for why not.</div><div=
><br></div><div>I'll be very happy if someone include this propose for synt=
ax change alongside fixes for other similar odd constructs. Because I just =
don't have time for writing such things.</div><div><br>=D0=BF=D0=BE=D0=BD=
=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 16 =D0=BC=D0=B0=D1=80=D1=82 201=
5 =D0=B3., 17:27:37 UTC+2, Ville Voutilainen =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 16 March 2015 at 17:=
21, Alexander Nikolov &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"G6ZXlmhMvcYJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;">sash...@mail.bg</a>&gt; wrote:
<br>&gt; +1.
<br>&gt;
<br>&gt; Except supporting old construct.
<br>
<br>Dropping support for the current way to define these operators is unacc=
eptable.
<br>That also means that the new syntax would actually need to be a compell=
ing fix
<br>for a real problem, which is not the case. I have no doubt this proposa=
l will
<br>be rejected by the committee. It's a microscopic fix looking for an
<br>actual problem.
<br></blockquote></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_3926_279554558.1426527340641--
------=_Part_3925_109646012.1426527340641--

.

On 16 March 2015 at 19:35, Alexander Nikolov <sasho648@mail.bg> wrote:
> I already pointed out the problem which is hardly understanding of existing
> code and also hardly writing new one without taking time to understand this
> odd construct.

Those difficulties don't seem to be frequent enough to warrant a language
change, as far as I can see.

> Can you please point out the reasons why 'dropping support for the current
> way to define these operators is unacceptable'? I already pointed out mine
> for why not.

Because it breaks existing valid and reasonable code for no good reason.

--

---
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_547_101811388.1426527883592
Content-Type: multipart/alternative;
 boundary="----=_Part_548_1747015104.1426527883592"

------=_Part_548_1747015104.1426527883592
Content-Type: text/plain; charset=UTF-8

On Monday, March 16, 2015 at 1:35:40 PM UTC-4, Alexander Nikolov wrote:
>
> I already pointed out the problem which is hardly understanding of
> existing code and also hardly writing new one without taking time to
> understand this odd construct.
>

Yes, and as we've pointed out, this is not a *significant* problem. Yes,
it's odd. Yes, it's not easy to understand. But in the grand scheme of
things, it's just *not that important*.

Just because it's a pain point for you personally does not make it one in
some objective sense.

Can you please point out the reasons why 'dropping support for the current
> way to define these operators is unacceptable'? I already pointed out mine
> for why not.
>

Because it breaks people's existing code. The fact that they could simply
rewrite it does not change the fact that they've been *broken*.

Breaking existing code is not something the standards committee does
lightly. Even removing the old use of 'auto' was done *only* after careful
investigation of existing codebases to see how often it was used. And that
change would only require users to just delete that use of 'auto'.

--

---
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_548_1747015104.1426527883592
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, March 16, 2015 at 1:35:40 PM UTC-4, Alexander N=
ikolov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
I already pointed out the problem which is hardly understanding of existing=
 code and also hardly writing new one without taking time to understand thi=
s odd construct.</div></blockquote><div><br>Yes, and as we've pointed out, =
this is not a <i>significant</i> problem. Yes, it's odd. Yes, it's not easy=
 to understand. But in the grand scheme of things, it's just <i>not that im=
portant</i>.<br><br>Just because it's a pain point for you personally does =
not make it one in some objective sense.<br><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>Can you please poi=
nt out the reasons why 'dropping support for the current way to define thes=
e operators is unacceptable'? I already pointed out mine for why not.</div>=
</div></blockquote><div><br>Because it breaks people's existing code. The f=
act that they could simply rewrite it does not change the fact that they've=
 been <i>broken</i>.<br><br>Breaking existing code is not something the sta=
ndards committee does lightly. Even removing the old use of 'auto' was done=
 <i>only</i> after careful investigation of existing codebases to see how o=
ften it was used. And that change would only require users to just delete t=
hat use of 'auto'.<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_548_1747015104.1426527883592--
------=_Part_547_101811388.1426527883592--

.

------=_Part_4160_1696591619.1426528115868
Content-Type: multipart/alternative;
 boundary="----=_Part_4161_327475667.1426528115868"

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

I think the reason is good enough for itself but perhaps this depends on=20
the view point.

=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 16 =D0=BC=D0=
=B0=D1=80=D1=82 2015 =D0=B3., 19:39:36 UTC+2, Ville Voutilainen =D0=BD=D0=
=B0=D0=BF=D0=B8=D1=81=D0=B0:
>
> On 16 March 2015 at 19:35, Alexander Nikolov <sash...@mail.bg=20
> <javascript:>> wrote:=20
> > I already pointed out the problem which is hardly understanding of=20
> existing=20
> > code and also hardly writing new one without taking time to understand=
=20
> this=20
> > odd construct.=20
>
> Those difficulties don't seem to be frequent enough to warrant a language=
=20
> change, as far as I can see.=20
>
> > Can you please point out the reasons why 'dropping support for the=20
> current=20
> > way to define these operators is unacceptable'? I already pointed out=
=20
> mine=20
> > for why not.=20
>
> Because it breaks existing valid and reasonable code for no good reason.=
=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_4161_327475667.1426528115868
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think the reason is good enough for itself but perhaps t=
his depends on the view point.<br><br>=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=
=D0=BB=D0=BD=D0=B8=D0=BA, 16 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 19:39:3=
6 UTC+2, Ville Voutilainen =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">On 16 March 2015 at 19:35, Alexander Niko=
lov &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
9wAizTURX7IJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';ret=
urn true;" onclick=3D"this.href=3D'javascript:';return true;">sash...@mail.=
bg</a>&gt; wrote:
<br>&gt; I already pointed out the problem which is hardly understanding of=
 existing
<br>&gt; code and also hardly writing new one without taking time to unders=
tand this
<br>&gt; odd construct.
<br>
<br>Those difficulties don't seem to be frequent enough to warrant a langua=
ge
<br>change, as far as I can see.
<br>
<br>&gt; Can you please point out the reasons why 'dropping support for the=
 current
<br>&gt; way to define these operators is unacceptable'? I already pointed =
out mine
<br>&gt; for why not.
<br>
<br>Because it breaks existing valid and reasonable code for no good reason=
..
<br></blockquote></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_4161_327475667.1426528115868--
------=_Part_4160_1696591619.1426528115868--

.

------=_Part_3849_443675404.1426528795718
Content-Type: multipart/alternative;
 boundary="----=_Part_3850_1236498878.1426528795728"

------=_Part_3850_1236498878.1426528795728
Content-Type: text/plain; charset=UTF-8

Also perhaps this small change for itself will be not anything important to
consider but if someone includes in a big proposal with fix for all other
odd constructs it will be far more significant.


@Nicol Bolas

Isn't this modern C++ or what? People which are using old code-bases will
have a lot of options. They'll either have to:


   1. Continue compiling against older C++ standards.
   2. Use automated-tools converting their codes into newer C++ standards.
   3. Convert their code by themselves.
   4. Convert code partially and compile different files against different
   C++ standard versions.

In every case this is a big choice. Otherwise soon we'll have very
unreadable mess with one hundred new keywords and standard libraries which
should 'patch' older code.
Understanding code then will be a night-mare - times harder then if we just
change come existing constructs.

--

---
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_3850_1236498878.1426528795728
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Also perhaps this small change for itself will be not anyt=
hing important to consider but if someone includes in a big proposal with f=
ix for all other odd constructs it will be far more significant.<div><br></=
div><div><br></div><div>@<span class=3D"_username" style=3D"white-space: no=
wrap;"><span class=3D"MJ2FHSC-O-a">Nicol Bolas</span></span><span style=3D"=
white-space: nowrap;">&nbsp;</span></div><div><span style=3D"white-space: n=
owrap;"><br></span></div><div><span style=3D"white-space: nowrap;">Isn't th=
is modern C++ or what? People which are using old code-bases will have a lo=
t of options. They'll either have to:</span><br><br><ol><li><span style=3D"=
line-height: normal; white-space: nowrap;">Continue compiling against older=
 C++ standards.</span></li><li><span style=3D"line-height: normal; white-sp=
ace: nowrap;">Use automated-tools converting their codes into newer C++ sta=
ndards.</span></li><li><span style=3D"line-height: normal; white-space: now=
rap;">Convert their code by themselves.</span></li><li><span style=3D"line-=
height: normal; white-space: nowrap;">Convert code partially and compile di=
fferent files against different C++ standard versions.</span></li></ol><div=
><span style=3D"white-space: nowrap;">In every case this is a big choice. O=
therwise soon we'll have very unreadable mess with one hundred new keywords=
 and standard libraries which should 'patch' older code.<br>Understanding c=
ode then will be a night-mare - times harder then if we just change come ex=
isting constructs.</span></div></div><div><span style=3D"white-space: nowra=
p;"><br></span></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_3850_1236498878.1426528795728--
------=_Part_3849_443675404.1426528795718--

.

FWIW, I've never had any problems with writing and understanding code
for operator++(int) and operator--(int).

On 3/16/15, Alexander Nikolov <sasho648@mail.bg> wrote:
> Also perhaps this small change for itself will be not anything important to
>
> consider but if someone includes in a big proposal with fix for all other
> odd constructs it will be far more significant.
>
>
> @Nicol Bolas
>
> Isn't this modern C++ or what? People which are using old code-bases will
> have a lot of options. They'll either have to:
>
>
>    1. Continue compiling against older C++ standards.
>    2. Use automated-tools converting their codes into newer C++ standards.
>    3. Convert their code by themselves.
>    4. Convert code partially and compile different files against different
>    C++ standard versions.
>
> In every case this is a big choice. Otherwise soon we'll have very
> unreadable mess with one hundred new keywords and standard libraries which
> should 'patch' older code.
> Understanding code then will be a night-mare - times harder then if we just
>
> change come existing constructs.
>
> --
>
> ---
> 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/.

.

------=_Part_4285_1697318614.1426538872487
Content-Type: multipart/alternative;
 boundary="----=_Part_4286_1808662397.1426538872487"

------=_Part_4286_1808662397.1426538872487
Content-Type: text/plain; charset=UTF-8



On Monday, March 16, 2015 at 1:59:55 PM UTC-4, Alexander Marinov wrote:
>
> Also perhaps this small change for itself will be not anything important
> to consider but if someone includes in a big proposal with fix for all
> other odd constructs it will be far more significant.
>
>
> @Nicol Bolas
>
> Isn't this modern C++ or what? People which are using old code-bases will
> have a lot of options. They'll either have to:
>
>
>    1. Continue compiling against older C++ standards.
>
> Python 3.x. How many Python-based projects, big, *important* ones have
completely rejected it? And why was that? Oh right, lack of backwards
compatibility in key areas.

Let's make this clear: splintering the C++ community, even if this were not
something incredibly trivial, *is not an option*. That's what we call a
"non-starter".

>
>    1. Use automated-tools converting their codes into newer C++ standards.
>
> Which can break your code. Also, such tools have to be written and
maintained by someone.

>
>    1. Convert their code by themselves.
>
> Which serves no genuine purpose, since the new code does the exact same
thing as the old. In short: you're wasting time.

>
>    1. Convert code partially and compile different files against
>    different C++ standard versions.
>
> That's just splintering your codebase within a project. Also, it seems
rather difficult to pull off, since any code that includes a header using
the old one will have to be compiled under the old rules.


> In every case this is a big choice. Otherwise soon we'll have very
> unreadable mess with one hundred new keywords and standard libraries which
> should 'patch' older code.
> Understanding code then will be a night-mare - times harder then if we
> just change come existing constructs.
>

We all would like a nice, cleaner looking language, with all the bad ways
cleaned out. I would have loved it if 'typedef' went the way of the Dodo in
C++11 (since we have 'using' aliases that are a functional superset). But
it's not going to happen. So there's no point in asking for it. It just
wastes time.

--

---
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_4286_1808662397.1426538872487
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, March 16, 2015 at 1:59:55 PM UTC-4, Ale=
xander Marinov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">Also perhaps this small change for itself will be not anything imp=
ortant to consider but if someone includes in a big proposal with fix for a=
ll other odd constructs it will be far more significant.<div><br></div><div=
><br></div><div>@<span style=3D"white-space:nowrap"><span>Nicol Bolas</span=
></span><span style=3D"white-space:nowrap">&nbsp;</span></div><div><span st=
yle=3D"white-space:nowrap"><br></span></div><div><span style=3D"white-space=
:nowrap">Isn't this modern C++ or what? People which are using old code-bas=
es will have a lot of options. They'll either have to:</span><br><br><ol><l=
i><span style=3D"line-height:normal;white-space:nowrap">Continue compiling =
against older C++ standards.</span></li></ol></div></div></blockquote><div>=
Python 3.x. How many Python-based projects, big, <i>important</i> ones have=
 completely rejected it? And why was that? Oh right, lack of backwards comp=
atibility in key areas.<br><br>Let's make this clear: splintering the C++ c=
ommunity, even if this were not something incredibly trivial, <i>is not an =
option</i>. That's what we call a "non-starter".<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><ol><li><span style=3D"li=
ne-height:normal;white-space:nowrap">Use automated-tools converting their c=
odes into newer C++ standards.</span></li></ol></div></div></blockquote><di=
v>Which can break your code. Also, such tools have to be written and mainta=
ined by someone.<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
 dir=3D"ltr"><div><ol><li><span style=3D"line-height:normal;white-space:now=
rap">Convert their code by themselves.</span></li></ol></div></div></blockq=
uote><div>Which serves no genuine purpose, since the new code does the exac=
t same thing as the old. In short: you're wasting time. <br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><ol><li><span sty=
le=3D"line-height:normal;white-space:nowrap">Convert code partially and com=
pile different files against different C++ standard versions.</span></li></=
ol></div></div></blockquote><div>That's just splintering your codebase with=
in a project. Also, it seems rather difficult to pull off, since any code t=
hat includes a header using the old one will have to be compiled under the =
old rules.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
 dir=3D"ltr"><div><div><span style=3D"white-space:nowrap">In every case thi=
s is a big choice. Otherwise soon we'll have very unreadable mess with one =
hundred new keywords and standard libraries which should 'patch' older code=
..<br>Understanding code then will be a night-mare - times harder then if we=
 just change come existing constructs.</span></div></div></div></blockquote=
><div><br>We all would like a nice, cleaner looking language, with all the =
bad ways cleaned out. I would have loved it if 'typedef' went the way of th=
e Dodo in C++11 (since we have 'using' aliases that are a functional supers=
et). But it's not going to happen. So there's no point in asking for it. It=
 just wastes time.<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_4286_1808662397.1426538872487--
------=_Part_4285_1697318614.1426538872487--

.

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

Additionally, in the grand scheme of things I expect a C++ developer to be
able to switch from one standard to another, from a legacy project to the
newest green fields task with the newest (even experimental) compiler.  If
the concern is that the old construct is *hard*, the alternative is having
to learn the same *hard* construct and a different one that might be
simpler.  This is not _overall_ simplifying the language but making it more
complex.  If this was adopted, I would have to expect my developers to
understand 'operator++(int)' and whatever form fo 'operator++(postfix)',
together with the understanding that they have to be mutually exclusive.

I value simplicity, there's a few places where I would love a simpler
language, but I don't see how this would simplify anything for users.  And
by the way, I am one of those that never knows how to overload
prefix/postfix, I've never been bothered to learn the detail I have the
standard, books and google to solve that for me.  I don't find that
particularly hard.

http://lmgtfy.com/?q=postfix+operator+overloading+c%2B%2B

    David

On Mon, Mar 16, 2015 at 4:47 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

>
>
> On Monday, March 16, 2015 at 1:59:55 PM UTC-4, Alexander Marinov wrote:
>>
>> Also perhaps this small change for itself will be not anything important
>> to consider but if someone includes in a big proposal with fix for all
>> other odd constructs it will be far more significant.
>>
>>
>> @Nicol Bolas
>>
>> Isn't this modern C++ or what? People which are using old code-bases will
>> have a lot of options. They'll either have to:
>>
>>
>>    1. Continue compiling against older C++ standards.
>>
>> Python 3.x. How many Python-based projects, big, *important* ones have
> completely rejected it? And why was that? Oh right, lack of backwards
> compatibility in key areas.
>
> Let's make this clear: splintering the C++ community, even if this were
> not something incredibly trivial, *is not an option*. That's what we call
> a "non-starter".
>
>>
>>    1. Use automated-tools converting their codes into newer C++
>>    standards.
>>
>> Which can break your code. Also, such tools have to be written and
> maintained by someone.
>
>>
>>    1. Convert their code by themselves.
>>
>> Which serves no genuine purpose, since the new code does the exact same
> thing as the old. In short: you're wasting time.
>
>>
>>    1. Convert code partially and compile different files against
>>    different C++ standard versions.
>>
>> That's just splintering your codebase within a project. Also, it seems
> rather difficult to pull off, since any code that includes a header using
> the old one will have to be compiled under the old rules.
>
>
>> In every case this is a big choice. Otherwise soon we'll have very
>> unreadable mess with one hundred new keywords and standard libraries which
>> should 'patch' older code.
>> Understanding code then will be a night-mare - times harder then if we
>> just change come existing constructs.
>>
>
> We all would like a nice, cleaner looking language, with all the bad ways
> cleaned out. I would have loved it if 'typedef' went the way of the Dodo in
> C++11 (since we have 'using' aliases that are a functional superset). But
> it's not going to happen. So there's no point in asking for it. It just
> wastes time.
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr">Additionally, in the grand scheme of things I expect a C++=
 developer to be able to switch from one standard to another, from a legacy=
 project to the newest green fields task with the newest (even experimental=
) compiler.=C2=A0 If the concern is that the old construct is *hard*, the a=
lternative is having to learn the same *hard* construct and a different one=
 that might be simpler.=C2=A0 This is not _overall_ simplifying the languag=
e but making it more complex.=C2=A0 If this was adopted, I would have to ex=
pect my developers to understand &#39;operator++(int)&#39; and whatever for=
m fo &#39;operator++(postfix)&#39;, together with the understanding that th=
ey have to be mutually exclusive.<br><br>I value simplicity, there&#39;s a =
few places where I would love a simpler language, but I don&#39;t see how t=
his would simplify anything for users.=C2=A0 And by the way, I am one of th=
ose that never knows how to overload prefix/postfix, I&#39;ve never been bo=
thered to learn the detail I have the standard, books and google to solve t=
hat for me.=C2=A0 I don&#39;t find that particularly hard.<br><br><a href=
=3D"http://lmgtfy.com/?q=3Dpostfix+operator+overloading+c%2B%2B">http://lmg=
tfy.com/?q=3Dpostfix+operator+overloading+c%2B%2B</a><br><br>=C2=A0 =C2=A0 =
David</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon=
, Mar 16, 2015 at 4:47 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D=
""><br><br>On Monday, March 16, 2015 at 1:59:55 PM UTC-4, Alexander Marinov=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Also perhap=
s this small change for itself will be not anything important to consider b=
ut if someone includes in a big proposal with fix for all other odd constru=
cts it will be far more significant.<div><br></div><div><br></div><div>@<sp=
an style=3D"white-space:nowrap"><span>Nicol Bolas</span></span><span style=
=3D"white-space:nowrap">=C2=A0</span></div><div><span style=3D"white-space:=
nowrap"><br></span></div><div><span style=3D"white-space:nowrap">Isn&#39;t =
this modern C++ or what? People which are using old code-bases will have a =
lot of options. They&#39;ll either have to:</span><br><br><ol><li><span sty=
le=3D"line-height:normal;white-space:nowrap">Continue compiling against old=
er C++ standards.</span></li></ol></div></div></blockquote></span><div>Pyth=
on 3.x. How many Python-based projects, big, <i>important</i> ones have com=
pletely rejected it? And why was that? Oh right, lack of backwards compatib=
ility in key areas.<br><br>Let&#39;s make this clear: splintering the C++ c=
ommunity, even if this were not something incredibly trivial, <i>is not an =
option</i>. That&#39;s what we call a &quot;non-starter&quot;.<br></div><sp=
an class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
><ol><li><span style=3D"line-height:normal;white-space:nowrap">Use automate=
d-tools converting their codes into newer C++ standards.</span></li></ol></=
div></div></blockquote></span><div>Which can break your code. Also, such to=
ols have to be written and maintained by someone.<br></div><span class=3D""=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><ol><li><spa=
n style=3D"line-height:normal;white-space:nowrap">Convert their code by the=
mselves.</span></li></ol></div></div></blockquote></span><div>Which serves =
no genuine purpose, since the new code does the exact same thing as the old=
.. In short: you&#39;re wasting time. <br></div><span class=3D""><blockquote=
 class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><ol><li><span style=3D"l=
ine-height:normal;white-space:nowrap">Convert code partially and compile di=
fferent files against different C++ standard versions.</span></li></ol></di=
v></div></blockquote></span><div>That&#39;s just splintering your codebase =
within a project. Also, it seems rather difficult to pull off, since any co=
de that includes a header using the old one will have to be compiled under =
the old rules.<br>=C2=A0</div><span class=3D""><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr"><div><div><span style=3D"white-space:nowrap">I=
n every case this is a big choice. Otherwise soon we&#39;ll have very unrea=
dable mess with one hundred new keywords and standard libraries which shoul=
d &#39;patch&#39; older code.<br>Understanding code then will be a night-ma=
re - times harder then if we just change come existing constructs.</span></=
div></div></div></blockquote></span><div><br>We all would like a nice, clea=
ner looking language, with all the bad ways cleaned out. I would have loved=
 it if &#39;typedef&#39; went the way of the Dodo in C++11 (since we have &=
#39;using&#39; aliases that are a functional superset). But it&#39;s not go=
ing to happen. So there&#39;s no point in asking for it. It just wastes tim=
e.<br></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<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" 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>
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 />

--001a113cc7e0dd814205117b987f--

.

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

.... if your concern is in the other direction, when reading code:

http://lmgtfy.com/?q=3Doperator%2B%2B(int)

On Tue, Mar 17, 2015 at 9:03 AM, David Rodr=C3=ADguez Ibeas <dibeas@ieee.or=
g>
wrote:

> Additionally, in the grand scheme of things I expect a C++ developer to b=
e
> able to switch from one standard to another, from a legacy project to the
> newest green fields task with the newest (even experimental) compiler.  I=
f
> the concern is that the old construct is *hard*, the alternative is havin=
g
> to learn the same *hard* construct and a different one that might be
> simpler.  This is not _overall_ simplifying the language but making it mo=
re
> complex.  If this was adopted, I would have to expect my developers to
> understand 'operator++(int)' and whatever form fo 'operator++(postfix)',
> together with the understanding that they have to be mutually exclusive.
>
> I value simplicity, there's a few places where I would love a simpler
> language, but I don't see how this would simplify anything for users.  An=
d
> by the way, I am one of those that never knows how to overload
> prefix/postfix, I've never been bothered to learn the detail I have the
> standard, books and google to solve that for me.  I don't find that
> particularly hard.
>
> http://lmgtfy.com/?q=3Dpostfix+operator+overloading+c%2B%2B
>
>     David
>
> On Mon, Mar 16, 2015 at 4:47 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>>
>>
>> On Monday, March 16, 2015 at 1:59:55 PM UTC-4, Alexander Marinov wrote:
>>>
>>> Also perhaps this small change for itself will be not anything importan=
t
>>> to consider but if someone includes in a big proposal with fix for all
>>> other odd constructs it will be far more significant.
>>>
>>>
>>> @Nicol Bolas
>>>
>>> Isn't this modern C++ or what? People which are using old code-bases
>>> will have a lot of options. They'll either have to:
>>>
>>>
>>>    1. Continue compiling against older C++ standards.
>>>
>>> Python 3.x. How many Python-based projects, big, *important* ones have
>> completely rejected it? And why was that? Oh right, lack of backwards
>> compatibility in key areas.
>>
>> Let's make this clear: splintering the C++ community, even if this were
>> not something incredibly trivial, *is not an option*. That's what we
>> call a "non-starter".
>>
>>>
>>>    1. Use automated-tools converting their codes into newer C++
>>>    standards.
>>>
>>> Which can break your code. Also, such tools have to be written and
>> maintained by someone.
>>
>>>
>>>    1. Convert their code by themselves.
>>>
>>> Which serves no genuine purpose, since the new code does the exact same
>> thing as the old. In short: you're wasting time.
>>
>>>
>>>    1. Convert code partially and compile different files against
>>>    different C++ standard versions.
>>>
>>> That's just splintering your codebase within a project. Also, it seems
>> rather difficult to pull off, since any code that includes a header usin=
g
>> the old one will have to be compiled under the old rules.
>>
>>
>>> In every case this is a big choice. Otherwise soon we'll have very
>>> unreadable mess with one hundred new keywords and standard libraries wh=
ich
>>> should 'patch' older code.
>>> Understanding code then will be a night-mare - times harder then if we
>>> just change come existing constructs.
>>>
>>
>> We all would like a nice, cleaner looking language, with all the bad way=
s
>> cleaned out. I would have loved it if 'typedef' went the way of the Dodo=
 in
>> C++11 (since we have 'using' aliases that are a functional superset). Bu=
t
>> it's not going to happen. So there's no point in asking for it. It just
>> wastes time.
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/.
>>
>
>

--=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/.

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

<div dir=3D"ltr">... if your concern is in the other direction, when readin=
g code:<br><br><a href=3D"http://lmgtfy.com/?q=3Doperator%2B%2B(int)">http:=
//lmgtfy.com/?q=3Doperator%2B%2B(int)</a><br></div><div class=3D"gmail_extr=
a"><br><div class=3D"gmail_quote">On Tue, Mar 17, 2015 at 9:03 AM, David Ro=
dr=C3=ADguez Ibeas <span dir=3D"ltr">&lt;<a href=3D"mailto:dibeas@ieee.org"=
 target=3D"_blank">dibeas@ieee.org</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">Additionally, in the grand scheme of thing=
s I expect a C++ developer to be able to switch from one standard to anothe=
r, from a legacy project to the newest green fields task with the newest (e=
ven experimental) compiler.=C2=A0 If the concern is that the old construct =
is *hard*, the alternative is having to learn the same *hard* construct and=
 a different one that might be simpler.=C2=A0 This is not _overall_ simplif=
ying the language but making it more complex.=C2=A0 If this was adopted, I =
would have to expect my developers to understand &#39;operator++(int)&#39; =
and whatever form fo &#39;operator++(postfix)&#39;, together with the under=
standing that they have to be mutually exclusive.<br><br>I value simplicity=
, there&#39;s a few places where I would love a simpler language, but I don=
&#39;t see how this would simplify anything for users.=C2=A0 And by the way=
, I am one of those that never knows how to overload prefix/postfix, I&#39;=
ve never been bothered to learn the detail I have the standard, books and g=
oogle to solve that for me.=C2=A0 I don&#39;t find that particularly hard.<=
br><br><a href=3D"http://lmgtfy.com/?q=3Dpostfix+operator+overloading+c%2B%=
2B" target=3D"_blank">http://lmgtfy.com/?q=3Dpostfix+operator+overloading+c=
%2B%2B</a><span class=3D"HOEnZb"><font color=3D"#888888"><br><br>=C2=A0 =C2=
=A0 David</font></span></div><div class=3D"HOEnZb"><div class=3D"h5"><div c=
lass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Mar 16, 2015 at=
 4:47 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gma=
il.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><span><br><br>On Monday, March =
16, 2015 at 1:59:55 PM UTC-4, Alexander Marinov wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr">Also perhaps this small change for itse=
lf will be not anything important to consider but if someone includes in a =
big proposal with fix for all other odd constructs it will be far more sign=
ificant.<div><br></div><div><br></div><div>@<span style=3D"white-space:nowr=
ap"><span>Nicol Bolas</span></span><span style=3D"white-space:nowrap">=C2=
=A0</span></div><div><span style=3D"white-space:nowrap"><br></span></div><d=
iv><span style=3D"white-space:nowrap">Isn&#39;t this modern C++ or what? Pe=
ople which are using old code-bases will have a lot of options. They&#39;ll=
 either have to:</span><br><br><ol><li><span style=3D"line-height:normal;wh=
ite-space:nowrap">Continue compiling against older C++ standards.</span></l=
i></ol></div></div></blockquote></span><div>Python 3.x. How many Python-bas=
ed projects, big, <i>important</i> ones have completely rejected it? And wh=
y was that? Oh right, lack of backwards compatibility in key areas.<br><br>=
Let&#39;s make this clear: splintering the C++ community, even if this were=
 not something incredibly trivial, <i>is not an option</i>. That&#39;s what=
 we call a &quot;non-starter&quot;.<br></div><span><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div><ol><li><span style=3D"line-height:no=
rmal;white-space:nowrap">Use automated-tools converting their codes into ne=
wer C++ standards.</span></li></ol></div></div></blockquote></span><div>Whi=
ch can break your code. Also, such tools have to be written and maintained =
by someone.<br></div><span><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div><ol><li><span style=3D"line-height:normal;white-space:nowrap"=
>Convert their code by themselves.</span></li></ol></div></div></blockquote=
></span><div>Which serves no genuine purpose, since the new code does the e=
xact same thing as the old. In short: you&#39;re wasting time. <br></div><s=
pan><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><ol><li><=
span style=3D"line-height:normal;white-space:nowrap">Convert code partially=
 and compile different files against different C++ standard versions.</span=
></li></ol></div></div></blockquote></span><div>That&#39;s just splintering=
 your codebase within a project. Also, it seems rather difficult to pull of=
f, since any code that includes a header using the old one will have to be =
compiled under the old rules.<br>=C2=A0</div><span><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div><div><span style=3D"white-space:nowra=
p">In every case this is a big choice. Otherwise soon we&#39;ll have very u=
nreadable mess with one hundred new keywords and standard libraries which s=
hould &#39;patch&#39; older code.<br>Understanding code then will be a nigh=
t-mare - times harder then if we just change come existing constructs.</spa=
n></div></div></div></blockquote></span><div><br>We all would like a nice, =
cleaner looking language, with all the bad ways cleaned out. I would have l=
oved it if &#39;typedef&#39; went the way of the Dodo in C++11 (since we ha=
ve &#39;using&#39; aliases that are a functional superset). But it&#39;s no=
t going to happen. So there&#39;s no point in asking for it. It just wastes=
 time.<br></div></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" 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>
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>
</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 />

--089e0111dcc22606bf05117b9d00--

.

------=_Part_890_247592994.1426621088060
Content-Type: multipart/alternative;
 boundary="----=_Part_891_1619625919.1426621088060"

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

OK I give up. In every case ISO committee will be on the same opinion as=20
you.

However I predict that keeping compatibility will increase complexity of=20
code and soon you'll see that it would be better if instead some existing=
=20
constructs were changed.

=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 17 =D0=BC=D0=B0=D1=80=D1=82 201=
5 =D0=B3., 15:05:00 UTC+2, David Rodr=C3=ADguez Ibeas =D0=BD=D0=B0=D0=BF=D0=
=B8=D1=81=D0=B0:
>
> ... if your concern is in the other direction, when reading code:
>
> http://lmgtfy.com/?q=3Doperator%2B%2B(int)
>
> On Tue, Mar 17, 2015 at 9:03 AM, David Rodr=C3=ADguez Ibeas <dib...@ieee.=
org=20
> <javascript:>> wrote:
>
>> Additionally, in the grand scheme of things I expect a C++ developer to=
=20
>> be able to switch from one standard to another, from a legacy project to=
=20
>> the newest green fields task with the newest (even experimental) compile=
r. =20
>> If the concern is that the old construct is *hard*, the alternative is=
=20
>> having to learn the same *hard* construct and a different one that might=
 be=20
>> simpler.  This is not _overall_ simplifying the language but making it m=
ore=20
>> complex.  If this was adopted, I would have to expect my developers to=
=20
>> understand 'operator++(int)' and whatever form fo 'operator++(postfix)',=
=20
>> together with the understanding that they have to be mutually exclusive.
>>
>> I value simplicity, there's a few places where I would love a simpler=20
>> language, but I don't see how this would simplify anything for users.  A=
nd=20
>> by the way, I am one of those that never knows how to overload=20
>> prefix/postfix, I've never been bothered to learn the detail I have the=
=20
>> standard, books and google to solve that for me.  I don't find that=20
>> particularly hard.
>>
>> http://lmgtfy.com/?q=3Dpostfix+operator+overloading+c%2B%2B
>>
>>     David
>>
>> On Mon, Mar 16, 2015 at 4:47 PM, Nicol Bolas <jmck...@gmail.com=20
>> <javascript:>> wrote:
>>
>>>
>>>
>>> On Monday, March 16, 2015 at 1:59:55 PM UTC-4, Alexander Marinov wrote:
>>>>
>>>> Also perhaps this small change for itself will be not anything=20
>>>> important to consider but if someone includes in a big proposal with f=
ix=20
>>>> for all other odd constructs it will be far more significant.
>>>>
>>>>
>>>> @Nicol Bolas=20
>>>>
>>>> Isn't this modern C++ or what? People which are using old code-bases=
=20
>>>> will have a lot of options. They'll either have to:
>>>>
>>>>
>>>>    1. Continue compiling against older C++ standards.
>>>>
>>>> Python 3.x. How many Python-based projects, big, *important* ones have=
=20
>>> completely rejected it? And why was that? Oh right, lack of backwards=
=20
>>> compatibility in key areas.
>>>
>>> Let's make this clear: splintering the C++ community, even if this were=
=20
>>> not something incredibly trivial, *is not an option*. That's what we=20
>>> call a "non-starter".
>>>
>>>>
>>>>    1. Use automated-tools converting their codes into newer C++=20
>>>>    standards.
>>>>
>>>> Which can break your code. Also, such tools have to be written and=20
>>> maintained by someone.
>>>
>>>>
>>>>    1. Convert their code by themselves.
>>>>
>>>> Which serves no genuine purpose, since the new code does the exact sam=
e=20
>>> thing as the old. In short: you're wasting time.=20
>>>
>>>>
>>>>    1. Convert code partially and compile different files against=20
>>>>    different C++ standard versions.
>>>>
>>>> That's just splintering your codebase within a project. Also, it seems=
=20
>>> rather difficult to pull off, since any code that includes a header usi=
ng=20
>>> the old one will have to be compiled under the old rules.
>>> =20
>>>
>>>> In every case this is a big choice. Otherwise soon we'll have very=20
>>>> unreadable mess with one hundred new keywords and standard libraries w=
hich=20
>>>> should 'patch' older code.
>>>> Understanding code then will be a night-mare - times harder then if we=
=20
>>>> just change come existing constructs.
>>>>
>>>
>>> We all would like a nice, cleaner looking language, with all the bad=20
>>> ways cleaned out. I would have loved it if 'typedef' went the way of th=
e=20
>>> Dodo in C++11 (since we have 'using' aliases that are a functional=20
>>> superset). But it's not going to happen. So there's no point in asking =
for=20
>>> it. It just wastes time.
>>>
>>> --=20
>>>
>>> ---=20
>>> You received this message because you are subscribed to the Google=20
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>> an email to std-proposal...@isocpp.org <javascript:>.
>>> To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..
>>> Visit this group at=20
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>>
>

--=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_891_1619625919.1426621088060
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">OK I give up. In every case ISO committee will be on the s=
ame opinion as you.<div><br></div><div>However I predict that keeping compa=
tibility will increase complexity of code and soon you'll see that it would=
 be better if instead some existing constructs were changed.</div><div><br>=
=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 17 =D0=BC=D0=B0=D1=80=D1=82 201=
5 =D0=B3., 15:05:00 UTC+2, David Rodr=C3=ADguez Ibeas =D0=BD=D0=B0=D0=BF=D0=
=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">... if your concern is in the other direction, when reading code:<br><br=
><a href=3D"http://lmgtfy.com/?q=3Doperator%2B%2B(int)" target=3D"_blank" r=
el=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75h=
ttp%3A%2F%2Flmgtfy.com%2F%3Fq%3Doperator%252B%252B(int)\46sa\75D\46sntz\075=
1\46usg\75AFQjCNFO9xZS3MKAn3KesHc5BorjyG9vuw';return true;" onclick=3D"this=
..href=3D'http://www.google.com/url?q\75http%3A%2F%2Flmgtfy.com%2F%3Fq%3Dope=
rator%252B%252B(int)\46sa\75D\46sntz\0751\46usg\75AFQjCNFO9xZS3MKAn3KesHc5B=
orjyG9vuw';return true;">http://lmgtfy.com/?q=3Doperator%<wbr>2B%2B(int)</a=
><br></div><div><br><div class=3D"gmail_quote">On Tue, Mar 17, 2015 at 9:03=
 AM, David Rodr=C3=ADguez Ibeas <span dir=3D"ltr">&lt;<a href=3D"javascript=
:" target=3D"_blank" gdf-obfuscated-mailto=3D"28bHQneE1oMJ" rel=3D"nofollow=
" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hr=
ef=3D'javascript:';return true;">dib...@ieee.org</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr">Additionally, in the grand s=
cheme of things I expect a C++ developer to be able to switch from one stan=
dard to another, from a legacy project to the newest green fields task with=
 the newest (even experimental) compiler.&nbsp; If the concern is that the =
old construct is *hard*, the alternative is having to learn the same *hard*=
 construct and a different one that might be simpler.&nbsp; This is not _ov=
erall_ simplifying the language but making it more complex.&nbsp; If this w=
as adopted, I would have to expect my developers to understand 'operator++(=
int)' and whatever form fo 'operator++(postfix)', together with the underst=
anding that they have to be mutually exclusive.<br><br>I value simplicity, =
there's a few places where I would love a simpler language, but I don't see=
 how this would simplify anything for users.&nbsp; And by the way, I am one=
 of those that never knows how to overload prefix/postfix, I've never been =
bothered to learn the detail I have the standard, books and google to solve=
 that for me.&nbsp; I don't find that particularly hard.<br><br><a href=3D"=
http://lmgtfy.com/?q=3Dpostfix+operator+overloading+c%2B%2B" target=3D"_bla=
nk" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?=
q\75http%3A%2F%2Flmgtfy.com%2F%3Fq%3Dpostfix%2Boperator%2Boverloading%2Bc%2=
52B%252B\46sa\75D\46sntz\0751\46usg\75AFQjCNHbhajeOsxBHJNnt7lIJiDj3N2GPA';r=
eturn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%=
2F%2Flmgtfy.com%2F%3Fq%3Dpostfix%2Boperator%2Boverloading%2Bc%252B%252B\46s=
a\75D\46sntz\0751\46usg\75AFQjCNHbhajeOsxBHJNnt7lIJiDj3N2GPA';return true;"=
>http://lmgtfy.com/?q=3Dpostfix+<wbr>operator+overloading+c%2B%2B</a><span>=
<font color=3D"#888888"><br><br>&nbsp; &nbsp; David</font></span></div><div=
><div><div><br><div class=3D"gmail_quote">On Mon, Mar 16, 2015 at 4:47 PM, =
Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank"=
 gdf-obfuscated-mailto=3D"28bHQneE1oMJ" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';r=
eturn true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><span><br><br>On Monday, March 16, 2015 at 1=
:59:55 PM UTC-4, Alexander Marinov wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr">Also perhaps this small change for itself will be no=
t anything important to consider but if someone includes in a big proposal =
with fix for all other odd constructs it will be far more significant.<div>=
<br></div><div><br></div><div>@<span style=3D"white-space:nowrap"><span>Nic=
ol Bolas</span></span><span style=3D"white-space:nowrap">&nbsp;</span></div=
><div><span style=3D"white-space:nowrap"><br></span></div><div><span style=
=3D"white-space:nowrap">Isn't this modern C++ or what? People which are usi=
ng old code-bases will have a lot of options. They'll either have to:</span=
><br><br><ol><li><span style=3D"line-height:normal;white-space:nowrap">Cont=
inue compiling against older C++ standards.</span></li></ol></div></div></b=
lockquote></span><div>Python 3.x. How many Python-based projects, big, <i>i=
mportant</i> ones have completely rejected it? And why was that? Oh right, =
lack of backwards compatibility in key areas.<br><br>Let's make this clear:=
 splintering the C++ community, even if this were not something incredibly =
trivial, <i>is not an option</i>. That's what we call a "non-starter".<br><=
/div><span><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><o=
l><li><span style=3D"line-height:normal;white-space:nowrap">Use automated-t=
ools converting their codes into newer C++ standards.</span></li></ol></div=
></div></blockquote></span><div>Which can break your code. Also, such tools=
 have to be written and maintained by someone.<br></div><span><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div><ol><li><span style=3D"lin=
e-height:normal;white-space:nowrap">Convert their code by themselves.</span=
></li></ol></div></div></blockquote></span><div>Which serves no genuine pur=
pose, since the new code does the exact same thing as the old. In short: yo=
u're wasting time. <br></div><span><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div><ol><li><span style=3D"line-height:normal;white-spac=
e:nowrap">Convert code partially and compile different files against differ=
ent C++ standard versions.</span></li></ol></div></div></blockquote></span>=
<div>That's just splintering your codebase within a project. Also, it seems=
 rather difficult to pull off, since any code that includes a header using =
the old one will have to be compiled under the old rules.<br>&nbsp;</div><s=
pan><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><spa=
n style=3D"white-space:nowrap">In every case this is a big choice. Otherwis=
e soon we'll have very unreadable mess with one hundred new keywords and st=
andard libraries which should 'patch' older code.<br>Understanding code the=
n will be a night-mare - times harder then if we just change come existing =
constructs.</span></div></div></div></blockquote></span><div><br>We all wou=
ld like a nice, cleaner looking language, with all the bad ways cleaned out=
.. I would have loved it if 'typedef' went the way of the Dodo in C++11 (sin=
ce we have 'using' aliases that are a functional superset). But it's not go=
ing to happen. So there's no point in asking for it. It just wastes time.<b=
r></div></div><div><div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
28bHQneE1oMJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';ret=
urn true;" onclick=3D"this.href=3D'javascript:';return true;">std-proposal.=
...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"28bHQneE1oMJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:=
';return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';return true=
;" onclick=3D"this.href=3D'http://groups.google.com/a/isocpp.org/group/std-=
proposals/';return true;">http://groups.google.com/a/<wbr>isocpp.org/group/=
std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</blockquote></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_891_1619625919.1426621088060--
------=_Part_890_247592994.1426621088060--

.

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

On Tue, Mar 17, 2015 at 9:03 AM, David Rodr=C3=ADguez Ibeas <dibeas@ieee.or=
g>
wrote:

> Additionally, in the grand scheme of things I expect a C++ developer to b=
e
> able to switch from one standard to another, from a legacy project to the
> newest green fields task with the newest (even experimental) compiler.  I=
f
> the concern is that the old construct is *hard*, the alternative is havin=
g
> to learn the same *hard* construct and a different one that might be
> simpler.  This is not _overall_ simplifying the language but making it mo=
re
> complex.  If this was adopted, I would have to expect my developers to
> understand 'operator++(int)' and whatever form fo 'operator++(postfix)',
> together with the understanding that they have to be mutually exclusive.
>
>
We can, eventually, stop learning old constructs.  ie The 'register'
keyword and the old version of 'auto'.  Maybe some day we will deprecate
typedef.  It just takes a long long time.

The question is just when is it worth it.  Probably isn't worth it in this
case.

--=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/.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Mar 17, 2015 at 9:03 AM, David Rodr=C3=ADguez Ibeas <span dir=
=3D"ltr">&lt;<a href=3D"mailto:dibeas@ieee.org" target=3D"_blank">dibeas@ie=
ee.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr">Additionally, in the grand scheme of things I expect a C++ developer t=
o be able to switch from one standard to another, from a legacy project to =
the newest green fields task with the newest (even experimental) compiler.=
=C2=A0 If the concern is that the old construct is *hard*, the alternative =
is having to learn the same *hard* construct and a different one that might=
 be simpler.=C2=A0 This is not _overall_ simplifying the language but makin=
g it more complex.=C2=A0 If this was adopted, I would have to expect my dev=
elopers to understand &#39;operator++(int)&#39; and whatever form fo &#39;o=
perator++(postfix)&#39;, together with the understanding that they have to =
be mutually exclusive.<br><br></div></blockquote><div><br></div><div>We can=
, eventually, stop learning old constructs.=C2=A0 ie The &#39;register&#39;=
 keyword and the old version of &#39;auto&#39;.=C2=A0 Maybe some day we wil=
l deprecate typedef.=C2=A0 It just takes a long long time.<br><br></div><di=
v>The question is just when is it worth it.=C2=A0 Probably isn&#39;t worth =
it in this case.<br></div><br></div><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 />

--089e01493c22a1f611051183585b--

.

------=_Part_1938_993181942.1457566524041
Content-Type: multipart/alternative;
 boundary="----=_Part_1939_846676464.1457566524042"

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

Hi, I just came across this old thread and thought why not simply add=20
`prefix` and `postfix` as contextual keywords, such that the following=20
declarations are equivalent:
X T::operator++();
X T::operator++() prefix;
//and
X T::operator++(int);
X T::operator++() postfix;

(same with `--` and non-member versions)

This has both backward compatability and clear intent.
If those keywords would be a part of the operator signature in some way,=20
there is no ambiguity between the pre/post versions.
Any thoughts?

On Wednesday, March 18, 2015 at 12:18:30 AM UTC+2, Tony V E wrote:
>
>
>
> On Tue, Mar 17, 2015 at 9:03 AM, David Rodr=C3=ADguez Ibeas <dib...@ieee.=
org=20
> <javascript:>> wrote:
>
>> Additionally, in the grand scheme of things I expect a C++ developer to=
=20
>> be able to switch from one standard to another, from a legacy project to=
=20
>> the newest green fields task with the newest (even experimental) compile=
r. =20
>> If the concern is that the old construct is *hard*, the alternative is=
=20
>> having to learn the same *hard* construct and a different one that might=
 be=20
>> simpler.  This is not _overall_ simplifying the language but making it m=
ore=20
>> complex.  If this was adopted, I would have to expect my developers to=
=20
>> understand 'operator++(int)' and whatever form fo 'operator++(postfix)',=
=20
>> together with the understanding that they have to be mutually exclusive.
>>
>>
> We can, eventually, stop learning old constructs.  ie The 'register'=20
> keyword and the old version of 'auto'.  Maybe some day we will deprecate=
=20
> typedef.  It just takes a long long time.
>
> The question is just when is it worth it.  Probably isn't worth it in thi=
s=20
> case.
>
>
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/f28acaca-0994-4f91-b0d6-2fef5635ca70%40isocpp.or=
g.

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

<div dir=3D"ltr"><div>Hi, I just came across this old thread and thought wh=
y not simply add `prefix` and `postfix` as contextual keywords, such that t=
he following declarations are equivalent:</div><div><span style=3D"color: r=
gb(0, 0, 0); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#39;, couri=
er, monospace; font-size: 10.88px; white-space: nowrap; background-color: r=
gba(0, 0, 0, 0.027451);">X=C2=A0T</span><span class=3D"sy4" style=3D"color:=
 rgb(0, 128, 128); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#39;,=
 courier, monospace; font-size: 10.88px; white-space: nowrap; background-co=
lor: rgba(0, 0, 0, 0.027451);">::</span><span class=3D"me2" style=3D"color:=
 rgb(0, 0, 0); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#39;, cou=
rier, monospace; font-size: 10.88px; white-space: nowrap; background-color:=
 rgba(0, 0, 0, 0.027451);">operator</span><span class=3D"sy2" style=3D"colo=
r: rgb(0, 0, 64); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#39;, =
courier, monospace; font-size: 10.88px; white-space: nowrap; background-col=
or: rgba(0, 0, 0, 0.027451);">++</span><span class=3D"br0" style=3D"color: =
rgb(0, 128, 0); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#39;, co=
urier, monospace; font-size: 10.88px; white-space: nowrap; background-color=
: rgba(0, 0, 0, 0.027451);">(</span><span class=3D"br0" style=3D"color: rgb=
(0, 128, 0); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#39;, couri=
er, monospace; font-size: 10.88px; white-space: nowrap; background-color: r=
gba(0, 0, 0, 0.027451);">)</span><span class=3D"sy4" style=3D"color: rgb(0,=
 128, 128); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#39;, courie=
r, monospace; font-size: 10.88px; white-space: nowrap; background-color: rg=
ba(0, 0, 0, 0.027451);">;</span></div><div><span style=3D"color: rgb(0, 0, =
0); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#39;, courier, monos=
pace; font-size: 10.88px; white-space: nowrap; background-color: rgba(0, 0,=
 0, 0.027451);">X=C2=A0T</span><span class=3D"sy4" style=3D"color: rgb(0, 1=
28, 128); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#39;, courier,=
 monospace; font-size: 10.88px; white-space: nowrap; background-color: rgba=
(0, 0, 0, 0.027451);">::</span><span class=3D"me2" style=3D"color: rgb(0, 0=
, 0); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#39;, courier, mon=
ospace; font-size: 10.88px; white-space: nowrap; background-color: rgba(0, =
0, 0, 0.027451);">operator</span><span class=3D"sy2" style=3D"color: rgb(0,=
 0, 64); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#39;, courier, =
monospace; font-size: 10.88px; white-space: nowrap; background-color: rgba(=
0, 0, 0, 0.027451);">++</span><span class=3D"br0" style=3D"color: rgb(0, 12=
8, 0); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#39;, courier, mo=
nospace; font-size: 10.88px; white-space: nowrap; background-color: rgba(0,=
 0, 0, 0.027451);">(</span><span class=3D"br0" style=3D"color: rgb(0, 128, =
0); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#39;, courier, monos=
pace; font-size: 10.88px; white-space: nowrap; background-color: rgba(0, 0,=
 0, 0.027451);">) prefix</span><span class=3D"sy4" style=3D"color: rgb(0, 1=
28, 128); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#39;, courier,=
 monospace; font-size: 10.88px; white-space: nowrap; background-color: rgba=
(0, 0, 0, 0.027451);">;</span></div><div><font color=3D"#008080" face=3D"De=
jaVuSansMono, DejaVu Sans Mono, courier, monospace"><span style=3D"font-siz=
e: 10.88px; white-space: nowrap;">//and</span></font></div><div><span style=
=3D"color: rgb(0, 0, 0); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono=
&#39;, courier, monospace; font-size: 10.88px; white-space: nowrap; backgro=
und-color: rgba(0, 0, 0, 0.027451);">X T</span><span class=3D"sy4" style=3D=
"color: rgb(0, 128, 128); font-family: DejaVuSansMono, &#39;DejaVu Sans Mon=
o&#39;, courier, monospace; font-size: 10.88px; white-space: nowrap; backgr=
ound-color: rgba(0, 0, 0, 0.027451);">::</span><span class=3D"me2" style=3D=
"color: rgb(0, 0, 0); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#3=
9;, courier, monospace; font-size: 10.88px; white-space: nowrap; background=
-color: rgba(0, 0, 0, 0.027451);">operator</span><span class=3D"sy2" style=
=3D"color: rgb(0, 0, 64); font-family: DejaVuSansMono, &#39;DejaVu Sans Mon=
o&#39;, courier, monospace; font-size: 10.88px; white-space: nowrap; backgr=
ound-color: rgba(0, 0, 0, 0.027451);">++</span><span class=3D"br0" style=3D=
"color: rgb(0, 128, 0); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&=
#39;, courier, monospace; font-size: 10.88px; white-space: nowrap; backgrou=
nd-color: rgba(0, 0, 0, 0.027451);">(</span><span class=3D"kw4" style=3D"co=
lor: rgb(0, 0, 255); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#39=
;, courier, monospace; font-size: 10.88px; white-space: nowrap; background-=
color: rgba(0, 0, 0, 0.027451);">int</span><span class=3D"br0" style=3D"col=
or: rgb(0, 128, 0); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#39;=
, courier, monospace; font-size: 10.88px; white-space: nowrap; background-c=
olor: rgba(0, 0, 0, 0.027451);">)</span><span class=3D"sy4" style=3D"color:=
 rgb(0, 128, 128); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#39;,=
 courier, monospace; font-size: 10.88px; white-space: nowrap; background-co=
lor: rgba(0, 0, 0, 0.027451);">;</span></div><div><span style=3D"color: rgb=
(0, 0, 0); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#39;, courier=
, monospace; font-size: 10.88px; white-space: nowrap; background-color: rgb=
a(0, 0, 0, 0.027451);">X T</span><span class=3D"sy4" style=3D"color: rgb(0,=
 128, 128); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#39;, courie=
r, monospace; font-size: 10.88px; white-space: nowrap; background-color: rg=
ba(0, 0, 0, 0.027451);">::</span><span class=3D"me2" style=3D"color: rgb(0,=
 0, 0); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#39;, courier, m=
onospace; font-size: 10.88px; white-space: nowrap; background-color: rgba(0=
, 0, 0, 0.027451);">operator</span><span class=3D"sy2" style=3D"color: rgb(=
0, 0, 64); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#39;, courier=
, monospace; font-size: 10.88px; white-space: nowrap; background-color: rgb=
a(0, 0, 0, 0.027451);">++</span><span class=3D"br0" style=3D"color: rgb(0, =
128, 0); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#39;, courier, =
monospace; font-size: 10.88px; white-space: nowrap; background-color: rgba(=
0, 0, 0, 0.027451);">(</span><span class=3D"br0" style=3D"color: rgb(0, 128=
, 0); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#39;, courier, mon=
ospace; font-size: 10.88px; white-space: nowrap; background-color: rgba(0, =
0, 0, 0.027451);">) postfix</span><span class=3D"sy4" style=3D"color: rgb(0=
, 128, 128); font-family: DejaVuSansMono, &#39;DejaVu Sans Mono&#39;, couri=
er, monospace; font-size: 10.88px; white-space: nowrap; background-color: r=
gba(0, 0, 0, 0.027451);">;</span></div><div><br></div><div>(same with `--` =
and non-member versions)<font face=3D"DejaVuSansMono, DejaVu Sans Mono, cou=
rier, monospace" color=3D"#000000"><span style=3D"font-size: 10.88px; white=
-space: nowrap;"><br></span></font></div><div><br></div><div><font color=3D=
"#000000" face=3D"arial, sans-serif" size=3D"2"><span style=3D"white-space:=
 nowrap;">This has both backward compatability and clear intent.</span></fo=
nt></div><div><font color=3D"#000000" face=3D"arial, sans-serif" size=3D"2"=
><span style=3D"white-space: nowrap;">If those keywords would be a part of =
the operator signature in some way, there is no=C2=A0ambiguity=C2=A0between=
 the pre/post versions.</span></font></div><div><font color=3D"#000000" fac=
e=3D"arial, sans-serif" size=3D"2"><span style=3D"white-space: nowrap;">Any=
 thoughts?</span></font></div><br>On Wednesday, March 18, 2015 at 12:18:30 =
AM UTC+2, Tony V E wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><br><div><br><div class=3D"gmail_quote">On Tue, Mar 17, 2015 at=
 9:03 AM, David Rodr=C3=ADguez Ibeas <span dir=3D"ltr">&lt;<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"A30oQBu0t8gJ" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" oncli=
ck=3D"this.href=3D&#39;javascript:&#39;;return true;">dib...@ieee.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Additio=
nally, in the grand scheme of things I expect a C++ developer to be able to=
 switch from one standard to another, from a legacy project to the newest g=
reen fields task with the newest (even experimental) compiler.=C2=A0 If the=
 concern is that the old construct is *hard*, the alternative is having to =
learn the same *hard* construct and a different one that might be simpler.=
=C2=A0 This is not _overall_ simplifying the language but making it more co=
mplex.=C2=A0 If this was adopted, I would have to expect my developers to u=
nderstand &#39;operator++(int)&#39; and whatever form fo &#39;operator++(po=
stfix)&#39;, together with the understanding that they have to be mutually =
exclusive.<br><br></div></blockquote><div><br></div><div>We can, eventually=
, stop learning old constructs.=C2=A0 ie The &#39;register&#39; keyword and=
 the old version of &#39;auto&#39;.=C2=A0 Maybe some day we will deprecate =
typedef.=C2=A0 It just takes a long long time.<br><br></div><div>The questi=
on is just when is it worth it.=C2=A0 Probably isn&#39;t worth it in this c=
ase.<br></div><br></div><br></div></div>
</blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f28acaca-0994-4f91-b0d6-2fef5635ca70%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f28acaca-0994-4f91-b0d6-2fef5635ca70=
%40isocpp.org</a>.<br />

------=_Part_1939_846676464.1457566524042--
------=_Part_1938_993181942.1457566524041--

.

On Wed, Mar 9, 2016 at 3:35 PM, Omer Rosler <omer.rosler@gmail.com> wrote:
> Hi, I just came across this old thread and thought why not simply add
> `prefix` and `postfix` as contextual keywords, such that the following
> declarations are equivalent:
> X T::operator++();
> X T::operator++() prefix;
> //and
> X T::operator++(int);
> X T::operator++() postfix;
>
> (same with `--` and non-member versions)
>
> This has both backward compatability and clear intent.
> If those keywords would be a part of the operator signature in some way,
> there is no ambiguity between the pre/post versions.
> Any thoughts?

From upthread:

  using prefix =3D void;
  using postfix =3D int;

  X T::operator++(prefix);
  X T::operator++(postfix);

.... works with existing compilers today.

> On Wednesday, March 18, 2015 at 12:18:30 AM UTC+2, Tony V E wrote:
>>
>>
>>
>> On Tue, Mar 17, 2015 at 9:03 AM, David Rodr=C3=ADguez Ibeas <dib...@ieee=
..org>
>> wrote:
>>>
>>> Additionally, in the grand scheme of things I expect a C++ developer to
>>> be able to switch from one standard to another, from a legacy project t=
o the
>>> newest green fields task with the newest (even experimental) compiler. =
 If
>>> the concern is that the old construct is *hard*, the alternative is hav=
ing
>>> to learn the same *hard* construct and a different one that might be
>>> simpler.  This is not _overall_ simplifying the language but making it =
more
>>> complex.  If this was adopted, I would have to expect my developers to
>>> understand 'operator++(int)' and whatever form fo 'operator++(postfix)'=
,
>>> together with the understanding that they have to be mutually exclusive=
..
>>>
>>
>> We can, eventually, stop learning old constructs.  ie The 'register'
>> keyword and the old version of 'auto'.  Maybe some day we will deprecate
>> typedef.  It just takes a long long time.
>>
>> The question is just when is it worth it.  Probably isn't worth it in th=
is
>> case.
>>
>>
> --
> 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/f28acaca-099=
4-4f91-b0d6-2fef5635ca70%40isocpp.org.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOfiQqk5kasKdb9O8sxQM4_NA5C9VqYhBKeFAnEa6aoTq_t=
7ZQ%40mail.gmail.com.

.

------=_Part_5532_207581096.1458037377404
Content-Type: multipart/alternative;
 boundary="----=_Part_5533_589694727.1458037377404"

------=_Part_5533_589694727.1458037377404
Content-Type: text/plain; charset=UTF-8

I haven't read the entire thread but I'd like to point out that there is
some merit to the generalization of this. In some languages with support
for user-defined operators some, also support specifying the fixity
(pre/post/infix) and precedence levels, Haskell also supports invoking
any named binary functions in infix form, e.g. *foo x y == x `foo` y* , I
know that will freak out some people who's not accustomed to it and it can
be abused but the point of having such support is an aid of creating
lightweight embedded DSLs without reaching out to full-blown
meta-programming facilities with support for syntax extensions.

I think some C++ developers have already experienced the pain of writing
certain types of EDSLs in C++ without this and have resort to obscure
tricks to achieve it, I think you can see this in libraries such as
Boost.Spirit.

On Sunday, March 8, 2015 at 3:54:41 PM UTC, sasho648 wrote:
>
> Wouldn't it be better instead of taking one dummy parameter
> the user-defined function which implements the post-fix ++ or -- operator
> to have declaration similar to the form:
>
> operator ~--()
>
> I personally think that this is a lot more clear then:
>
> operator --(int);
>
> In which the only one function parameter of type 'int' will have a dummy
> value of '0' when instanced.
>
> What do you think?
>
>

--
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/09156144-de2f-485a-a261-c6c0e0c41139%40isocpp.org.

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

<div dir=3D"ltr">I haven&#39;t read the entire thread but I&#39;d like to p=
oint out that there is some merit to the generalization of this. In some la=
nguages with support for user-defined operators some, also support specifyi=
ng the=C2=A0fixity (pre/post/infix) and precedence levels, Haskell also sup=
ports invoking any=C2=A0named=C2=A0binary functions in infix form, e.g. <i>=
foo x y =3D=3D x <b>`</b>foo<b>`</b> y</i> , I know that will freak out som=
e people who&#39;s not accustomed to it and it can be abused but the point =
of having such support is an aid of creating lightweight embedded DSLs with=
out reaching out to full-blown meta-programming facilities with support for=
 syntax extensions.<div><br></div><div><div>I think some C++ developers hav=
e already experienced the pain of writing certain types of EDSLs in C++ wit=
hout this and have resort to obscure tricks to achieve it, I think you can =
see this in libraries such as Boost.Spirit.<br><br>On Sunday, March 8, 2015=
 at 3:54:41 PM UTC, sasho648 wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr">Wouldn&#39;t it be better instead of taking one dumm=
y parameter the=C2=A0user-defined function which implements the post-fix ++=
 or -- operator to have declaration similar to the form:<br><br><div style=
=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-color=
:rgb(250,250,250)"><code><div><span style=3D"color:#008">operator</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#660">~--()</span></di=
v></code></div><div><br></div><div>I personally think that this is a lot mo=
re clear then:</div><div><br></div><div><div style=3D"border:1px solid rgb(=
187,187,187);word-wrap:break-word;background-color:rgb(250,250,250)"><code>=
<div><span style=3D"color:#008">operator</span><span style=3D"color:#000"> =
</span><span style=3D"color:#660">--(</span><span style=3D"color:#008">int<=
/span><span style=3D"color:#660">);</span></div></code></div><br>In which t=
he only one function parameter of type &#39;int&#39; will have a dummy valu=
e of &#39;0&#39; when instanced.<br><br>What do you think?<br></div><div><b=
r></div></div></blockquote></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/09156144-de2f-485a-a261-c6c0e0c41139%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/09156144-de2f-485a-a261-c6c0e0c41139=
%40isocpp.org</a>.<br />

------=_Part_5533_589694727.1458037377404--
------=_Part_5532_207581096.1458037377404--

.

------=_Part_94_456540400.1458048590978
Content-Type: multipart/alternative;
 boundary="----=_Part_95_676631806.1458048590978"

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

Sorry for the late response,
Those aliases look more like a patch than an actual solution.
As I see it, it's a problem of the core the language so a language solution=
=20
is more appropriate (but maybe that's just me).
With a different grammer there is a clear path to eradicate this oddity=20
from new code and maybe with tools, as suggested upthread, from existing=20
code (and maybe even deprecation and removal, but that would be many years=
=20
from now).


On Thursday, March 10, 2016 at 2:36:24 AM UTC+2, Richard Smith wrote:
>
> On Wed, Mar 9, 2016 at 3:35 PM, Omer Rosler <omer....@gmail.com=20
> <javascript:>> wrote:=20
> > Hi, I just came across this old thread and thought why not simply add=
=20
> > `prefix` and `postfix` as contextual keywords, such that the following=
=20
> > declarations are equivalent:=20
> > X T::operator++();=20
> > X T::operator++() prefix;=20
> > //and=20
> > X T::operator++(int);=20
> > X T::operator++() postfix;=20
> >=20
> > (same with `--` and non-member versions)=20
> >=20
> > This has both backward compatability and clear intent.=20
> > If those keywords would be a part of the operator signature in some way=
,=20
> > there is no ambiguity between the pre/post versions.=20
> > Any thoughts?=20
>
> From upthread:=20
>
>   using prefix =3D void;=20
>   using postfix =3D int;=20
>
>   X T::operator++(prefix);=20
>   X T::operator++(postfix);=20
>
> ... works with existing compilers today.=20
>
> > On Wednesday, March 18, 2015 at 12:18:30 AM UTC+2, Tony V E wrote:=20
> >>=20
> >>=20
> >>=20
> >> On Tue, Mar 17, 2015 at 9:03 AM, David Rodr=C3=ADguez Ibeas <dib...@ie=
ee.org>=20
>
> >> wrote:=20
> >>>=20
> >>> Additionally, in the grand scheme of things I expect a C++ developer=
=20
> to=20
> >>> be able to switch from one standard to another, from a legacy project=
=20
> to the=20
> >>> newest green fields task with the newest (even experimental) compiler=
..=20
>  If=20
> >>> the concern is that the old construct is *hard*, the alternative is=
=20
> having=20
> >>> to learn the same *hard* construct and a different one that might be=
=20
> >>> simpler.  This is not _overall_ simplifying the language but making i=
t=20
> more=20
> >>> complex.  If this was adopted, I would have to expect my developers t=
o=20
> >>> understand 'operator++(int)' and whatever form fo=20
> 'operator++(postfix)',=20
> >>> together with the understanding that they have to be mutually=20
> exclusive.=20
> >>>=20
> >>=20
> >> We can, eventually, stop learning old constructs.  ie The 'register'=
=20
> >> keyword and the old version of 'auto'.  Maybe some day we will=20
> deprecate=20
> >> typedef.  It just takes a long long time.=20
> >>=20
> >> The question is just when is it worth it.  Probably isn't worth it in=
=20
> this=20
> >> case.=20
> >>=20
> >>=20
> > --=20
> > You received this message because you are subscribed to the Google=20
> Groups=20
> > "ISO C++ Standard - Future Proposals" group.=20
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an=20
> > email to std-proposal...@isocpp.org <javascript:>.=20
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..=20
>
> > To view this discussion on the web visit=20
> >=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f28acaca-099=
4-4f91-b0d6-2fef5635ca70%40isocpp.org.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7ca90cde-f8d6-435b-97c1-5474490d1001%40isocpp.or=
g.

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

<div dir=3D"ltr">Sorry for the late response,<div>Those aliases look more l=
ike a patch than an actual solution.</div><div>As I see it, it&#39;s a prob=
lem of the core the language so a language solution is more appropriate (bu=
t maybe that&#39;s just me).</div><div>With a different grammer there is a =
clear path to eradicate this oddity from new code and maybe with tools, as =
suggested upthread, from existing code (and maybe even deprecation and remo=
val, but that would be many years from now).</div><div><br><br>On Thursday,=
 March 10, 2016 at 2:36:24 AM UTC+2, Richard Smith wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">On Wed, Mar 9, 2016 at 3:35 PM, Omer Rosler &lt=
;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"gYDsEoi=
5BgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">omer=
.....@gmail.com</a>&gt; wrote:
<br>&gt; Hi, I just came across this old thread and thought why not simply =
add
<br>&gt; `prefix` and `postfix` as contextual keywords, such that the follo=
wing
<br>&gt; declarations are equivalent:
<br>&gt; X T::operator++();
<br>&gt; X T::operator++() prefix;
<br>&gt; //and
<br>&gt; X T::operator++(int);
<br>&gt; X T::operator++() postfix;
<br>&gt;
<br>&gt; (same with `--` and non-member versions)
<br>&gt;
<br>&gt; This has both backward compatability and clear intent.
<br>&gt; If those keywords would be a part of the operator signature in som=
e way,
<br>&gt; there is no ambiguity between the pre/post versions.
<br>&gt; Any thoughts?
<br>
<br>From upthread:
<br>
<br>=C2=A0 using prefix =3D void;
<br>=C2=A0 using postfix =3D int;
<br>
<br>=C2=A0 X T::operator++(prefix);
<br>=C2=A0 X T::operator++(postfix);
<br>
<br>... works with existing compilers today.
<br>
<br>&gt; On Wednesday, March 18, 2015 at 12:18:30 AM UTC+2, Tony V E wrote:
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; On Tue, Mar 17, 2015 at 9:03 AM, David Rodr=C3=ADguez Ibeas &l=
t;<a>dib...@ieee.org</a>&gt;
<br>&gt;&gt; wrote:
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; Additionally, in the grand scheme of things I expect a C++=
 developer to
<br>&gt;&gt;&gt; be able to switch from one standard to another, from a leg=
acy project to the
<br>&gt;&gt;&gt; newest green fields task with the newest (even experimenta=
l) compiler. =C2=A0If
<br>&gt;&gt;&gt; the concern is that the old construct is *hard*, the alter=
native is having
<br>&gt;&gt;&gt; to learn the same *hard* construct and a different one tha=
t might be
<br>&gt;&gt;&gt; simpler. =C2=A0This is not _overall_ simplifying the langu=
age but making it more
<br>&gt;&gt;&gt; complex. =C2=A0If this was adopted, I would have to expect=
 my developers to
<br>&gt;&gt;&gt; understand &#39;operator++(int)&#39; and whatever form fo =
&#39;operator++(postfix)&#39;,
<br>&gt;&gt;&gt; together with the understanding that they have to be mutua=
lly exclusive.
<br>&gt;&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; We can, eventually, stop learning old constructs. =C2=A0ie The=
 &#39;register&#39;
<br>&gt;&gt; keyword and the old version of &#39;auto&#39;. =C2=A0Maybe som=
e day we will deprecate
<br>&gt;&gt; typedef. =C2=A0It just takes a long long time.
<br>&gt;&gt;
<br>&gt;&gt; The question is just when is it worth it. =C2=A0Probably isn&#=
39;t worth it in this
<br>&gt;&gt; case.
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt; --
<br>&gt; You received this message because you are subscribed to the Google=
 Groups
<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"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"gYDsEoi5BgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;r=
eturn true;">std-proposal...@<wbr>isocpp.org</a>.
<br>&gt; To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"gYDsEoi5BgAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.
<br>&gt; To view this discussion on the web visit
<br>&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/f28acaca-0994-4f91-b0d6-2fef5635ca70%40isocpp.org" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/f28acaca-0994-4f91-b0d6-2fef5635ca70%40i=
socpp.org&#39;;return true;" onclick=3D"this.href=3D&#39;https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/f28acaca-0994-4f91-b0d6-2fef5635=
ca70%40isocpp.org&#39;;return true;">https://groups.google.com/a/<wbr>isocp=
p.org/d/msgid/std-<wbr>proposals/f28acaca-0994-4f91-<wbr>b0d6-2fef5635ca70%=
40isocpp.org</a><wbr>.
<br></blockquote></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7ca90cde-f8d6-435b-97c1-5474490d1001%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7ca90cde-f8d6-435b-97c1-5474490d1001=
%40isocpp.org</a>.<br />

------=_Part_95_676631806.1458048590978--
------=_Part_94_456540400.1458048590978--

.

------=_Part_692_233488431.1458049004645
Content-Type: multipart/alternative;
 boundary="----=_Part_693_1187609764.1458049004645"

------=_Part_693_1187609764.1458049004645
Content-Type: text/plain; charset=UTF-8



On Tuesday, March 15, 2016 at 9:29:51 AM UTC-4, Omer Rosler wrote:
>
> Sorry for the late response,
> Those aliases look more like a patch than an actual solution.
> As I see it, it's a problem of the core the language so a language
> solution is more appropriate (but maybe that's just me).
>

Except that it is not a problem that is *worthy* of a language solution.
It's not preventing people from learning how to do it or writing code. It's
not preventing people from doing what they need to.

It's just ugly. Well... so what?

--
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/c883e463-fe06-475c-80ce-5f6591195341%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Tuesday, March 15, 2016 at 9:29:51 AM UTC-4, Om=
er Rosler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">Sorry for the late response,<div>Those aliases look more like a patch th=
an an actual solution.</div><div>As I see it, it&#39;s a problem of the cor=
e the language so a language solution is more appropriate (but maybe that&#=
39;s just me).</div></div></blockquote><div><br>Except that it is not a pro=
blem that is <i>worthy</i> of a language solution. It&#39;s not preventing =
people from learning how to do it or writing code. It&#39;s not preventing =
people from doing what they need to.<br><br>It&#39;s just ugly. Well... so =
what?</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c883e463-fe06-475c-80ce-5f6591195341%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c883e463-fe06-475c-80ce-5f6591195341=
%40isocpp.org</a>.<br />

------=_Part_693_1187609764.1458049004645--
------=_Part_692_233488431.1458049004645--

.

On ter=C3=A7a-feira, 15 de mar=C3=A7o de 2016 06:29:50 PDT Omer Rosler wrot=
e:
> Those aliases look more like a patch than an actual solution.

Solution implies a problem. We're not agreeing there is a problem in the fi=
rst=20
place, which means we disagree that we need an invasive change.

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

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3522796.cA4LnGkYVR%40tjmaciei-mobl4.

.

On 3/15/2016 8:36 AM, Nicol Bolas wrote:
> Except that it is not a problem that is /worthy/ of a language solution.
> It's not preventing people from learning how to do it or writing code.
> It's not preventing people from doing what they need to.

It'd be a fairly small language solution, though. Most of the structure
is already there.

Overall, I'm neutral on this proposal, since it would look nicer to use
a context-sensitive keyword, but there are probably 1000 other things
I'd rather see the committee spend their time on. Maybe when C++ is
very-nearly perfect, we can come back to issues like this.

- Jim

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

.

I'll just admit that when I need to implement ++, I still need to look up s=
omewhere which is which :-(

Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Jim Porter
Sent: Tuesday, March 15, 2016 2:58 PM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Subject: [std-proposals] Re: Post-fix operator declaration change.

On 3/15/2016 8:36 AM, Nicol Bolas wrote:
> Except that it is not a problem that is /worthy/ of a language solution.
> It's not preventing people from learning how to do it or writing code.
> It's not preventing people from doing what they need to.

It'd be a fairly small language solution, though. Most of the structure=20
is already there.

Overall, I'm neutral on this proposal, since it would look nicer to use=20
a context-sensitive keyword, but there are probably 1000 other things=20
I'd rather see the committee spend their time on. Maybe when C++ is=20
very-nearly perfect, we can come back to issues like this.

- Jim

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/nc9m12%24qtj%241%40ger.gmane.org.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20160315193156.4935763.67850.8133%40gmail.com.

.

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

The one that avoids a temporary is the one that requires the least typing
in its signature, typically :)

2016-03-15 15:31 GMT-04:00 Tony V E <tvaneerd@gmail.com>:

> I'll just admit that when I need to implement ++, I still need to look up
> somewhere which is which :-(
>
> Sent from my BlackBerry portable Babbage Device
>   Original Message
> From: Jim Porter
> Sent: Tuesday, March 15, 2016 2:58 PM
> To: std-proposals@isocpp.org
> Reply To: std-proposals@isocpp.org
> Subject: [std-proposals] Re: Post-fix operator declaration change.
>
> On 3/15/2016 8:36 AM, Nicol Bolas wrote:
> > Except that it is not a problem that is /worthy/ of a language solution.
> > It's not preventing people from learning how to do it or writing code.
> > It's not preventing people from doing what they need to.
>
> It'd be a fairly small language solution, though. Most of the structure
> is already there.
>
> Overall, I'm neutral on this proposal, since it would look nicer to use
> a context-sensitive keyword, but there are probably 1000 other things
> I'd rather see the committee spend their time on. Maybe when C++ is
> very-nearly perfect, we can come back to issues like this.
>
> - Jim
>
> --
> 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/nc9m12%24qtj%241%40ger.gmane.org
> .
>
> --
> 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/20160315193156.4935763.67850.8133%40gmail.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/CAKiZDp35Z2QNaLmGk3H7YOCMf%2BtHN6CLZJyjHVriN0%3DSRVDWtQ%40mail.gmail.com.

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

<div dir=3D"ltr">The one that avoids a temporary is the one that requires t=
he least typing in its signature, typically :)<br></div><div class=3D"gmail=
_extra"><br><div class=3D"gmail_quote">2016-03-15 15:31 GMT-04:00 Tony V E =
<span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blan=
k">tvaneerd@gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I&#=
39;ll just admit that when I need to implement ++, I still need to look up =
somewhere which is which :-(<br>
<br>
Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce<br>
=C2=A0 Original Message =C2=A0<br>
From: Jim Porter<br>
Sent: Tuesday, March 15, 2016 2:58 PM<br>
To: <a href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a=
><br>
Reply To: <a href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.=
org</a><br>
Subject: [std-proposals] Re: Post-fix operator declaration change.<br>
<div><div class=3D"h5"><br>
On 3/15/2016 8:36 AM, Nicol Bolas wrote:<br>
&gt; Except that it is not a problem that is /worthy/ of a language solutio=
n.<br>
&gt; It&#39;s not preventing people from learning how to do it or writing c=
ode.<br>
&gt; It&#39;s not preventing people from doing what they need to.<br>
<br>
It&#39;d be a fairly small language solution, though. Most of the structure=
<br>
is already there.<br>
<br>
Overall, I&#39;m neutral on this proposal, since it would look nicer to use=
<br>
a context-sensitive keyword, but there are probably 1000 other things<br>
I&#39;d rather see the committee spend their time on. Maybe when C++ is<br>
very-nearly perfect, we can come back to issues like this.<br>
<br>
- Jim<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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/nc9m12%24qtj%241%40ger.gmane.org" rel=
=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/=
msgid/std-proposals/nc9m12%24qtj%241%40ger.gmane.org</a>.<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>
</div></div>To view this discussion on the web visit <a href=3D"https://gro=
ups.google.com/a/isocpp.org/d/msgid/std-proposals/20160315193156.4935763.67=
850.8133%40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/20160315193156.4935763.67850.8=
133%40gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp35Z2QNaLmGk3H7YOCMf%2BtHN6CLZJ=
yjHVriN0%3DSRVDWtQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp35Z2QN=
aLmGk3H7YOCMf%2BtHN6CLZJyjHVriN0%3DSRVDWtQ%40mail.gmail.com</a>.<br />

--001a1143ea84cc7f4e052e206d03--

.

On ter=C3=A7a-feira, 15 de mar=C3=A7o de 2016 21:28:19 PDT Patrice Roy wrot=
e:
> The one that avoids a temporary is the one that requires the least typing
> in its signature, typically

Another rule of thumb: the one that you really want to use (because it avoi=
ds=20
the temporary) is the obvious one :-)

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

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1869433.zV1pDda5sR%40tjmaciei-mobl4.

.