------=_Part_1297_1086162295.1487792961340
Content-Type: multipart/alternative;
 boundary="----=_Part_1298_340349424.1487792961340"

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

=3D=3D Problem =3D=3D
Some math operators are missing from the standard.

=3D=3D Workaround used in current libraries =3D=3D
* Use functions
The Eigen library (http://eigen.tuxfamily.org/) uses a.cross(b) and=20
a.dot(b), instead of "a=C3=97b" and "a=C2=B7b".
The point of introducing operators in c++ was precisely to avoid doing that=
..

* Hack some existing operators
The versor library (http://versor.mat.ucsb.edu/) uses "a%b" and "a<=3Db"=20
instead of "a=C3=97b" and "a=C2=B7b".
I find it quite clumsy to hack some operators to give them a completely non=
=20
intuitive meaning. I would rather not do that.


=3D=3D Proposal =3D=3D
Allow more operators, possibly using characters not currently in the c++=20
character set, such as "a=C2=B7b" "a=E2=88=A7b" "a=C3=97b" or possibly usin=
g multiple=20
characters such as "a**b" "a cross b" "a dot b".
Using characters not currently in the c++ character set guaranties backward=
=20
compatibility, and is easier to read I think.

The =C2=B7 and =C3=97 operators are already missing in the two main math li=
braries of=20
interest to me, which shows that it would be useful to add them.=20
Interest in an exponent operator has already been shown in another topic=20
(** and *^ have been suggested there, I think ** is better, compiler just=
=20
need to parse things properly to avoid issues that we had with operators >>=
=20
or >=3D and templates).
The wedge operator is important too and even if using the operator^ instead=
=20
is ok, it could be added as well while we are at it.

=3D=3D Related topics =3D=3D
https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/mathe=
matical$20operators/std-proposals/Xr8H8V_fnEs/gbW1uBImoSQJ
https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/new$2=
0operators/std-proposals/uTOtGMYyJEo/KA9z8TSfnHEJ

--=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/53de9adb-1e05-46fc-8ac9-75fb331720fa%40isocpp.or=
g.

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

<div dir=3D"ltr">=3D=3D Problem =3D=3D<br>Some math operators are missing f=
rom the standard.<br><br>=3D=3D Workaround used in current libraries =3D=3D=
<br>* Use functions<br>The Eigen library (<a href=3D"http://eigen.tuxfamily=
..org/">http://eigen.tuxfamily.org/</a>) uses a.cross(b) and a.dot(b), inste=
ad of &quot;a=C3=97b&quot; and &quot;a=C2=B7b&quot;.<br>The point of introd=
ucing operators in c++ was precisely to avoid doing that.<br><br>* Hack som=
e existing operators<br>The versor library (<a href=3D"http://versor.mat.uc=
sb.edu/">http://versor.mat.ucsb.edu/</a>) uses &quot;a%b&quot; and &quot;a&=
lt;=3Db&quot; instead of &quot;a=C3=97b&quot; and &quot;a=C2=B7b&quot;.<br>=
I find it quite clumsy to hack some=20
operators to give them a completely non intuitive meaning. I would rather n=
ot do that.<br><br><br>=3D=3D Proposal =3D=3D<br>Allow more operators, poss=
ibly using characters not currently in the c++ character set, such as &quot=
;a=C2=B7b&quot; &quot;a=E2=88=A7b&quot; &quot;a=C3=97b&quot; or possibly us=
ing multiple characters such as &quot;a**b&quot; &quot;a cross b&quot; &quo=
t;a dot b&quot;.<br>Using characters not currently in the c++ character set=
 guaranties backward compatibility, and is easier to read I think.<br><br>T=
he =C2=B7 and =C3=97 operators are already missing in the two main math lib=
raries of interest to me, which shows that it would be useful to add them. =
<br>Interest in an exponent operator has already been shown in another topi=
c (** and *^ have been suggested there, I think ** is better, compiler just=
 need to parse things properly to avoid issues that we had with operators &=
gt;&gt; or &gt;=3D and templates).<br>The wedge operator is important too a=
nd even if using the operator^ instead is ok, it could be added as well whi=
le we are at it.<br><br>=3D=3D Related topics =3D=3D<br>https://groups.goog=
le.com/a/isocpp.org/forum/#!searchin/std-proposals/mathematical$20operators=
/std-proposals/Xr8H8V_fnEs/gbW1uBImoSQJ<br>https://groups.google.com/a/isoc=
pp.org/forum/#!searchin/std-proposals/new$20operators/std-proposals/uTOtGMY=
yJEo/KA9z8TSfnHEJ<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/53de9adb-1e05-46fc-8ac9-75fb331720fa%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/53de9adb-1e05-46fc-8ac9-75fb331720fa=
%40isocpp.org</a>.<br />

------=_Part_1298_340349424.1487792961340--

------=_Part_1297_1086162295.1487792961340--

.

Instead of specifically adding those specific operators, I rather like a
more general solution - that has probably been discussed before: infix
calling notation for functions.

As an extended uniform call syntax allow a binary function call `f(a,
b)` to be written as `a f b`.
I don't know whether this would work like so, but maybe `a `f` b` or
something like that?

This would allow the `a cross b` and `a dot b` you wanted.

--
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/9bec1bf1-7fa6-faa4-4372-789b91387ce6%40gmail.com.

.

On 02/22/17 22:49, godefv@gmail.com wrote:
>
> =3D=3D Proposal =3D=3D
> Allow more operators, possibly using characters not currently in the c++
> character set, such as "a=C2=B7b" "a=E2=88=A7b" "a=C3=97b"

That would be too difficult to type, IMO.

> or possibly using multiple
> characters such as "a**b" "a cross b" "a dot b".

Allowing user-defined operators of arbitrary spelling might be=20
impossible because of conflicts with the C++ grammar. There might be=20
other issues, too, like distinguishing operators from declarations.

   sqrt x; // variable declaration or an operator call?

Adding new operators with fixed spelling to the standard might be more=20
feasible.

--=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/7bc2257e-1acc-97f4-4ef2-7d936f1191aa%40gmail.com=
..

.

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

On Wed, Feb 22, 2017 at 1:49 PM, <godefv@gmail.com> wrote:

> =3D=3D Problem =3D=3D
> Some math operators are missing from the standard.
>
> =3D=3D Workaround used in current libraries =3D=3D
> * Use functions
> The Eigen library (http://eigen.tuxfamily.org/) uses a.cross(b) and
> a.dot(b), instead of "a=C3=97b" and "a=C2=B7b".
> The point of introducing operators in c++ was precisely to avoid doing
> that.
>
> * Hack some existing operators
> The versor library (http://versor.mat.ucsb.edu/) uses "a%b" and "a<=3Db"
> instead of "a=C3=97b" and "a=C2=B7b".
> I find it quite clumsy to hack some operators to give them a completely
> non intuitive meaning. I would rather not do that.
>
>
> =3D=3D Proposal =3D=3D
> Allow more operators, possibly using characters not currently in the c++
> character set, such as "a=C2=B7b" "a=E2=88=A7b" "a=C3=97b" or possibly us=
ing multiple
> characters such as "a**b" "a cross b" "a dot b".
> Using characters not currently in the c++ character set guaranties
> backward compatibility, and is easier to read I think.
>
> The =C2=B7 and =C3=97 operators are already missing in the two main math =
libraries
> of interest to me, which shows that it would be useful to add them.
> Interest in an exponent operator has already been shown in another topic
> (** and *^ have been suggested there, I think ** is better, compiler just
> need to parse things properly to avoid issues that we had with operators =
>>
> or >=3D and templates).
> The wedge operator is important too and even if using the operator^
> instead is ok, it could be added as well while we are at it.
>
> =3D=3D Related topics =3D=3D
> https://groups.google.com/a/isocpp.org/forum/#!searchin/
> std-proposals/mathematical$20operators/std-proposals/
> Xr8H8V_fnEs/gbW1uBImoSQJ
> https://groups.google.com/a/isocpp.org/forum/#!searchin/
> std-proposals/new$20operators/std-proposals/uTOtGMYyJEo/KA9z8TSfnHEJ
>

As I understand, some current C++ compilers still natively require EBCDIC
encoding which doesn't appear to be able to represent those characters. If
that is so, this may be difficult to get through as IBM may object.

--=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/CADbh%2BeREHL%2BFTsR3aGASEHfVyKFf1PQcb7R0_BEWkYZ=
9b_C7Mw%40mail.gmail.com.

--001a114046c4b66f58054923f6df
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 Wed, Feb 22, 2017 at 1:49 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:g=
odefv@gmail.com" target=3D"_blank">godefv@gmail.com</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=3D=3D Problem =3D=3D<br>=
Some math operators are missing from the standard.<br><br>=3D=3D Workaround=
 used in current libraries =3D=3D<br>* Use functions<br>The Eigen library (=
<a href=3D"http://eigen.tuxfamily.org/" target=3D"_blank">http://eigen.tuxf=
amily.org/</a>) uses a.cross(b) and a.dot(b), instead of &quot;a=C3=97b&quo=
t; and &quot;a=C2=B7b&quot;.<br>The point of introducing operators in c++ w=
as precisely to avoid doing that.<br><br>* Hack some existing operators<br>=
The versor library (<a href=3D"http://versor.mat.ucsb.edu/" target=3D"_blan=
k">http://versor.mat.ucsb.edu/</a>) uses &quot;a%b&quot; and &quot;a&lt;=3D=
b&quot; instead of &quot;a=C3=97b&quot; and &quot;a=C2=B7b&quot;.<br>I find=
 it quite clumsy to hack some=20
operators to give them a completely non intuitive meaning. I would rather n=
ot do that.<br><br><br>=3D=3D Proposal =3D=3D<br>Allow more operators, poss=
ibly using characters not currently in the c++ character set, such as &quot=
;a=C2=B7b&quot; &quot;a=E2=88=A7b&quot; &quot;a=C3=97b&quot; or possibly us=
ing multiple characters such as &quot;a**b&quot; &quot;a cross b&quot; &quo=
t;a dot b&quot;.<br>Using characters not currently in the c++ character set=
 guaranties backward compatibility, and is easier to read I think.<br><br>T=
he =C2=B7 and =C3=97 operators are already missing in the two main math lib=
raries of interest to me, which shows that it would be useful to add them. =
<br>Interest in an exponent operator has already been shown in another topi=
c (** and *^ have been suggested there, I think ** is better, compiler just=
 need to parse things properly to avoid issues that we had with operators &=
gt;&gt; or &gt;=3D and templates).<br>The wedge operator is important too a=
nd even if using the operator^ instead is ok, it could be added as well whi=
le we are at it.<br><br>=3D=3D Related topics =3D=3D<br><a href=3D"https://=
groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/mathematical$=
20operators/std-proposals/Xr8H8V_fnEs/gbW1uBImoSQJ" target=3D"_blank">https=
://groups.google.com/a/<wbr>isocpp.org/forum/#!searchin/<wbr>std-proposals/=
mathematical$<wbr>20operators/std-proposals/<wbr>Xr8H8V_fnEs/gbW1uBImoSQJ</=
a><br><a href=3D"https://groups.google.com/a/isocpp.org/forum/#!searchin/st=
d-proposals/new$20operators/std-proposals/uTOtGMYyJEo/KA9z8TSfnHEJ" target=
=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/forum/#!searchin/<w=
br>std-proposals/new$20operators/<wbr>std-proposals/uTOtGMYyJEo/<wbr>KA9z8T=
SfnHEJ</a></div></blockquote><div><br></div><div>As I understand, some curr=
ent C++ compilers still natively require EBCDIC encoding which doesn&#39;t =
appear to be able to represent those characters. If that is so, this may be=
 difficult to get through as IBM may object.</div><div><br></div></div><br>=
</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/CADbh%2BeREHL%2BFTsR3aGASEHfVyKFf1PQc=
b7R0_BEWkYZ9b_C7Mw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeREHL=
%2BFTsR3aGASEHfVyKFf1PQcb7R0_BEWkYZ9b_C7Mw%40mail.gmail.com</a>.<br />

--001a114046c4b66f58054923f6df--

.

------=_Part_1986_1993467249.1487794488248
Content-Type: multipart/alternative;
 boundary="----=_Part_1987_138989736.1487794488248"

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

Le mercredi 22 f=C3=A9vrier 2017 21:00:20 UTC+1, Andrey Semashev a =C3=A9cr=
it :
>
> On 02/22/17 22:49, god...@gmail.com <javascript:> wrote:=20
> >=20
> > =3D=3D Proposal =3D=3D=20
> > Allow more operators, possibly using characters not currently in the c+=
+=20
> > character set, such as "a=C2=B7b" "a=E2=88=A7b" "a=C3=97b"=20
>
> That would be too difficult to type, IMO.=20
>

If you have a compose key it is easy, by defaut =C2=B7 is compose . . and =
=C3=97 is=20
compose x x.
You could also define your own key binding.
If you really find it too difficult, your IDE could help you with that.
Finally, in most cases, you write code less often than you read it.

But obviously, this goes in the "cons" column.
=20

>
> > or possibly using multiple=20
> > characters such as "a**b" "a cross b" "a dot b".=20
>
> Allowing user-defined operators of arbitrary spelling might be=20
> impossible because of conflicts with the C++ grammar. There might be=20
> other issues, too, like distinguishing operators from declarations.=20
>
>    sqrt x; // variable declaration or an operator call?=20
>

sqrt does not takes two arguments, this argument is not valid for "a cross=
=20
b".
=20

>
> Adding new operators with fixed spelling to the standard might be more=20
> feasible.=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/e4a1b783-70a9-43d0-a092-a99d690acd53%40isocpp.or=
g.

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

<div dir=3D"ltr">Le mercredi 22 f=C3=A9vrier 2017 21:00:20 UTC+1, Andrey Se=
mashev a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 0=
2/22/17 22:49, <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"Ue1S2ctYBwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javas=
cript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;retu=
rn true;">god...@gmail.com</a> wrote:
<br>&gt;
<br>&gt; =3D=3D Proposal =3D=3D
<br>&gt; Allow more operators, possibly using characters not currently in t=
he c++
<br>&gt; character set, such as &quot;a=C2=B7b&quot; &quot;a=E2=88=A7b&quot=
; &quot;a=C3=97b&quot;
<br>
<br>That would be too difficult to type, IMO.
<br></blockquote><div><br>If you have a compose key it is easy, by defaut =
=C2=B7 is compose . . and =C3=97 is compose x x.<br>You could also define y=
our own key binding.<br>If you really find it too difficult, your IDE could=
 help you with that.<br>Finally, in most cases, you write code less often t=
han you read it.<br><br>But obviously, this goes in the &quot;cons&quot; co=
lumn.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; or possibly using multiple
<br>&gt; characters such as &quot;a**b&quot; &quot;a cross b&quot; &quot;a =
dot b&quot;.
<br>
<br>Allowing user-defined operators of arbitrary spelling might be=20
<br>impossible because of conflicts with the C++ grammar. There might be=20
<br>other issues, too, like distinguishing operators from declarations.
<br>
<br>=C2=A0 =C2=A0sqrt x; // variable declaration or an operator call?
<br></blockquote><div><br>sqrt does not takes two arguments, this argument =
is not valid for &quot;a cross b&quot;.<br>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;">
<br>Adding new operators with fixed spelling to the standard might be more=
=20
<br>feasible.
<br>
<br></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/e4a1b783-70a9-43d0-a092-a99d690acd53%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e4a1b783-70a9-43d0-a092-a99d690acd53=
%40isocpp.org</a>.<br />

------=_Part_1987_138989736.1487794488248--

------=_Part_1986_1993467249.1487794488248--

.

------=_Part_1908_1878008043.1487794656310
Content-Type: multipart/alternative;
 boundary="----=_Part_1909_1640954876.1487794656311"

------=_Part_1909_1640954876.1487794656311
Content-Type: text/plain; charset=UTF-8


>
> As I understand, some current C++ compilers still natively require EBCDIC
> encoding which doesn't appear to be able to represent those characters. If
> that is so, this may be difficult to get through as IBM may object.
>

Well, if the standard evolves, the compilers need to adapt, this is the
case for any proposal.

--
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/a5579274-87eb-46b3-95f5-92b6174b6c50%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote"><div>As I understand, some current C++ =
compilers still natively require EBCDIC encoding which doesn&#39;t appear t=
o be able to represent those characters. If that is so, this may be difficu=
lt to get through as IBM may object.</div></div></div></div></blockquote><d=
iv><br>Well, if the standard evolves, the compilers need to adapt, this is =
the case for any proposal. <br></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/a5579274-87eb-46b3-95f5-92b6174b6c50%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a5579274-87eb-46b3-95f5-92b6174b6c50=
%40isocpp.org</a>.<br />

------=_Part_1909_1640954876.1487794656311--

------=_Part_1908_1878008043.1487794656310--

.

------=_Part_364_648310909.1487797420715
Content-Type: multipart/alternative;
 boundary="----=_Part_365_1640764010.1487797420715"

------=_Part_365_1640764010.1487797420715
Content-Type: text/plain; charset=UTF-8

On Wednesday, February 22, 2017 at 3:17:36 PM UTC-5, god...@gmail.com wrote:
>
> As I understand, some current C++ compilers still natively require EBCDIC
>> encoding which doesn't appear to be able to represent those characters. If
>> that is so, this may be difficult to get through as IBM may object.
>>
>
> Well, if the standard evolves, the compilers need to adapt, this is the
> case for any proposal.
>

Part of the standard process is evaluating the burden that a feature would
place on compiler developers and deciding if it is worth it or not. Not to
mention the burden on users.

Telling IBM, and every user of IBM's compiler (and therefore *all of their
source code*) that they now have to switch to a completely different
encoding for their files... well, I hope you can see that this isn't a very
workable solution.

Even if that weren't a problem, I just don't think this feature is a good
idea. While it would be nice to add operators to C++, they would only be
directly useful for a very specific set of people. Most C++ users don't go
around doing dot products, cross products, and the like.

Not only that, creating more operators means giving more people the chance
to overload them for less regular uses. And quite frankly, we get enough of
that as is.

--
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/2846b857-1fab-4fcf-b05d-74c117cb4e28%40isocpp.org.

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

<div dir=3D"ltr">On Wednesday, February 22, 2017 at 3:17:36 PM UTC-5, god..=
..@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><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 cla=
ss=3D"gmail_quote"><div>As I understand, some current C++ compilers still n=
atively require EBCDIC encoding which doesn&#39;t appear to be able to repr=
esent those characters. If that is so, this may be difficult to get through=
 as IBM may object.</div></div></div></div></blockquote><div><br>Well, if t=
he standard evolves, the compilers need to adapt, this is the case for any =
proposal. <br></div></div></blockquote><div><br>Part of the standard proces=
s is evaluating the burden that a feature would place on compiler developer=
s and deciding if it is worth it or not. Not to mention the burden on users=
..<br><br>Telling IBM, and every user of IBM&#39;s compiler (and therefore *=
all of their source code*) that they now have to switch to a completely dif=
ferent encoding for their files... well, I hope you can see that this isn&#=
39;t a very workable solution.<br><br>Even if that weren&#39;t a problem, I=
 just don&#39;t think this feature is a good idea. While it would be nice t=
o add operators to C++, they would only be directly useful for a very speci=
fic set of people. Most C++ users don&#39;t go around doing dot products, c=
ross products, and the like.<br><br>Not only that, creating more operators =
means giving more people the chance to overload them for less regular uses.=
 And quite frankly, we get enough of that as is.<br></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/2846b857-1fab-4fcf-b05d-74c117cb4e28%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2846b857-1fab-4fcf-b05d-74c117cb4e28=
%40isocpp.org</a>.<br />

------=_Part_365_1640764010.1487797420715--

------=_Part_364_648310909.1487797420715--

.

On 02/22/17 23:14, godefv@gmail.com wrote:
> Le mercredi 22 f=C3=A9vrier 2017 21:00:20 UTC+1, Andrey Semashev a =C3=A9=
crit :
>
>     On 02/22/17 22:49, god...@gmail.com <javascript:> wrote:
>     >
>     > =3D=3D Proposal =3D=3D
>     > Allow more operators, possibly using characters not currently in
>     the c++
>     > character set, such as "a=C2=B7b" "a=E2=88=A7b" "a=C3=97b"
>
>     That would be too difficult to type, IMO.
>
>
> If you have a compose key it is easy, by defaut =C2=B7 is compose . . and=
 =C3=97
> is compose x x.
> You could also define your own key binding.
> If you really find it too difficult, your IDE could help you with that.

All that doesn't really solve the problem. Even with a compose key,=20
that's 3 keystrokes for an operator character, which one also has to=20
remember.

> Finally, in most cases, you write code less often than you read it.

Readability benefits are quite questionable, IMO. There are enough=20
Unicode characters that have similar appearance.

> But obviously, this goes in the "cons" column.
>
>
>
>     > or possibly using multiple
>     > characters such as "a**b" "a cross b" "a dot b".
>
>     Allowing user-defined operators of arbitrary spelling might be
>     impossible because of conflicts with the C++ grammar. There might be
>     other issues, too, like distinguishing operators from declarations.
>
>        sqrt x; // variable declaration or an operator call?
>
>
> sqrt does not takes two arguments, this argument is not valid for "a
> cross b".

So the proposal only concerns binary operators? Ok, how about this then:

   a cross (b); // function declaration or an operator call?

--=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/3f7941b6-caf2-e135-71c2-78762fddbeb1%40gmail.com=
..

.

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

On 22 February 2017 at 11:54, Jonathan M=C3=BCller <jonathanmueller.dev@gma=
il.com
> wrote:

> Instead of specifically adding those specific operators, I rather like a
> more general solution - that has probably been discussed before: infix
> calling notation for functions.
>
> As an extended uniform call syntax allow a binary function call `f(a, b)`
> to be written as `a f b`.
> I don't know whether this would work like so, but maybe `a `f` b` or
> something like that?
>
> This would allow the `a cross b` and `a dot b` you wanted.


I forget who originally came up with this, but something along these lines
is already possible:


template<typename T> struct identity { typedef T type; };
template<typename T> using identity_t =3D typename identity<T>::type;

template<typename A, typename B, typename C> struct OperatorLhs {
  B b;
  A (*fn)(B, C);
  friend A operator*(OperatorLhs &&lhs, C c) { return
lhs.fn(static_cast<B>(lhs.b), static_cast<C>(c)); }
};
template<typename A, typename B, typename C>
OperatorLhs<A, B, C> operator*(identity_t<B> b, A (*fn)(B, C)) {
  return {static_cast<B>(b), fn};
}


struct Vec {};
Vec cross(const Vec &, const Vec &);

Vec a, b;
Vec x =3D a *cross* b;


(where the choice of the "surrounding" operator dictates the precedence of
the resulting pseudo-operator). This does not support the operator in
question being overloaded (or a template), but you can fix that and package
this up into the following form:


struct Cross : InfixFunction<Cross, std::multiplies> {
  Vec operator()(const Vec &, const Vec&) const;
  // ... more operator() overloads if you want ...
};
inline constexpr Cross cross;

Vec a, b;
Vec x =3D cross(a, b);
Vec y =3D a *cross* b;

--=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/CAOfiQqm1uLt-mm9-P0z0hEwi%3D6%3DjUoe-DTFf6VMyjjS=
pCW5OGg%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
2 February 2017 at 11:54, Jonathan M=C3=BCller <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:jonathanmueller.dev@gmail.com" target=3D"_blank">jonathanmuelle=
r.dev@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">Instead of specifically adding those specific operators, I =
rather like a more general solution - that has probably been discussed befo=
re: infix calling notation for functions.<br>
<br>
As an extended uniform call syntax allow a binary function call `f(a, b)` t=
o be written as `a f b`.<br>
I don&#39;t know whether this would work like so, but maybe `a `f` b` or so=
mething like that?<br>
<br>
This would allow the `a cross b` and `a dot b` you wanted.</blockquote><div=
><br></div><div>I forget who originally came up with this, but something al=
ong these lines is already possible:</div><div><br></div><div><br></div><di=
v>template&lt;typename T&gt; struct identity { typedef T type; };</div><div=
>template&lt;typename T&gt; using identity_t =3D typename identity&lt;T&gt;=
::type;</div><div><br></div><div>template&lt;typename A, typename B, typena=
me C&gt; struct OperatorLhs {</div><div>=C2=A0 B b;</div><div>=C2=A0 A (*fn=
)(B, C);</div><div>=C2=A0 friend A operator*(OperatorLhs &amp;&amp;lhs, C c=
) { return lhs.fn(static_cast&lt;B&gt;(lhs.b), static_cast&lt;C&gt;(c)); }<=
/div><div>};</div><div>template&lt;typename A, typename B, typename C&gt;</=
div><div>OperatorLhs&lt;A, B, C&gt; operator*(identity_t&lt;B&gt; b, A (*fn=
)(B, C)) {</div><div>=C2=A0 return {static_cast&lt;B&gt;(b), fn};</div><div=
>}</div><div><br></div><div><br></div><div>struct Vec {};</div><div>Vec cro=
ss(const Vec &amp;, const Vec &amp;);</div><div><br></div><div>Vec a, b;</d=
iv><div>Vec x =3D a *cross* b;<br></div><div><br></div><div><br></div><div>=
(where the choice of the &quot;surrounding&quot; operator dictates the prec=
edence of the resulting pseudo-operator). This does not support the operato=
r in question being overloaded (or a template), but you can fix that and pa=
ckage this up into the following form:</div><div><br></div><div><br></div><=
div>struct Cross : InfixFunction&lt;Cross, std::multiplies&gt; {</div><div>=
=C2=A0 Vec operator()(const Vec &amp;, const Vec&amp;) const;</div><div>=C2=
=A0 // ... more operator() overloads if you want ...</div><div>};</div><div=
>inline constexpr Cross cross;</div><div><br></div><div>Vec a, b;</div><div=
>Vec x =3D cross(a, b);<br></div><div><div>Vec y =3D a *cross* b;</div></di=
v></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/CAOfiQqm1uLt-mm9-P0z0hEwi%3D6%3DjUoe-=
DTFf6VMyjjSpCW5OGg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqm1uLt-=
mm9-P0z0hEwi%3D6%3DjUoe-DTFf6VMyjjSpCW5OGg%40mail.gmail.com</a>.<br />

--001a113c97fecbb3bd054924f2e4--

.

------=_Part_267_1822726415.1487798178136
Content-Type: multipart/alternative;
 boundary="----=_Part_268_2026775295.1487798178136"

------=_Part_268_2026775295.1487798178136
Content-Type: text/plain; charset=UTF-8


>
>
> I forget who originally came up with this, but something along these lines
> is already possible:
>
>
Yakk: http://stackoverflow.com/a/15090751/2069064

--
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/ab4b9d74-ad9a-46b2-ac29-2c3d4ff1a27b%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div class=3D"gmail_quote"><div><br></div><div>I forget who originally =
came up with this, but something along these lines is already possible:</di=
v><div><br></div></div></div></blockquote><div><br></div><div>Yakk: http://=
stackoverflow.com/a/15090751/2069064</div><div><br></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/ab4b9d74-ad9a-46b2-ac29-2c3d4ff1a27b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ab4b9d74-ad9a-46b2-ac29-2c3d4ff1a27b=
%40isocpp.org</a>.<br />

------=_Part_268_2026775295.1487798178136--

------=_Part_267_1822726415.1487798178136--

.

------=_Part_7961_343871467.1487813441766
Content-Type: multipart/alternative;
 boundary="----=_Part_7962_1052345650.1487813441767"

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

On Wednesday, February 22, 2017 at 1:12:06 PM UTC-8, Richard Smith wrote:
>
> On 22 February 2017 at 11:54, Jonathan M=C3=BCller <jonathanm...@gmail.co=
m=20
> <javascript:>> wrote:
>
>> Instead of specifically adding those specific operators, I rather like a=
=20
>> more general solution - that has probably been discussed before: infix=
=20
>> calling notation for functions.
>>
>> As an extended uniform call syntax allow a binary function call `f(a, b)=
`=20
>> to be written as `a f b`.
>> I don't know whether this would work like so, but maybe `a `f` b` or=20
>> something like that?
>>
>> This would allow the `a cross b` and `a dot b` you wanted.
>
>
> I forget who originally came up with this, but something along these line=
s=20
> is already possible:
>
> struct Vec {};
> Vec cross(const Vec &, const Vec &);
>
> Vec a, b;
> Vec x =3D a *cross* b;
>

I'm sure many people have independently invented this kind of thing. In=20
high school circa 2001, I personally "invented"

    struct cross { ... };  // much boilerplate goes here
    int a, b;
    a &(cross)& b;  // that is, a & static_cast<cross>(&b);

Superficially related, by the way: just the other day I read Nick=20
Athanasiou's relatively clean trick=20
<https://ngathanasiou.wordpress.com/2015/12/15/182/> for using=20
fold-expressions over arbitrary binary functions in C++17, which looks like=
=20
this:

    template<auto F, typename T> auto Foldable(T&&) { ... };  // much=20
boilerplate goes here

    Vec cross2(const Vec &, const Vec &);

    template<typename... Vecs>
    auto crossN(const Vecs&... vecs) {
        return ... + Foldable<cross2>{vecs};   // folds over=20
Foldable<cross2>::operator+, which invokes cross2
    }

=E2=80=93Arthur

>

--=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/e7311756-195a-408f-ab68-84f26a36ae72%40isocpp.or=
g.

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

<div dir=3D"ltr">On Wednesday, February 22, 2017 at 1:12:06 PM UTC-8, Richa=
rd Smith 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 class=3D"gmail_quote">On 22 February 2017 at 11:54, Jonathan M=C3=BC=
ller <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"DsYIXLZcBwAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">jonathanm...@gmail.com</a><wbr>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">Instead of specifically =
adding those specific operators, I rather like a more general solution - th=
at has probably been discussed before: infix calling notation for functions=
..<br>
<br>
As an extended uniform call syntax allow a binary function call `f(a, b)` t=
o be written as `a f b`.<br>
I don&#39;t know whether this would work like so, but maybe `a `f` b` or so=
mething like that?<br>
<br>
This would allow the `a cross b` and `a dot b` you wanted.</blockquote><div=
><br></div><div>I forget who originally came up with this, but something al=
ong these lines is already possible:</div><div><br></div><div>struct Vec {}=
;<br></div><div>Vec cross(const Vec &amp;, const Vec &amp;);</div><div><br>=
</div><div>Vec a, b;</div><div>Vec x =3D a *cross* b;</div></div></div></bl=
ockquote><div><br></div><div>I&#39;m sure many people have independently in=
vented this kind of thing. In high school circa 2001, I personally &quot;in=
vented&quot;</div><div><br></div><div>=C2=A0 =C2=A0 struct cross { ... }; =
=C2=A0// much boilerplate goes here</div><div>=C2=A0 =C2=A0 int a, b;<br></=
div><div>=C2=A0 =C2=A0 a &amp;(cross)&amp; b; =C2=A0// that is, a &amp; sta=
tic_cast&lt;cross&gt;(&amp;b);</div><div><br></div><div>Superficially relat=
ed, by the way: just the other day I read=C2=A0<a href=3D"https://ngathanas=
iou.wordpress.com/2015/12/15/182/">Nick Athanasiou&#39;s relatively clean t=
rick</a> for using fold-expressions over arbitrary binary functions in C++1=
7, which looks like this:</div><div><br></div><div>=C2=A0 =C2=A0 template&l=
t;auto F, typename T&gt; auto Foldable(T&amp;&amp;) { ... }; =C2=A0// much =
boilerplate goes here</div><div><br></div><div>=C2=A0 =C2=A0 Vec cross2(con=
st Vec &amp;, const Vec &amp;);</div><div><br></div><div>=C2=A0 =C2=A0 temp=
late&lt;typename... Vecs&gt;</div><div>=C2=A0 =C2=A0 auto crossN(const Vecs=
&amp;... vecs) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return ... + Foldabl=
e&lt;cross2&gt;{vecs}; =C2=A0 // folds over Foldable&lt;cross2&gt;::operato=
r+, which invokes cross2<br></div><div>=C2=A0 =C2=A0 }</div><div><br></div>=
<div>=E2=80=93Arthur</div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
</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/e7311756-195a-408f-ab68-84f26a36ae72%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e7311756-195a-408f-ab68-84f26a36ae72=
%40isocpp.org</a>.<br />

------=_Part_7962_1052345650.1487813441767--

------=_Part_7961_343871467.1487813441766--

.

------=_Part_2209_1736268713.1487863084646
Content-Type: multipart/alternative;
 boundary="----=_Part_2210_885610941.1487863084646"

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

To summarize:
- the "a cross b" syntax is a bit pointless since we can do "a *cross* b"=
=20
already, which not so bad already, just a bit of boilerplate to define the=
=20
operator, and the operator itself is a bit long.
- the "a=C3=97b" syntax would be troublesome to users who can't type the sy=
mbol=20
easily, and it might not be supported by some compilers easily if they have=
=20
trouble with encoding.
 =20
In my opinion, for the minority users who would use these operators, IBM=20
compiler probably doesn't matter (it doesn't support c++14 anyway according=
=20
to this http://en.cppreference.com/w/cpp/compiler_support), and the syntax=
=20
is much easier to read. Typing is actually quicker with a compose key than=
=20
writing something like "a *cross* b" or "a.cross(b)", and an IDE could help=
=20
for users without means to type non standard characters (for example: alt+.=
=20
alt+x).

The real question might be: is it easy to implement for the 3 major=20
compilers (gcc clang, msvc) ? That I don't know...


About more specific remarks :

> Most C++ users don't go around doing dot products, cross products, and=20
the like.
What about those who do ?

> Not only that, creating more operators means giving more people the=20
chance to overload them for less regular uses. And quite frankly, we get=20
enough of that as is.
The fact that a tool can be misused does not make the tool bad. Moreover,=
=20
some unforeseen uses of a feature can be very good uses too.

--=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/60aa8b65-f134-480d-8bd5-a5c1bc29b212%40isocpp.or=
g.

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

<div dir=3D"ltr">To summarize:<br>- the &quot;a cross b&quot; syntax is a b=
it pointless since we can do &quot;a *cross* b&quot; already, which not so =
bad already, just a bit of boilerplate to define the operator, and the oper=
ator itself is a bit long.<br>-  the &quot;a=C3=97b&quot; syntax would be t=
roublesome to users who can&#39;t type the symbol easily, and it might not =
be supported by some compilers easily if they have trouble with encoding.<b=
r>=C2=A0 <br>In my opinion, for the minority users who would use these oper=
ators, IBM compiler probably doesn&#39;t matter (it doesn&#39;t support c++=
14 anyway according to this http://en.cppreference.com/w/cpp/compiler_suppo=
rt), and the syntax is much easier to read. Typing is actually quicker with=
 a compose key than writing something like &quot;a *cross* b&quot; or &quot=
;a.cross(b)&quot;, and an IDE could help for users without means to type no=
n standard characters (for example: alt+. alt+x).<br><br>The real question =
might be: is it easy to implement for the 3 major compilers (gcc clang, msv=
c) ? That I don&#39;t know...<br><br><br>About more specific remarks :<br><=
br>&gt; Most C++ users don&#39;t go around doing dot products, cross produc=
ts, and the like.<br>What about those who do ?<br><br>&gt; Not only that, c=
reating more operators means giving more people the=20
chance to overload them for less regular uses. And quite frankly, we get
 enough of that as is.<br>The fact that a tool can be misused does not make=
 the tool bad. Moreover, some unforeseen uses of a feature can be very good=
 uses too.<br><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/60aa8b65-f134-480d-8bd5-a5c1bc29b212%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/60aa8b65-f134-480d-8bd5-a5c1bc29b212=
%40isocpp.org</a>.<br />

------=_Part_2210_885610941.1487863084646--

------=_Part_2209_1736268713.1487863084646--

.

On 2017-02-23 16:18, godefv@gmail.com wrote:
> To summarize:
> - the "a cross b" syntax is a bit pointless since we can do "a *cross*
> b" already, which not so bad already, just a bit of boilerplate to
> define the operator, and the operator itself is a bit long.
> - the "a=C3=97b" syntax would be troublesome to users who can't type the
> symbol easily, and it might not be supported by some compilers easily if
> they have trouble with encoding.
>
> In my opinion, for the minority users who would use these operators, IBM
> compiler probably doesn't matter (it doesn't support c++14 anyway
> according to this http://en.cppreference.com/w/cpp/compiler_support),
> and the syntax is much easier to read.

It would also mean that the compiler will NEVER be able to support=20
standard C++, just because it lacks a single character in its default=20
character set.

Isn't that a bit odd for an International Standard?


    Bo Persson





--=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/o8n1gt%24mie%241%40blaine.gmane.org.

.

------=_Part_2102_1784257400.1487867462430
Content-Type: multipart/alternative;
 boundary="----=_Part_2103_774038006.1487867462430"

------=_Part_2103_774038006.1487867462430
Content-Type: text/plain; charset=UTF-8


>
> It would also mean that the compiler will NEVER be able to support
> standard C++, just because it lacks a single character in its default
> character set.
>

You are suggesting that the c++ parser in this compiler is SO badly
designed that it cannot possibly read a character not in its initial
character set - EVER.


> Isn't that a bit odd for an International Standard?
>

 Isn't it really odd that the existence of a badly designed compiler
prevents the c++ standard from providing new features ?

--
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/cfbe2a92-194a-4f50-b0ad-9a1a601a2418%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">It would also=
 mean that the compiler will NEVER be able to support=20
<br>standard C++, just because it lacks a single character in its default=
=20
<br>character set.
<br></blockquote><div><br>You are suggesting that the c++ parser in this co=
mpiler is SO badly designed that it cannot possibly read a character not in=
 its initial character set - EVER.<br></div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">Isn&#39;t that a bit odd for an Internationa=
l Standard?
<br></blockquote><div><br>=C2=A0Isn&#39;t it really odd that the existence =
of a badly designed compiler prevents the c++ standard from providing new f=
eatures ?<br></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/cfbe2a92-194a-4f50-b0ad-9a1a601a2418%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cfbe2a92-194a-4f50-b0ad-9a1a601a2418=
%40isocpp.org</a>.<br />

------=_Part_2103_774038006.1487867462430--

------=_Part_2102_1784257400.1487867462430--

.

On 2017-02-23 17:31, godefv@gmail.com wrote:
>     It would also mean that the compiler will NEVER be able to support
>     standard C++, just because it lacks a single character in its default
>     character set.
>
>
> You are suggesting that the c++ parser in this compiler is SO badly
> designed that it cannot possibly read a character not in its initial
> character set - EVER.
>

I'm saying that the compiler cannot read something that doesn't exist in
the character set.

How would you represent the dot product when there is no dot?


    Bo Persson



--
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/o8n5dq%24k6s%241%40blaine.gmane.org.

.

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

On 23 Feb 2017 9:17 am, "Bo Persson" <bop@gmb.dk> wrote:

On 2017-02-23 17:31, godefv@gmail.com wrote:

>     It would also mean that the compiler will NEVER be able to support
>     standard C++, just because it lacks a single character in its default
>     character set.
>
>
> You are suggesting that the c++ parser in this compiler is SO badly
> designed that it cannot possibly read a character not in its initial
> character set - EVER.
>
>
I'm saying that the compiler cannot read something that doesn't exist in
the character set.

How would you represent the dot product when there is no dot?


As \u00B7, I would imagine.

   Bo Persson




--
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/is
ocpp.org/d/msgid/std-proposals/o8n5dq%24k6s%241%40blaine.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/CAOfiQqko7%2BkoP%2BErRn4bqZLGi_Zaa8L2sLYq4UejSFu6ECRg6Q%40mail.gmail.com.

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

<div dir=3D"auto"><div><div class=3D"gmail_extra"><div class=3D"gmail_quote=
">On 23 Feb 2017 9:17 am, &quot;Bo Persson&quot; &lt;<a href=3D"mailto:bop@=
gmb.dk">bop@gmb.dk</a>&gt; wrote:<br type=3D"attribution"><blockquote class=
=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div class=3D"quoted-text">On 2017-02-23 17:31, <a href=3D"mailto:g=
odefv@gmail.com" target=3D"_blank">godefv@gmail.com</a> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
=C2=A0 =C2=A0 It would also mean that the compiler will NEVER be able to su=
pport<br>
=C2=A0 =C2=A0 standard C++, just because it lacks a single character in its=
 default<br>
=C2=A0 =C2=A0 character set.<br>
<br>
<br>
You are suggesting that the c++ parser in this compiler is SO badly<br>
designed that it cannot possibly read a character not in its initial<br>
character set - EVER.<br>
<br>
</blockquote>
<br></div>
I&#39;m saying that the compiler cannot read something that doesn&#39;t exi=
st in the character set.<br>
<br>
How would you represent the dot product when there is no dot?<br></blockquo=
te></div></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">As \u00B=
7, I would imagine.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div=
 class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
=C2=A0 =C2=A0Bo Persson<div class=3D"quoted-text"><br>
<br>
<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.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></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/o8n5dq%24k6s%241%40blaine.gmane.org" =
rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/is<wbr>ocp=
p.org/d/msgid/std-proposals<wbr>/o8n5dq%24k6s%241%40blaine.<wbr>gmane.org</=
a>.<br>
</blockquote></div><br></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/CAOfiQqko7%2BkoP%2BErRn4bqZLGi_Zaa8L2=
sLYq4UejSFu6ECRg6Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqko7%2B=
koP%2BErRn4bqZLGi_Zaa8L2sLYq4UejSFu6ECRg6Q%40mail.gmail.com</a>.<br />

--001a11423ae8ac92f40549361b86--

.

On quinta-feira, 23 de fevereiro de 2017 07:18:04 PST godefv@gmail.com wrot=
e:
> The real question might be: is it easy to implement for the 3 major
> compilers (gcc clang, msvc) ? That I don't know...

Unless you want this to be an extension supported by those compilers -- and=
 I=20
assume you don't want to, since we're on the standard proposals mailing lis=
t=20
-- you're really looking at extending the C++ basic character set.

You need to convince people of that first. You need a three-phased approach=
:

1) extend the basic character set (you may need a digraphs)
2) creating new operators in C++ (without saying which ones)
3) that some of those new operators should be =C2=B7, =E2=88=A7 and =C3=97

You can do #1 and #2 in parallel.

I expect you'll find heavy resistance in #1 and #2.

--=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/19685075.YErbsEonb8%40tjmaciei-mobl1.

.

On 2017-02-23 18:40, Richard Smith wrote:
> On 23 Feb 2017 9:17 am, "Bo Persson" <bop@gmb.dk <mailto:bop@gmb.dk>> wro=
te:
>
>     On 2017-02-23 17:31, godefv@gmail.com <mailto:godefv@gmail.com> wrote=
:
>
>             It would also mean that the compiler will NEVER be able to
>         support
>             standard C++, just because it lacks a single character in
>         its default
>             character set.
>
>
>         You are suggesting that the c++ parser in this compiler is SO bad=
ly
>         designed that it cannot possibly read a character not in its init=
ial
>         character set - EVER.
>
>
>     I'm saying that the compiler cannot read something that doesn't
>     exist in the character set.
>
>     How would you represent the dot product when there is no dot?
>
>
> As \u00B7, I would imagine.
>

Yes, but that is for Unicode, which we cannot expect. In EBCDIC hex B7=20
would be '=C2=BC'.


We could simplify the language to always assume byte addressability,=20
2's complement, 32-bit ints, IEEE floating point, non-segmented memory,=20
no padding bits, no trap representations, and UTF-8 as the source (and=20
execution) character set.

But do we want to?



    Bo Persson



--=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/o8naaj%24q4f%241%40blaine.gmane.org.

.

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

On Thu, Feb 23, 2017 at 10:40 AM, Bo Persson <bop@gmb.dk> wrote:
>
> On 2017-02-23 18:40, Richard Smith wrote:
>>
>> On 23 Feb 2017 9:17 am, "Bo Persson" <bop@gmb.dk <mailto:bop@gmb.dk>>
wrote:
>>>
>>>    I'm saying that the compiler cannot read something that doesn't
>>>    exist in the character set.
>>>
>>>    How would you represent the dot product when there is no dot?
>>
>> As \u00B7, I would imagine.
>
> Yes, but that is for Unicode, which we cannot expect. In EBCDIC hex B7
would be '=C2=BC'.

I believe Richard means literally "\u00B7", not "=C2=B7".
The C++ Standard already requires that compilers support input such as
\u00B7 in string literals and identifiers and such. (Even \u00B7 itself can
appear in an identifier, which is shocking to me.)

The Standard limply pretends to be Unicode-agnostic by using the term
"universal-character-name" instead of "Unicode codepoint"; but it's
extremely obvious (from sections like 2.10) that these "universal character
names" are just Unicode by another name.

The meaning of "universal-character-name" is defined in 2.3.
See 2.10 for the list of which Unicode characters can appear in identifiers=
..

Fatally to the OP's original proposal, since \u00B7 is currently an
identifier character, Clang already accepts

    constexpr int a\u00B7b =3D 42;
    int func(int a, int b) { return a=C2=B7b; }

as equivalent to

    int func(int a, int b) { return 42; }

I bet GCC also accepts it in some mode that's not the default on Linux.
See it in action here: http://melpon.org/wandbox/permlink/XYAv6rbbxEgtHBYa

HTH,
=E2=80=93Arthur

--=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/CADvuK0%2BCjrdr5hYKT1Yu7GiGBk02d9C1MJ5XX%3DPJrnW=
hyj1%3D_Q%40mail.gmail.com.

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

<div dir=3D"ltr">On Thu, Feb 23, 2017 at 10:40 AM, Bo Persson &lt;<a href=
=3D"mailto:bop@gmb.dk">bop@gmb.dk</a>&gt; wrote:<br>&gt;<br>&gt; On 2017-02=
-23 18:40, Richard Smith wrote:<br>&gt;&gt;<br>&gt;&gt; On 23 Feb 2017 9:17=
 am, &quot;Bo Persson&quot; &lt;<a href=3D"mailto:bop@gmb.dk">bop@gmb.dk</a=
> &lt;mailto:<a href=3D"mailto:bop@gmb.dk">bop@gmb.dk</a>&gt;&gt; wrote:<br=
>&gt;&gt;&gt;<br>&gt;&gt;&gt; =C2=A0 =C2=A0I&#39;m saying that the compiler=
 cannot read something that doesn&#39;t<br>&gt;&gt;&gt; =C2=A0 =C2=A0exist =
in the character set.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; =C2=A0 =C2=A0How woul=
d you represent the dot product when there is no dot?<br>&gt;&gt;<br>&gt;&g=
t; As \u00B7, I would imagine.<br>&gt;<br>&gt; Yes, but that is for Unicode=
, which we cannot expect. In EBCDIC hex B7 would be &#39;=C2=BC&#39;.<br><b=
r>I believe Richard means literally &quot;\u00B7&quot;, not &quot;=C2=B7&qu=
ot;.<br>The C++ Standard already requires that compilers support input such=
 as \u00B7 in string literals and identifiers and such. (Even \u00B7 itself=
 can appear in an identifier, which is shocking to me.)<br><br>The Standard=
 limply pretends to be Unicode-agnostic by using the term &quot;universal-c=
haracter-name&quot; instead of &quot;Unicode codepoint&quot;; but it&#39;s =
extremely obvious (from sections like 2.10) that these &quot;universal char=
acter names&quot; are just Unicode by another name.<br><br>The meaning of &=
quot;universal-character-name&quot; is defined in 2.3.<br>See 2.10 for the =
list of which Unicode characters can appear in identifiers.<br>=C2=A0 =C2=
=A0<br>Fatally to the OP&#39;s original proposal, since \u00B7 is currently=
 an identifier character, Clang already accepts<br><br>=C2=A0 =C2=A0 conste=
xpr int a\u00B7b =3D 42;<br>=C2=A0 =C2=A0 int func(int a, int b) { return a=
=C2=B7b; }<br><br>as equivalent to<br><br>=C2=A0 =C2=A0 int func(int a, int=
 b) { return 42; }<br><br>I bet GCC also accepts it in some mode that&#39;s=
 not the default on Linux.<br>See it in action here: <a href=3D"http://melp=
on.org/wandbox/permlink/XYAv6rbbxEgtHBYa">http://melpon.org/wandbox/permlin=
k/XYAv6rbbxEgtHBYa</a><div><br></div><div>HTH,<br>=E2=80=93Arthur</div></di=
v>

<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/CADvuK0%2BCjrdr5hYKT1Yu7GiGBk02d9C1MJ=
5XX%3DPJrnWhyj1%3D_Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2BC=
jrdr5hYKT1Yu7GiGBk02d9C1MJ5XX%3DPJrnWhyj1%3D_Q%40mail.gmail.com</a>.<br />

--f403045f20cac0addd054937fa73--

.

------=_Part_1097_1510634022.1487891764632
Content-Type: multipart/alternative;
 boundary="----=_Part_1098_741372657.1487891764632"

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

On Thursday, February 23, 2017 at 10:18:04 AM UTC-5, god...@gmail.com wrote=
:
>
> To summarize:
> - the "a cross b" syntax is a bit pointless since we can do "a *cross* b"=
=20
> already, which not so bad already, just a bit of boilerplate to define th=
e=20
> operator, and the operator itself is a bit long.
> - the "a=C3=97b" syntax would be troublesome to users who can't type the =
symbol=20
> easily, and it might not be supported by some compilers easily if they ha=
ve=20
> trouble with encoding.
>  =20
> In my opinion, for the minority users who would use these operators, IBM=
=20
> compiler probably doesn't matter (it doesn't support c++14 anyway accordi=
ng=20
> to this http://en.cppreference.com/w/cpp/compiler_support), and the=20
> syntax is much easier to read.
>

It's easy to say "let's cut compatibility with stuff I don't personally=20
use". It's a lot harder to tell people that they can't have new features=20
because some subset of programmers wanted dot products as operators.

Typing is actually quicker with a compose key than writing something like=
=20
> "a *cross* b" or "a.cross(b)", and an IDE could help for users without=20
> means to type non standard characters (for example: alt+. alt+x).
>

I don't even know what a "compose key" is, let alone have any idea how to=
=20
use one. So for me, the versions that use the basic character set will be=
=20
much faster to type.

The real question might be: is it easy to implement for the 3 major=20
> compilers (gcc clang, msvc) ? That I don't know...
>

> About more specific remarks :
>
> > Most C++ users don't go around doing dot products, cross products, and=
=20
> the like.
> What about those who do ?
>

.... What about them?

The fact of the matter is, the benefits of this feature are *trivial*. They=
=20
represent nothing more than convenient notation more.

How can you justify your convenience over the ability of other people to=20
have a C++ compiler? How can you justify your comfort over the ability of=
=20
some users to even use C++ at all.

Language features should do the least harm. That's why we try to make them=
=20
backwards compatible. If we're going to make a breaking change,=20
particularly one of this magnitude, it had *better* be for a feature that's=
=20
worth the cost.

And the convenience of a subset of C++ programmers is *not good enough*.
=20

> > Not only that, creating more operators means giving more people the=20
> chance to overload them for less regular uses. And quite frankly, we get=
=20
> enough of that as is.
> The fact that a tool can be misused does not make the tool bad.
>

Sure, but that doesn't make it *good* either. We shouldn't encourage misuse=
=20
of the language, and adding dozens of operators that have no built-in=20
function encourages misuse of the language. Especially without any=20
standard-defined meaning given to them.

Also, you have to deal with Unicode issues. Like decomposition. Consider Un=
icode=20
codepoint U+00B7, MIDDLE DOT=20
<http://www.fileformat.info/info/unicode/char/00B7/index.htm>. Now, what=20
should happen if you use Unicode codepoint U+0387: GREEK ANO TELLA=20
<http://www.fileformat.info/info/unicode/char/0387/index.htm>. This is the=
=20
difference between "=C2=B7" and "=CE=87". Did your font render them differe=
ntly? It=20
certainly didn't have to.

Even if your font does render them differently, if you convert the file to=
=20
NFC, the latter becomes the former. What was once just a random character=
=20
suddenly became a C++ operator.

That's not good.

Moreover, some unforeseen uses of a feature can be very good uses 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/362d4f94-0f0f-441c-a70b-395ab384d7b7%40isocpp.or=
g.

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

<div dir=3D"ltr">On Thursday, February 23, 2017 at 10:18:04 AM UTC-5, god..=
..@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">To summarize:<br>- the &quot;a cross b&quot; syntax is a bit pointless=
 since we can do &quot;a *cross* b&quot; already, which not so bad already,=
 just a bit of boilerplate to define the operator, and the operator itself =
is a bit long.<br>-  the &quot;a=C3=97b&quot; syntax would be troublesome t=
o users who can&#39;t type the symbol easily, and it might not be supported=
 by some compilers easily if they have trouble with encoding.<br>=C2=A0 <br=
>In my opinion, for the minority users who would use these operators, IBM c=
ompiler probably doesn&#39;t matter (it doesn&#39;t support c++14 anyway ac=
cording to this <a href=3D"http://en.cppreference.com/w/cpp/compiler_suppor=
t" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http:=
//www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fcomp=
iler_support\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHxj7_1kfe-Y2P-40WmnW1Z=
Ubz3Aw&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com=
/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fcompiler_support\x26=
sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHxj7_1kfe-Y2P-40WmnW1ZUbz3Aw&#39;;retu=
rn true;">http://en.cppreference.com/w/<wbr>cpp/compiler_support</a>), and =
the syntax is much easier to read.</div></blockquote><div><br>It&#39;s easy=
 to say &quot;let&#39;s cut=20
compatibility with stuff I don&#39;t personally use&quot;. It&#39;s a lot h=
arder to=20
tell people that they can&#39;t have new features because some subset of=20
programmers wanted dot products as operators.<br><br></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">Typing is actually quicker wi=
th a compose key than writing something like &quot;a *cross* b&quot; or &qu=
ot;a.cross(b)&quot;, and an IDE could help for users without means to type =
non standard characters (for example: alt+. alt+x).<br></div></blockquote><=
div><br>I don&#39;t even know what a &quot;compose key&quot; is, let alone =
have any idea how to use one. So for me, the versions that use the basic ch=
aracter set will be much faster to type.<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">The real question might be: is it =
easy to implement for the 3 major compilers (gcc clang, msvc) ? That I don&=
#39;t know...<br></div></blockquote><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>About more specific remarks :<br><br>&gt; Most C=
++ users don&#39;t go around doing dot products, cross products, and the li=
ke.<br>What about those who do ?<br></div></blockquote><div><br>... What ab=
out them?<br><br>The fact of the matter is, the benefits of this feature ar=
e <i>trivial</i>. They represent nothing more than convenient notation more=
..<br><br>How can you justify your convenience over the ability of other peo=
ple to have a C++ compiler? How can you justify your comfort over the abili=
ty of some users to even use C++ at all.<br><br>Language features should do=
 the least harm. That&#39;s why we try to make them backwards compatible. I=
f we&#39;re going to make a breaking change, particularly one of this magni=
tude, it had <i>better</i> be for a feature that&#39;s worth the cost.<br><=
br>And the convenience of a subset of C++ programmers is <i>not good enough=
</i>.<br>=C2=A0</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"ltr">&gt; Not only that, creating more operators means giving more peop=
le the=20
chance to overload them for less regular uses. And quite frankly, we get
 enough of that as is.<br>The fact that a tool can be misused does not make=
 the tool bad.</div></blockquote><div><br>Sure, but that doesn&#39;t make i=
t <i>good</i> either. We shouldn&#39;t encourage misuse of the language, an=
d adding dozens of operators that have no built-in function encourages misu=
se of the language. Especially without any standard-defined meaning given t=
o them.<br><br>Also, you have to deal with Unicode issues. Like decompositi=
on. Consider <a href=3D"http://www.fileformat.info/info/unicode/char/00B7/i=
ndex.htm">Unicode codepoint U+00B7, MIDDLE DOT</a>. Now, what should happen=
 if you use <a href=3D"http://www.fileformat.info/info/unicode/char/0387/in=
dex.htm">Unicode codepoint U+0387: GREEK ANO TELLA</a>. This is the differe=
nce between &quot;=C2=B7&quot; and &quot;=CE=87&quot;. Did your font render=
 them differently? It certainly didn&#39;t have to.<br><br>Even if your fon=
t does render them differently, if you convert the file to NFC, the latter =
becomes the former. What was once just a random character suddenly became a=
 C++ operator.<br><br>That&#39;s not good.<br><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>Moreover, some unforeseen uses of a featur=
e can be very good uses too. <br></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/362d4f94-0f0f-441c-a70b-395ab384d7b7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/362d4f94-0f0f-441c-a70b-395ab384d7b7=
%40isocpp.org</a>.<br />

------=_Part_1098_741372657.1487891764632--

------=_Part_1097_1510634022.1487891764632--

.

------=_Part_2479_1724676872.1487892055965
Content-Type: multipart/alternative;
 boundary="----=_Part_2480_56619330.1487892055965"

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


>
> You need to convince people of that first. You need a three-phased=20
> approach:=20
>
> 1) extend the basic character set (you may need a digraphs)=20
> 2) creating new operators in C++ (without saying which ones)=20
> 3) that some of those new operators should be =C2=B7, =E2=88=A7 and =C3=
=97=20
>
> You can do #1 and #2 in parallel.=20
>
> I expect you'll find heavy resistance in #1 and #2.=20
>

This is sensible to me.=20
In order to convince people that #1 and #2 are useful, I thought it would=
=20
be nice to provide a real example where #1 and #2 are useful.
It seems that the single use case that I have exposed (math operators) does=
=20
not weigh enough to convince people (maybe because they don't do math ?).

I take that I would rather collect a bunch of use cases for #1 and #2=20
separately, and then #3 should come easily.

--=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/3742c9d7-d299-42a9-923c-bb937f4cd745%40isocpp.or=
g.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">You need to c=
onvince people of that first. You need a three-phased approach:
<br>
<br>1) extend the basic character set (you may need a digraphs)
<br>2) creating new operators in C++ (without saying which ones)
<br>3) that some of those new operators should be =C2=B7, =E2=88=A7 and =C3=
=97
<br>
<br>You can do #1 and #2 in parallel.
<br>
<br>I expect you&#39;ll find heavy resistance in #1 and #2.
<br></blockquote><div><br>This is sensible to me. <br>In order to convince =
people that #1 and #2 are useful, I thought it would be nice to provide a r=
eal example where #1 and #2 are useful.<br>It seems that the single use cas=
e that I have exposed (math operators) does not weigh enough to convince pe=
ople (maybe because they don&#39;t do math ?).<br><br>I take that I would r=
ather collect a bunch of use cases for #1 and #2 separately, and then #3 sh=
ould come easily.<br></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/3742c9d7-d299-42a9-923c-bb937f4cd745%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3742c9d7-d299-42a9-923c-bb937f4cd745=
%40isocpp.org</a>.<br />

------=_Part_2480_56619330.1487892055965--

------=_Part_2479_1724676872.1487892055965--

.

------=_Part_742_812977056.1487892814437
Content-Type: multipart/alternative;
 boundary="----=_Part_743_1725608605.1487892814437"

------=_Part_743_1725608605.1487892814437
Content-Type: text/plain; charset=UTF-8

On Thursday, February 23, 2017 at 12:59:19 PM UTC-5, Thiago Macieira wrote:
>
> On quinta-feira, 23 de fevereiro de 2017 07:18:04 PST god...@gmail.com
> <javascript:> wrote:
> > The real question might be: is it easy to implement for the 3 major
> > compilers (gcc clang, msvc) ? That I don't know...
>
> Unless you want this to be an extension supported by those compilers --
> and I
> assume you don't want to, since we're on the standard proposals mailing
> list
> -- you're really looking at extending the C++ basic character set.
>
> You need to convince people of that first.


I don't agree with this.

Declaring that you want to extend the basic character set without
explaining why you need to is like going to a bank and asking if you can
borrow $5 million dollars without asking what you intend to do with it or
when you intend to pay it back.

Odds are good, things won't go well.

Any extension of the basic character set needs to involve a cost/benefit
analysis: what are the costs of the extension vs. the benefits of the *use*
of that extension. Without explaining how that extension gets used, it's
all cost with no benefit.

--
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/a9bcacd5-74fd-4222-880e-bb9a449944bf%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, February 23, 2017 at 12:59:19 PM UTC-5, Thiag=
o Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On quinta-fei=
ra, 23 de fevereiro de 2017 07:18:04 PST <a href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"4GECKALGAQAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">god...@gmail.com</a> wrote:
<br>&gt; The real question might be: is it easy to implement for the 3 majo=
r
<br>&gt; compilers (gcc clang, msvc) ? That I don&#39;t know...
<br>
<br>Unless you want this to be an extension supported by those compilers --=
 and I=20
<br>assume you don&#39;t want to, since we&#39;re on the standard proposals=
 mailing list=20
<br>-- you&#39;re really looking at extending the C++ basic character set.
<br>
<br>You need to convince people of that first.</blockquote><div><br>I don&#=
39;t agree with this.<br><br>Declaring that you want to extend the basic ch=
aracter set without explaining why you need to is like going to a bank and =
asking if you can borrow $5 million dollars without asking what you intend =
to do with it or when you intend to pay it back.<br><br>Odds are good, thin=
gs won&#39;t go well.<br><br>Any extension of the basic character set needs=
 to involve a cost/benefit analysis: what are the costs of the extension vs=
.. the benefits of the <i>use</i> of that extension. Without explaining how =
that extension gets used, it&#39;s all cost with no benefit.</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/a9bcacd5-74fd-4222-880e-bb9a449944bf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a9bcacd5-74fd-4222-880e-bb9a449944bf=
%40isocpp.org</a>.<br />

------=_Part_743_1725608605.1487892814437--

------=_Part_742_812977056.1487892814437--

.

------=_Part_2301_564105970.1487893650774
Content-Type: multipart/alternative;
 boundary="----=_Part_2302_950861762.1487893650774"

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

Le vendredi 24 f=C3=A9vrier 2017 00:16:04 UTC+1, Nicol Bolas a =C3=A9crit :
>
> On Thursday, February 23, 2017 at 10:18:04 AM UTC-5, god...@gmail.com=20
> wrote:
>>
>> To summarize:
>> - the "a cross b" syntax is a bit pointless since we can do "a *cross* b=
"=20
>> already, which not so bad already, just a bit of boilerplate to define t=
he=20
>> operator, and the operator itself is a bit long.
>> - the "a=C3=97b" syntax would be troublesome to users who can't type the=
=20
>> symbol easily, and it might not be supported by some compilers easily if=
=20
>> they have trouble with encoding.
>>  =20
>> In my opinion, for the minority users who would use these operators, IBM=
=20
>> compiler probably doesn't matter (it doesn't support c++14 anyway accord=
ing=20
>> to this http://en.cppreference.com/w/cpp/compiler_support), and the=20
>> syntax is much easier to read.
>>
>
> It's easy to say "let's cut compatibility with stuff I don't personally=
=20
> use". It's a lot harder to tell people that they can't have new features=
=20
> because some subset of programmers wanted dot products as operators.
>

> Typing is actually quicker with a compose key than writing something like=
=20
>> "a *cross* b" or "a.cross(b)", and an IDE could help for users without=
=20
>> means to type non standard characters (for example: alt+. alt+x).
>>
>
> I don't even know what a "compose key" is, let alone have any idea how to=
=20
> use one. So for me, the versions that use the basic character set will be=
=20
> much faster to type.
>
> The real question might be: is it easy to implement for the 3 major=20
>> compilers (gcc clang, msvc) ? That I don't know...
>>
>
>> About more specific remarks :
>>
>> > Most C++ users don't go around doing dot products, cross products, and=
=20
>> the like.
>> What about those who do ?
>>
>
> ... What about them?
>
> The fact of the matter is, the benefits of this feature are *trivial*.=20
> They represent nothing more than convenient notation more.
>
> How can you justify your convenience over the ability of other people to=
=20
> have a C++ compiler? How can you justify your comfort over the ability of=
=20
> some users to even use C++ at all.
>
> Language features should do the least harm. That's why we try to make the=
m=20
> backwards compatible. If we're going to make a breaking change,=20
> particularly one of this magnitude, it had *better* be for a feature=20
> that's worth the cost.
>
> And the convenience of a subset of C++ programmers is *not good enough*.
>

I have no clue what you are talking about... This is fully backward=20
compatible except if someone is using middle dots in its code now, which I=
=20
doubt. This changes nothing to people who don't use the new operators,=20
whether their compiler implement it or not.

For the end user, convenience for free is better than nothing.
And readability is a bit more than convenience.
=20

> =20
>
>> > Not only that, creating more operators means giving more people the=20
>> chance to overload them for less regular uses. And quite frankly, we get=
=20
>> enough of that as is.
>> The fact that a tool can be misused does not make the tool bad.
>>
>
> Sure, but that doesn't make it *good* either. We shouldn't encourage=20
> misuse of the language, and adding dozens of operators that have no=20
> built-in function encourages misuse of the language. Especially without a=
ny=20
> standard-defined meaning given to them.
>

What encourages misuse of the language is not having enough operators,=20
where you end up hacking those you have in place of using those you don't.=
=20
Standard defined meaning may not be a good thing. Example of meaningful=20
usage is good, but some unknown folks may come up with their own=20
interpretation of symbols which is widespread in their community, and that=
=20
would be perfectly good to me even if this is not defined in the standard.=
=20
For instance, operator/ is now used in std::filesystem, operator<< is used=
=20
in iostream, soon we will have operator| for ranges as in bash pipes. If=20
the symbol is the good one for some usage, it is good to use it, and so it=
=20
is good to have it available as an operator.
=20

>
> Also, you have to deal with Unicode issues. Like decomposition. Consider =
Unicode=20
> codepoint U+00B7, MIDDLE DOT=20
> <http://www.fileformat.info/info/unicode/char/00B7/index.htm>. Now, what=
=20
> should happen if you use Unicode codepoint U+0387: GREEK ANO TELLA=20
> <http://www.fileformat.info/info/unicode/char/0387/index.htm>. This is=20
> the difference between "=C2=B7" and "=CE=87". Did your font render them d=
ifferently?=20
> It certainly didn't have to.
>
> Even if your font does render them differently, if you convert the file t=
o=20
> NFC, the latter becomes the former. What was once just a random character=
=20
> suddenly became a C++ operator.
>
> That's not good.
>

Yeah, we have to be careful with encoding as always, but you can simply=20
tell your compiler what encoding you use, or maybe enforce utf8, or=20
whatever is deemed proper.
=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/a692f9e3-3209-402e-94d8-998bc1a1ebe7%40isocpp.or=
g.

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

<div dir=3D"ltr">Le vendredi 24 f=C3=A9vrier 2017 00:16:04 UTC+1, Nicol Bol=
as a =C3=A9crit=C2=A0:<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">On Thursday, February 23, 2017 at 10:18:04 AM UTC-5, <a>god...@gma=
il.com</a> 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">T=
o summarize:<br>- the &quot;a cross b&quot; syntax is a bit pointless since=
 we can do &quot;a *cross* b&quot; already, which not so bad already, just =
a bit of boilerplate to define the operator, and the operator itself is a b=
it long.<br>-  the &quot;a=C3=97b&quot; syntax would be troublesome to user=
s who can&#39;t type the symbol easily, and it might not be supported by so=
me compilers easily if they have trouble with encoding.<br>=C2=A0 <br>In my=
 opinion, for the minority users who would use these operators, IBM compile=
r probably doesn&#39;t matter (it doesn&#39;t support c++14 anyway accordin=
g to this <a href=3D"http://en.cppreference.com/w/cpp/compiler_support" rel=
=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.=
google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fcompiler_s=
upport\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHxj7_1kfe-Y2P-40WmnW1ZUbz3Aw=
&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q=
\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fcompiler_support\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNHxj7_1kfe-Y2P-40WmnW1ZUbz3Aw&#39;;return tru=
e;">http://en.cppreference.com/w/<wbr>cpp/compiler_support</a>), and the sy=
ntax is much easier to read.</div></blockquote><div><br>It&#39;s easy to sa=
y &quot;let&#39;s cut=20
compatibility with stuff I don&#39;t personally use&quot;. It&#39;s a lot h=
arder to=20
tell people that they can&#39;t have new features because some subset of=20
programmers wanted dot products as operators.<br></div></div></blockquote><=
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><br></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">Typing is actuall=
y quicker with a compose key than writing something like &quot;a *cross* b&=
quot; or &quot;a.cross(b)&quot;, and an IDE could help for users without me=
ans to type non standard characters (for example: alt+. alt+x).<br></div></=
blockquote><div><br>I don&#39;t even know what a &quot;compose key&quot; is=
, let alone have any idea how to use one. So for me, the versions that use =
the basic character set will be much faster to type.<br><br></div><blockquo=
te 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">The real question might be:=
 is it easy to implement for the 3 major compilers (gcc clang, msvc) ? That=
 I don&#39;t know...<br></div></blockquote><blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><br>About more specific remarks :<br><br>&gt; Most=
 C++ users don&#39;t go around doing dot products, cross products, and the =
like.<br>What about those who do ?<br></div></blockquote><div><br>... What =
about them?<br><br>The fact of the matter is, the benefits of this feature =
are <i>trivial</i>. They represent nothing more than convenient notation mo=
re.<br><br>How can you justify your convenience over the ability of other p=
eople to have a C++ compiler? How can you justify your comfort over the abi=
lity of some users to even use C++ at all.<br><br>Language features should =
do the least harm. That&#39;s why we try to make them backwards compatible.=
 If we&#39;re going to make a breaking change, particularly one of this mag=
nitude, it had <i>better</i> be for a feature that&#39;s worth the cost.<br=
><br>And the convenience of a subset of C++ programmers is <i>not good enou=
gh</i>.<br></div></div></blockquote><div><br>I have no clue what you are ta=
lking about... This is fully backward compatible except if someone is using=
 middle dots in its code now, which I doubt. This changes nothing to people=
 who don&#39;t use the new operators, whether their compiler implement it o=
r not.<br><br>For the end user, convenience for free is better than nothing=
..<br>And readability is a bit more than convenience.<br>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">&gt; Not only that, c=
reating more operators means giving more people the=20
chance to overload them for less regular uses. And quite frankly, we get
 enough of that as is.<br>The fact that a tool can be misused does not make=
 the tool bad.</div></blockquote><div><br>Sure, but that doesn&#39;t make i=
t <i>good</i> either. We shouldn&#39;t encourage misuse of the language, an=
d adding dozens of operators that have no built-in function encourages misu=
se of the language. Especially without any standard-defined meaning given t=
o them.<br></div></div></blockquote><div><br>What encourages misuse of the =
language is not having enough operators, where you end up hacking those you=
 have in place of using those you don&#39;t. <br>Standard defined meaning m=
ay not be a good thing. Example of meaningful usage is good, but some unkno=
wn folks may come up with their own interpretation of symbols which is wide=
spread in their community, and that would be perfectly good to me even if t=
his is not defined in the standard. For instance, operator/ is now used in =
std::filesystem, operator&lt;&lt; is used in iostream, soon we will have op=
erator| for ranges as in bash pipes. If the symbol is the good one for some=
 usage, it is good to use it, and so it is good to have it available as an =
operator.<br>=C2=A0</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><br>Also, you have to deal with Unicode issues. Like decom=
position. Consider <a href=3D"http://www.fileformat.info/info/unicode/char/=
00B7/index.htm" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.fileformat.info%2Fi=
nfo%2Funicode%2Fchar%2F00B7%2Findex.htm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dA=
FQjCNESTmv0n3sB_JN4DbAsC0hx-2fVIw&#39;;return true;" onclick=3D"this.href=
=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.fileformat.info%2Fi=
nfo%2Funicode%2Fchar%2F00B7%2Findex.htm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dA=
FQjCNESTmv0n3sB_JN4DbAsC0hx-2fVIw&#39;;return true;">Unicode codepoint U+00=
B7, MIDDLE DOT</a>. Now, what should happen if you use <a href=3D"http://ww=
w.fileformat.info/info/unicode/char/0387/index.htm" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x=
3dhttp%3A%2F%2Fwww.fileformat.info%2Finfo%2Funicode%2Fchar%2F0387%2Findex.h=
tm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEGQcQ-CiM9pqtHJK9a3Vw3XJ5wQA&#39=
;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3d=
http%3A%2F%2Fwww.fileformat.info%2Finfo%2Funicode%2Fchar%2F0387%2Findex.htm=
\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEGQcQ-CiM9pqtHJK9a3Vw3XJ5wQA&#39;;=
return true;">Unicode codepoint U+0387: GREEK ANO TELLA</a>. This is the di=
fference between &quot;=C2=B7&quot; and &quot;=CE=87&quot;. Did your font r=
ender them differently? It certainly didn&#39;t have to.<br><br>Even if you=
r font does render them differently, if you convert the file to NFC, the la=
tter becomes the former. What was once just a random character suddenly bec=
ame a C++ operator.<br><br>That&#39;s not good.</div></div></blockquote><di=
v><br>Yeah, we have to be careful with encoding as always, but you can simp=
ly tell your compiler what encoding you use, or maybe enforce utf8, or what=
ever is deemed proper.<br>=C2=A0</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/a692f9e3-3209-402e-94d8-998bc1a1ebe7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a692f9e3-3209-402e-94d8-998bc1a1ebe7=
%40isocpp.org</a>.<br />

------=_Part_2302_950861762.1487893650774--

------=_Part_2301_564105970.1487893650774--

.

------=_Part_11933_986553164.1487898424234
Content-Type: multipart/alternative;
 boundary="----=_Part_11934_1665043165.1487898424234"

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

On Thursday, February 23, 2017 at 6:47:30 PM UTC-5, god...@gmail.com wrote:
>
> Le vendredi 24 f=C3=A9vrier 2017 00:16:04 UTC+1, Nicol Bolas a =C3=A9crit=
 :
>>
>> On Thursday, February 23, 2017 at 10:18:04 AM UTC-5, god...@gmail.com=20
>> wrote:
>>>
>>> To summarize:
>>> - the "a cross b" syntax is a bit pointless since we can do "a *cross*=
=20
>>> b" already, which not so bad already, just a bit of boilerplate to defi=
ne=20
>>> the operator, and the operator itself is a bit long.
>>> - the "a=C3=97b" syntax would be troublesome to users who can't type th=
e=20
>>> symbol easily, and it might not be supported by some compilers easily i=
f=20
>>> they have trouble with encoding.
>>>  =20
>>> In my opinion, for the minority users who would use these operators, IB=
M=20
>>> compiler probably doesn't matter (it doesn't support c++14 anyway accor=
ding=20
>>> to this http://en.cppreference.com/w/cpp/compiler_support), and the=20
>>> syntax is much easier to read.
>>>
>>
>> It's easy to say "let's cut compatibility with stuff I don't personally=
=20
>> use". It's a lot harder to tell people that they can't have new features=
=20
>> because some subset of programmers wanted dot products as operators.
>>
>
>> Typing is actually quicker with a compose key than writing something lik=
e=20
>>> "a *cross* b" or "a.cross(b)", and an IDE could help for users without=
=20
>>> means to type non standard characters (for example: alt+. alt+x).
>>>
>>
>> I don't even know what a "compose key" is, let alone have any idea how t=
o=20
>> use one. So for me, the versions that use the basic character set will b=
e=20
>> much faster to type.
>>
>> The real question might be: is it easy to implement for the 3 major=20
>>> compilers (gcc clang, msvc) ? That I don't know...
>>>
>>
>>> About more specific remarks :
>>>
>>> > Most C++ users don't go around doing dot products, cross products, an=
d=20
>>> the like.
>>> What about those who do ?
>>>
>>
>> ... What about them?
>>
>> The fact of the matter is, the benefits of this feature are *trivial*.=
=20
>> They represent nothing more than convenient notation more.
>>
>> How can you justify your convenience over the ability of other people to=
=20
>> have a C++ compiler? How can you justify your comfort over the ability o=
f=20
>> some users to even use C++ at all.
>>
>> Language features should do the least harm. That's why we try to make=20
>> them backwards compatible. If we're going to make a breaking change,=20
>> particularly one of this magnitude, it had *better* be for a feature=20
>> that's worth the cost.
>>
>> And the convenience of a subset of C++ programmers is *not good enough*.
>>
>
> I have no clue what you are talking about... This is fully backward=20
> compatible except if someone is using middle dots in its code now, which =
I=20
> doubt. This changes nothing to people who don't use the new operators,=20
> whether their compiler implement it or not.
>

It requires that an implementation use a character set that can encode all=
=20
of the characters from the basic character set. By expanding the basic=20
character set, you require implementations to potentially change the=20
character sets they can take. Or more specifically, to stop supporting=20
character sets that cannot encode all of the characters from the expanded=
=20
basic character set.

Hence not being backwards compatible with files in the previously-supported=
=20
character set.
=20

> For the end user, convenience for free is better than nothing.
>

Can you provide an explanation for how ditching EBCDIC and thus breaking=20
compatibility with those files is "free"?

And readability is a bit more than convenience.
> =20
>
>> =20
>>
>>> > Not only that, creating more operators means giving more people the=
=20
>>> chance to overload them for less regular uses. And quite frankly, we ge=
t=20
>>> enough of that as is.
>>> The fact that a tool can be misused does not make the tool bad.
>>>
>>
>> Sure, but that doesn't make it *good* either. We shouldn't encourage=20
>> misuse of the language, and adding dozens of operators that have no=20
>> built-in function encourages misuse of the language. Especially without =
any=20
>> standard-defined meaning given to them.
>>
>
> What encourages misuse of the language is not having enough operators,=20
> where you end up hacking those you have in place of using those you don't=
..
>

Or you can just do what normal people do and write `cross(a, b)`. That's=20
not a hack. And to be perfectly honest, I'd much rather we (as someone=20
earlier suggested) permit in-fix calling notation for regular functions. Or=
=20
at least, provide a way to declare an "operator Funcname", such that=20
`Funcname` can thereafter be used as an operator.

It'd be a lot easier to type `a cross b` for people who don't use Unicode=
=20
frequently. It also wouldn't break support for non-Unicode-able character=
=20
sets.

Also, is there any prior art for this feature? For example, do other=20
languages support a wide variety of Unicode operators? More recent=20
languages, like Swift and Go, do not support such features.

Standard defined meaning may not be a good thing. Example of meaningful=20
> usage is good, but some unknown folks may come up with their own=20
> interpretation of symbols which is widespread in their community, and tha=
t=20
> would be perfectly good to me even if this is not defined in the standard=
..=20
> For instance, operator/ is now used in std::filesystem, operator<< is use=
d=20
> in iostream, soon we will have operator| for ranges as in bash pipes. If=
=20
> the symbol is the good one for some usage, it is good to use it, and so i=
t=20
> is good to have it available as an operator.
>

It should be noted that a number of C++ programmers lament the use of `<<`=
=20
and `>>` for streams. Indeed, the use of `<<` for insertion into streams=20
makes it exceedingly difficult to implement certain formatting tasks. It=20
leads to horrors like `std::cout << std::fixed << std::setprecision(3) <<=
=20
12.5f;`. Why? Because we cannot provide additional parameters to the call=
=20
to `operator<<`, and that operator call is what does the formatting. It=20
requires the stream to store these formatting parameters, all so that the=
=20
`operator<<` overload can read them and respond to them.

Consider the functional equivalent: `insert(cout, 12.5f, std::fixed,=20
std::setprecision(3));`, and the overload for `float` could easily extract=
=20
the appropriate parameters (via a variadic template) and do the right=20
thing. This is also more flexible, as arbitrary user-defined types can have=
=20
their *own* formatting parameters. By contrast, streams define a specific=
=20
set of formatting parameters, and anything else has to be done a different=
=20
way.

So whether this is good or not is, ultimately, in the eye of the beholder.

Also, you have to deal with Unicode issues. Like decomposition. Consider Un=
icode=20
>> codepoint U+00B7, MIDDLE DOT=20
>> <http://www.fileformat.info/info/unicode/char/00B7/index.htm>. Now, what=
=20
>> should happen if you use Unicode codepoint U+0387: GREEK ANO TELLA=20
>> <http://www.fileformat.info/info/unicode/char/0387/index.htm>. This is=
=20
>> the difference between "=C2=B7" and "=CE=87". Did your font render them =
differently?=20
>> It certainly didn't have to.
>>
>> Even if your font does render them differently, if you convert the file=
=20
>> to NFC, the latter becomes the former. What was once just a random=20
>> character suddenly became a C++ operator.
>>
>> That's not good.
>>
>
> Yeah, we have to be careful with encoding as always, but you can simply=
=20
> tell your compiler what encoding you use, or maybe enforce utf8, or=20
> whatever is deemed proper.
>

--=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/cf875100-93f0-45ec-9a46-205e0af7a8fe%40isocpp.or=
g.

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

<div dir=3D"ltr">On Thursday, February 23, 2017 at 6:47:30 PM UTC-5, god...=
@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">Le vendredi 24 f=C3=A9vrier 2017 00:16:04 UTC+1, Nicol Bolas a =C3=A9cr=
it=C2=A0:<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">On Thursd=
ay, February 23, 2017 at 10:18:04 AM UTC-5, <a>god...@gmail.com</a> 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">To summarize:<br>- =
the &quot;a cross b&quot; syntax is a bit pointless since we can do &quot;a=
 *cross* b&quot; already, which not so bad already, just a bit of boilerpla=
te to define the operator, and the operator itself is a bit long.<br>-  the=
 &quot;a=C3=97b&quot; syntax would be troublesome to users who can&#39;t ty=
pe the symbol easily, and it might not be supported by some compilers easil=
y if they have trouble with encoding.<br>=C2=A0 <br>In my opinion, for the =
minority users who would use these operators, IBM compiler probably doesn&#=
39;t matter (it doesn&#39;t support c++14 anyway according to this <a href=
=3D"http://en.cppreference.com/w/cpp/compiler_support" rel=3D"nofollow" tar=
get=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\=
x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fcompiler_support\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNHxj7_1kfe-Y2P-40WmnW1ZUbz3Aw&#39;;return true=
;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2F=
en.cppreference.com%2Fw%2Fcpp%2Fcompiler_support\x26sa\x3dD\x26sntz\x3d1\x2=
6usg\x3dAFQjCNHxj7_1kfe-Y2P-40WmnW1ZUbz3Aw&#39;;return true;">http://en.cpp=
reference.com/w/<wbr>cpp/compiler_support</a>), and the syntax is much easi=
er to read.</div></blockquote><div><br>It&#39;s easy to say &quot;let&#39;s=
 cut=20
compatibility with stuff I don&#39;t personally use&quot;. It&#39;s a lot h=
arder to=20
tell people that they can&#39;t have new features because some subset of=20
programmers wanted dot products as operators.<br></div></div></blockquote><=
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><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">Typing is actually qui=
cker with a compose key than writing something like &quot;a *cross* b&quot;=
 or &quot;a.cross(b)&quot;, and an IDE could help for users without means t=
o type non standard characters (for example: alt+. alt+x).<br></div></block=
quote><div><br>I don&#39;t even know what a &quot;compose key&quot; is, let=
 alone have any idea how to use one. So for me, the versions that use the b=
asic character set will be much faster to type.<br><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr">The real question might be: is i=
t easy to implement for the 3 major compilers (gcc clang, msvc) ? That I do=
n&#39;t know...<br></div></blockquote><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"><br>About more specific remarks :<br><br>&gt; Most C++ =
users don&#39;t go around doing dot products, cross products, and the like.=
<br>What about those who do ?<br></div></blockquote><div><br>... What about=
 them?<br><br>The fact of the matter is, the benefits of this feature are <=
i>trivial</i>. They represent nothing more than convenient notation more.<b=
r><br>How can you justify your convenience over the ability of other people=
 to have a C++ compiler? How can you justify your comfort over the ability =
of some users to even use C++ at all.<br><br>Language features should do th=
e least harm. That&#39;s why we try to make them backwards compatible. If w=
e&#39;re going to make a breaking change, particularly one of this magnitud=
e, it had <i>better</i> be for a feature that&#39;s worth the cost.<br><br>=
And the convenience of a subset of C++ programmers is <i>not good enough</i=
>.<br></div></div></blockquote><div><br>I have no clue what you are talking=
 about... This is fully backward compatible except if someone is using midd=
le dots in its code now, which I doubt. This changes nothing to people who =
don&#39;t use the new operators, whether their compiler implement it or not=
..<br></div></div></blockquote><div><br>It requires that an implementation u=
se a character set that can encode all of the characters from the basic cha=
racter set. By expanding the basic character set, you require implementatio=
ns to potentially change the character sets they can take. Or more specific=
ally, to stop supporting character sets that cannot encode all of the chara=
cters from the expanded basic character set.<br><br>Hence not being backwar=
ds compatible with files in the previously-supported character set.<br>=C2=
=A0</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=
>For the end user, convenience for free is better than nothing.<br></div></=
div></blockquote><div><br></div>Can you provide an explanation for how ditc=
hing EBCDIC and thus breaking compatibility with those files is &quot;free&=
quot;?<br><br><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"=
><div>And readability is a bit more than convenience.<br>=C2=A0</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"><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">&gt; Not only that, creat=
ing more operators means giving more people the=20
chance to overload them for less regular uses. And quite frankly, we get
 enough of that as is.<br>The fact that a tool can be misused does not make=
 the tool bad.</div></blockquote><div><br>Sure, but that doesn&#39;t make i=
t <i>good</i> either. We shouldn&#39;t encourage misuse of the language, an=
d adding dozens of operators that have no built-in function encourages misu=
se of the language. Especially without any standard-defined meaning given t=
o them.<br></div></div></blockquote><div><br>What encourages misuse of the =
language is not having enough operators, where you end up hacking those you=
 have in place of using those you don&#39;t.<br></div></div></blockquote><d=
iv><br>Or you can just do what normal people do and write `cross(a, b)`. Th=
at&#39;s not a hack. And to be perfectly honest, I&#39;d much rather we (as=
 someone earlier suggested) permit in-fix calling notation for regular func=
tions. Or at least, provide a way to declare an &quot;operator Funcname&quo=
t;, such that `Funcname` can thereafter be used as an operator.<br><br>It&#=
39;d be a lot easier to type `a cross b` for people who don&#39;t use Unico=
de frequently. It also wouldn&#39;t break support for non-Unicode-able char=
acter sets.<br><br>Also, is there any prior art for this feature? For examp=
le, do other languages support a wide variety of Unicode operators? More re=
cent languages, like Swift and Go, do not support such features.<br><br></d=
iv><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>Stand=
ard defined meaning may not be a good thing. Example of meaningful usage is=
 good, but some unknown folks may come up with their own interpretation of =
symbols which is widespread in their community, and that would be perfectly=
 good to me even if this is not defined in the standard. For instance, oper=
ator/ is now used in std::filesystem, operator&lt;&lt; is used in iostream,=
 soon we will have operator| for ranges as in bash pipes. If the symbol is =
the good one for some usage, it is good to use it, and so it is good to hav=
e it available as an operator.<br></div></div></blockquote><div><br>It shou=
ld be noted that a number of C++ programmers lament the use of `&lt;&lt;` a=
nd `&gt;&gt;` for streams. Indeed, the use of `&lt;&lt;` for insertion into=
 streams makes it exceedingly difficult to implement certain formatting tas=
ks. It leads to horrors like `std::cout &lt;&lt; std::fixed &lt;&lt; std::s=
etprecision(3) &lt;&lt; 12.5f;`. Why? Because we cannot provide additional =
parameters to the call to `operator&lt;&lt;`, and that operator call is wha=
t does the formatting. It requires the stream to store these formatting par=
ameters, all so that the `operator&lt;&lt;` overload can read them and resp=
ond to them.<br><br>Consider the functional equivalent: `insert(cout, 12.5f=
, std::fixed, std::setprecision(3));`, and the overload for `float` could e=
asily extract the appropriate parameters (via a variadic template) and do t=
he right thing. This is also more flexible, as arbitrary user-defined types=
 can have their <i>own</i> formatting parameters. By contrast, streams defi=
ne a specific set of formatting parameters, and anything else has to be don=
e a different way.<br><br>So whether this is good or not is, ultimately, in=
 the eye of the beholder.<br><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div></div><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"><div>Also, you have to deal with Unicode issues. Like de=
composition. Consider <a href=3D"http://www.fileformat.info/info/unicode/ch=
ar/00B7/index.htm" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.h=
ref=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.fileformat.info%=
2Finfo%2Funicode%2Fchar%2F00B7%2Findex.htm\x26sa\x3dD\x26sntz\x3d1\x26usg\x=
3dAFQjCNESTmv0n3sB_JN4DbAsC0hx-2fVIw&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.fileformat.info%2F=
info%2Funicode%2Fchar%2F00B7%2Findex.htm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNESTmv0n3sB_JN4DbAsC0hx-2fVIw&#39;;return true;">Unicode codepoint U+0=
0B7, MIDDLE DOT</a>. Now, what should happen if you use <a href=3D"http://w=
ww.fileformat.info/info/unicode/char/0387/index.htm" rel=3D"nofollow" targe=
t=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3=
dhttp%3A%2F%2Fwww.fileformat.info%2Finfo%2Funicode%2Fchar%2F0387%2Findex.ht=
m\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEGQcQ-CiM9pqtHJK9a3Vw3XJ5wQA&#39;=
;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dh=
ttp%3A%2F%2Fwww.fileformat.info%2Finfo%2Funicode%2Fchar%2F0387%2Findex.htm\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEGQcQ-CiM9pqtHJK9a3Vw3XJ5wQA&#39;;r=
eturn true;">Unicode codepoint U+0387: GREEK ANO TELLA</a>. This is the dif=
ference between &quot;=C2=B7&quot; and &quot;=CE=87&quot;. Did your font re=
nder them differently? It certainly didn&#39;t have to.<br><br>Even if your=
 font does render them differently, if you convert the file to NFC, the lat=
ter becomes the former. What was once just a random character suddenly beca=
me a C++ operator.<br><br>That&#39;s not good.</div></div></blockquote><div=
><br>Yeah, we have to be careful with encoding as always, but you can simpl=
y tell your compiler what encoding you use, or maybe enforce utf8, or whate=
ver is deemed proper.<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/cf875100-93f0-45ec-9a46-205e0af7a8fe%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cf875100-93f0-45ec-9a46-205e0af7a8fe=
%40isocpp.org</a>.<br />

------=_Part_11934_1665043165.1487898424234--

------=_Part_11933_986553164.1487898424234--

.

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

On 23 February 2017 at 17:07, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Thursday, February 23, 2017 at 6:47:30 PM UTC-5, god...@gmail.com
> wrote:
>>
>> Le vendredi 24 f=C3=A9vrier 2017 00:16:04 UTC+1, Nicol Bolas a =C3=A9cri=
t :
>>>
>>> On Thursday, February 23, 2017 at 10:18:04 AM UTC-5, god...@gmail.com
>>> wrote:
>>>>
>>>> To summarize:
>>>> - the "a cross b" syntax is a bit pointless since we can do "a *cross*
>>>> b" already, which not so bad already, just a bit of boilerplate to def=
ine
>>>> the operator, and the operator itself is a bit long.
>>>> - the "a=C3=97b" syntax would be troublesome to users who can't type t=
he
>>>> symbol easily, and it might not be supported by some compilers easily =
if
>>>> they have trouble with encoding.
>>>>
>>>> In my opinion, for the minority users who would use these operators,
>>>> IBM compiler probably doesn't matter (it doesn't support c++14 anyway
>>>> according to this http://en.cppreference.com/w/cpp/compiler_support),
>>>> and the syntax is much easier to read.
>>>>
>>>
>>> It's easy to say "let's cut compatibility with stuff I don't personally
>>> use". It's a lot harder to tell people that they can't have new feature=
s
>>> because some subset of programmers wanted dot products as operators.
>>>
>>
>>> Typing is actually quicker with a compose key than writing something
>>>> like "a *cross* b" or "a.cross(b)", and an IDE could help for users wi=
thout
>>>> means to type non standard characters (for example: alt+. alt+x).
>>>>
>>>
>>> I don't even know what a "compose key" is, let alone have any idea how
>>> to use one. So for me, the versions that use the basic character set wi=
ll
>>> be much faster to type.
>>>
>>> The real question might be: is it easy to implement for the 3 major
>>>> compilers (gcc clang, msvc) ? That I don't know...
>>>>
>>>
>>>> About more specific remarks :
>>>>
>>>> > Most C++ users don't go around doing dot products, cross products,
>>>> and the like.
>>>> What about those who do ?
>>>>
>>>
>>> ... What about them?
>>>
>>> The fact of the matter is, the benefits of this feature are *trivial*.
>>> They represent nothing more than convenient notation more.
>>>
>>> How can you justify your convenience over the ability of other people t=
o
>>> have a C++ compiler? How can you justify your comfort over the ability =
of
>>> some users to even use C++ at all.
>>>
>>> Language features should do the least harm. That's why we try to make
>>> them backwards compatible. If we're going to make a breaking change,
>>> particularly one of this magnitude, it had *better* be for a feature
>>> that's worth the cost.
>>>
>>> And the convenience of a subset of C++ programmers is *not good enough*=
..
>>>
>>
>> I have no clue what you are talking about... This is fully backward
>> compatible except if someone is using middle dots in its code now, which=
 I
>> doubt. This changes nothing to people who don't use the new operators,
>> whether their compiler implement it or not.
>>
>
> It requires that an implementation use a character set that can encode al=
l
> of the characters from the basic character set. By expanding the basic
> character set, you require implementations to potentially change the
> character sets they can take. Or more specifically, to stop supporting
> character sets that cannot encode all of the characters from the expanded
> basic character set.
>

I fail to see why this would require expanding the set of characters in the
basic source character set. As for not supporting character sets that
cannot represent all of unicode, that is not at all a novel requirement. A
conforming implementation is already required to support \uXXXX and
\U00XXXXXX escapes within identifiers, string literals, ...

There may be good arguments against this proposal, but this does not seem
to be one of them.


> Hence not being backwards compatible with files in the
> previously-supported character set.
>
>
>> For the end user, convenience for free is better than nothing.
>>
>
> Can you provide an explanation for how ditching EBCDIC and thus breaking
> compatibility with those files is "free"?
>
> And readability is a bit more than convenience.
>>
>>
>>>
>>>
>>>> > Not only that, creating more operators means giving more people the
>>>> chance to overload them for less regular uses. And quite frankly, we g=
et
>>>> enough of that as is.
>>>> The fact that a tool can be misused does not make the tool bad.
>>>>
>>>
>>> Sure, but that doesn't make it *good* either. We shouldn't encourage
>>> misuse of the language, and adding dozens of operators that have no
>>> built-in function encourages misuse of the language. Especially without=
 any
>>> standard-defined meaning given to them.
>>>
>>
>> What encourages misuse of the language is not having enough operators,
>> where you end up hacking those you have in place of using those you don'=
t.
>>
>
> Or you can just do what normal people do and write `cross(a, b)`. That's
> not a hack. And to be perfectly honest, I'd much rather we (as someone
> earlier suggested) permit in-fix calling notation for regular functions. =
Or
> at least, provide a way to declare an "operator Funcname", such that
> `Funcname` can thereafter be used as an operator.
>
> It'd be a lot easier to type `a cross b` for people who don't use Unicode
> frequently. It also wouldn't break support for non-Unicode-able character
> sets.
>
> Also, is there any prior art for this feature? For example, do other
> languages support a wide variety of Unicode operators? More recent
> languages, like Swift and Go, do not support such features.
>

You are mistaken about Swift. Swift and Haskell support arbitrary
user-defined custom operators, spelled with Unicode operator characters:
https://developer.apple.com/library/content/documentation/Swift/Conceptual/=
Swift_Programming_Language/AdvancedOperators.html#//apple_ref/doc/uid/TP400=
14097-CH27-ID46,
https://www.haskell.org/onlinereport/lexemes.html

However, Rust and Dart, like C++, support overloading only for a fixed
subset of builtin operators: https://doc.rust-lang.org/std/ops/,
https://www.dartlang.org/guides/language/language-tour#overridable-operator=
s

Standard defined meaning may not be a good thing. Example of meaningful
>> usage is good, but some unknown folks may come up with their own
>> interpretation of symbols which is widespread in their community, and th=
at
>> would be perfectly good to me even if this is not defined in the standar=
d.
>> For instance, operator/ is now used in std::filesystem, operator<< is us=
ed
>> in iostream, soon we will have operator| for ranges as in bash pipes. If
>> the symbol is the good one for some usage, it is good to use it, and so =
it
>> is good to have it available as an operator.
>>
>
> It should be noted that a number of C++ programmers lament the use of `<<=
`
> and `>>` for streams. Indeed, the use of `<<` for insertion into streams
> makes it exceedingly difficult to implement certain formatting tasks. It
> leads to horrors like `std::cout << std::fixed << std::setprecision(3) <<
> 12.5f;`. Why? Because we cannot provide additional parameters to the call
> to `operator<<`, and that operator call is what does the formatting. It
> requires the stream to store these formatting parameters, all so that the
> `operator<<` overload can read them and respond to them.
>
> Consider the functional equivalent: `insert(cout, 12.5f, std::fixed,
> std::setprecision(3));`, and the overload for `float` could easily extrac=
t
> the appropriate parameters (via a variadic template) and do the right
> thing. This is also more flexible, as arbitrary user-defined types can ha=
ve
> their *own* formatting parameters. By contrast, streams define a specific
> set of formatting parameters, and anything else has to be done a differen=
t
> way.
>
> So whether this is good or not is, ultimately, in the eye of the beholder=
..
>

+1


> Also, you have to deal with Unicode issues. Like decomposition. Consider =
Unicode
>>> codepoint U+00B7, MIDDLE DOT
>>> <http://www.fileformat.info/info/unicode/char/00B7/index.htm>. Now,
>>> what should happen if you use Unicode codepoint U+0387: GREEK ANO TELLA
>>> <http://www.fileformat.info/info/unicode/char/0387/index.htm>. This is
>>> the difference between "=C2=B7" and "=CE=87". Did your font render them=
 differently?
>>> It certainly didn't have to.
>>>
>>> Even if your font does render them differently, if you convert the file
>>> to NFC, the latter becomes the former. What was once just a random
>>> character suddenly became a C++ operator.
>>>
>>> That's not good.
>>>
>>
>> Yeah, we have to be careful with encoding as always, but you can simply
>> tell your compiler what encoding you use, or maybe enforce utf8, or
>> whatever is deemed proper.
>>
> --
> 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/cf875100-93f0-45ec-
> 9a46-205e0af7a8fe%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cf875100-93=
f0-45ec-9a46-205e0af7a8fe%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=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/CAOfiQqmH-Ro-hM7djrbZ7tZPvZLoDVXsuYwNQBF42rDLBiy=
Dug%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
3 February 2017 at 17:07, 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:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><span class=3D"gmail-">On Thursday, February 23, 2017 at 6:47:30 PM UTC=
-5, <a href=3D"mailto:god...@gmail.com" target=3D"_blank">god...@gmail.com<=
/a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr=
">Le vendredi 24 f=C3=A9vrier 2017 00:16:04 UTC+1, Nicol Bolas a =C3=A9crit=
=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">O=
n Thursday, February 23, 2017 at 10:18:04 AM UTC-5, <a>god...@gmail.com</a>=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">T=
o summarize:<br>- the &quot;a cross b&quot; syntax is a bit pointless since=
 we can do &quot;a *cross* b&quot; already, which not so bad already, just =
a bit of boilerplate to define the operator, and the operator itself is a b=
it long.<br>-  the &quot;a=C3=97b&quot; syntax would be troublesome to user=
s who can&#39;t type the symbol easily, and it might not be supported by so=
me compilers easily if they have trouble with encoding.<br>=C2=A0 <br>In my=
 opinion, for the minority users who would use these operators, IBM compile=
r probably doesn&#39;t matter (it doesn&#39;t support c++14 anyway accordin=
g to this <a href=3D"http://en.cppreference.com/w/cpp/compiler_support" rel=
=3D"nofollow" target=3D"_blank">http://en.cppreference.com/w/c<wbr>pp/compi=
ler_support</a>), and the syntax is much easier to read.</div></blockquote>=
<div><br>It&#39;s easy to say &quot;let&#39;s cut=20
compatibility with stuff I don&#39;t personally use&quot;. It&#39;s a lot h=
arder to=20
tell people that they can&#39;t have new features because some subset of=20
programmers wanted dot products as operators.<br></div></div></blockquote><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Ty=
ping is actually quicker with a compose key than writing something like &qu=
ot;a *cross* b&quot; or &quot;a.cross(b)&quot;, and an IDE could help for u=
sers without means to type non standard characters (for example: alt+. alt+=
x).<br></div></blockquote><div><br>I don&#39;t even know what a &quot;compo=
se key&quot; is, let alone have any idea how to use one. So for me, the ver=
sions that use the basic character set will be much faster to type.<br><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Th=
e real question might be: is it easy to implement for the 3 major compilers=
 (gcc clang, msvc) ? That I don&#39;t know...<br></div></blockquote><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br>About more =
specific remarks :<br><br>&gt; Most C++ users don&#39;t go around doing dot=
 products, cross products, and the like.<br>What about those who do ?<br></=
div></blockquote><div><br>... What about them?<br><br>The fact of the matte=
r is, the benefits of this feature are <i>trivial</i>. They represent nothi=
ng more than convenient notation more.<br><br>How can you justify your conv=
enience over the ability of other people to have a C++ compiler? How can yo=
u justify your comfort over the ability of some users to even use C++ at al=
l.<br><br>Language features should do the least harm. That&#39;s why we try=
 to make them backwards compatible. If we&#39;re going to make a breaking c=
hange, particularly one of this magnitude, it had <i>better</i> be for a fe=
ature that&#39;s worth the cost.<br><br>And the convenience of a subset of =
C++ programmers is <i>not good enough</i>.<br></div></div></blockquote><div=
><br>I have no clue what you are talking about... This is fully backward co=
mpatible except if someone is using middle dots in its code now, which I do=
ubt. This changes nothing to people who don&#39;t use the new operators, wh=
ether their compiler implement it or not.<br></div></div></blockquote></spa=
n><div><br>It requires that an implementation use a character set that can =
encode all of the characters from the basic character set. By expanding the=
 basic character set, you require implementations to potentially change the=
 character sets they can take. Or more specifically, to stop supporting cha=
racter sets that cannot encode all of the characters from the expanded basi=
c character set.<br></div></div></blockquote><div><br></div><div>I fail to =
see why this would require expanding the set of characters in the basic sou=
rce character set. As for not supporting character sets that cannot represe=
nt all of unicode, that is not at all a novel requirement. A conforming imp=
lementation is already required to support \uXXXX and \U00XXXXXX escapes wi=
thin identifiers, string literals, ...</div><div><br></div><div>There may b=
e good arguments against this proposal, but this does not seem to be one of=
 them.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr"><div>Hence not being backwards compatible with files i=
n the previously-supported character set.<br>=C2=A0</div><span class=3D"gma=
il-"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><di=
v>For the end user, convenience for free is better than nothing.<br></div><=
/div></blockquote><div><br></div></span>Can you provide an explanation for =
how ditching EBCDIC and thus breaking compatibility with those files is &qu=
ot;free&quot;?<span class=3D"gmail-"><br><br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><div dir=3D"ltr"><div>And readability is a bit more tha=
n convenience.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div dir=3D"ltr"><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr">&gt; Not only that, creating more operators =
means giving more people the=20
chance to overload them for less regular uses. And quite frankly, we get
 enough of that as is.<br>The fact that a tool can be misused does not make=
 the tool bad.</div></blockquote><div><br>Sure, but that doesn&#39;t make i=
t <i>good</i> either. We shouldn&#39;t encourage misuse of the language, an=
d adding dozens of operators that have no built-in function encourages misu=
se of the language. Especially without any standard-defined meaning given t=
o them.<br></div></div></blockquote><div><br>What encourages misuse of the =
language is not having enough operators, where you end up hacking those you=
 have in place of using those you don&#39;t.<br></div></div></blockquote></=
span><div><br>Or you can just do what normal people do and write `cross(a, =
b)`. That&#39;s not a hack. And to be perfectly honest, I&#39;d much rather=
 we (as someone earlier suggested) permit in-fix calling notation for regul=
ar functions. Or at least, provide a way to declare an &quot;operator Funcn=
ame&quot;, such that `Funcname` can thereafter be used as an operator.<br><=
br>It&#39;d be a lot easier to type `a cross b` for people who don&#39;t us=
e Unicode frequently. It also wouldn&#39;t break support for non-Unicode-ab=
le character sets.<br><br>Also, is there any prior art for this feature? Fo=
r example, do other languages support a wide variety of Unicode operators? =
More recent languages, like Swift and Go, do not support such features.<br>=
</div></div></blockquote><div><br></div><div>You are mistaken about Swift. =
Swift and Haskell support arbitrary user-defined custom operators, spelled =
with Unicode operator characters: <a href=3D"https://developer.apple.com/li=
brary/content/documentation/Swift/Conceptual/Swift_Programming_Language/Adv=
ancedOperators.html#//apple_ref/doc/uid/TP40014097-CH27-ID46">https://devel=
oper.apple.com/library/content/documentation/Swift/Conceptual/Swift_Program=
ming_Language/AdvancedOperators.html#//apple_ref/doc/uid/TP40014097-CH27-ID=
46</a>, <a href=3D"https://www.haskell.org/onlinereport/lexemes.html">https=
://www.haskell.org/onlinereport/lexemes.html</a></div><div><br></div><div>H=
owever, Rust and Dart, like C++, support overloading only for a fixed subse=
t of builtin operators:=C2=A0<a href=3D"https://doc.rust-lang.org/std/ops/"=
>https://doc.rust-lang.org/std/ops/</a>,=C2=A0<a href=3D"https://www.dartla=
ng.org/guides/language/language-tour#overridable-operators">https://www.dar=
tlang.org/guides/language/language-tour#overridable-operators</a></div><div=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r"><div></div><span class=3D"gmail-"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr"><div>Standard defined meaning may not be a goo=
d thing. Example of meaningful usage is good, but some unknown folks may co=
me up with their own interpretation of symbols which is widespread in their=
 community, and that would be perfectly good to me even if this is not defi=
ned in the standard. For instance, operator/ is now used in std::filesystem=
, operator&lt;&lt; is used in iostream, soon we will have operator| for ran=
ges as in bash pipes. If the symbol is the good one for some usage, it is g=
ood to use it, and so it is good to have it available as an operator.<br></=
div></div></blockquote></span><div><br>It should be noted that a number of =
C++ programmers lament the use of `&lt;&lt;` and `&gt;&gt;` for streams. In=
deed, the use of `&lt;&lt;` for insertion into streams makes it exceedingly=
 difficult to implement certain formatting tasks. It leads to horrors like =
`std::cout &lt;&lt; std::fixed &lt;&lt; std::setprecision(3) &lt;&lt; 12.5f=
;`. Why? Because we cannot provide additional parameters to the call to `op=
erator&lt;&lt;`, and that operator call is what does the formatting. It req=
uires the stream to store these formatting parameters, all so that the `ope=
rator&lt;&lt;` overload can read them and respond to them.<br><br>Consider =
the functional equivalent: `insert(cout, 12.5f, std::fixed, std::setprecisi=
on(3));`, and the overload for `float` could easily extract the appropriate=
 parameters (via a variadic template) and do the right thing. This is also =
more flexible, as arbitrary user-defined types can have their <i>own</i> fo=
rmatting parameters. By contrast, streams define a specific set of formatti=
ng parameters, and anything else has to be done a different way.<br><br>So =
whether this is good or not is, ultimately, in the eye of the beholder.<br>=
</div></div></blockquote><div><br></div><div>+1</div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div></div><s=
pan class=3D"gmail-"><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div=
 dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"ltr"><div>Also, you have to deal with Unicode issues. Like decom=
position. Consider <a href=3D"http://www.fileformat.info/info/unicode/char/=
00B7/index.htm" rel=3D"nofollow" target=3D"_blank">Unicode codepoint U+00B7=
, MIDDLE DOT</a>. Now, what should happen if you use <a href=3D"http://www.=
fileformat.info/info/unicode/char/0387/index.htm" rel=3D"nofollow" target=
=3D"_blank">Unicode codepoint U+0387: GREEK ANO TELLA</a>. This is the diff=
erence between &quot;=C2=B7&quot; and &quot;=CE=87&quot;. Did your font ren=
der them differently? It certainly didn&#39;t have to.<br><br>Even if your =
font does render them differently, if you convert the file to NFC, the latt=
er becomes the former. What was once just a random character suddenly becam=
e a C++ operator.<br><br>That&#39;s not good.</div></div></blockquote><div>=
<br>Yeah, we have to be careful with encoding as always, but you can simply=
 tell your compiler what encoding you use, or maybe enforce utf8, or whatev=
er is deemed proper.<br></div></div></blockquote></span></div><span class=
=3D"gmail-">

<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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cf875100-93f0-45ec-9a46-205e0af7a8fe%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/cf87=
5100-93f0-45ec-<wbr>9a46-205e0af7a8fe%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></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/CAOfiQqmH-Ro-hM7djrbZ7tZPvZLoDVXsuYwN=
QBF42rDLBiyDug%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqmH-Ro-hM7d=
jrbZ7tZPvZLoDVXsuYwNQBF42rDLBiyDug%40mail.gmail.com</a>.<br />

--f403045f50d02af4d705493ccf84--

.

------=_Part_53_351787807.1487906252106
Content-Type: multipart/alternative;
 boundary="----=_Part_54_1455274877.1487906252106"

------=_Part_54_1455274877.1487906252106
Content-Type: text/plain; charset=UTF-8

On Thursday, February 23, 2017 at 8:40:09 PM UTC-5, Richard Smith wrote:
>
> On 23 February 2017 at 17:07, Nicol Bolas <jmck...@gmail.com <javascript:>
> > wrote:
>
>> It requires that an implementation use a character set that can encode
>> all of the characters from the basic character set. By expanding the basic
>> character set, you require implementations to potentially change the
>> character sets they can take. Or more specifically, to stop supporting
>> character sets that cannot encode all of the characters from the expanded
>> basic character set.
>>
>
> I fail to see why this would require expanding the set of characters in
> the basic source character set. As for not supporting character sets that
> cannot represent all of unicode, that is not at all a novel requirement. A
> conforming implementation is already required to support \uXXXX and
> \U00XXXXXX escapes within identifiers, string literals, ...
>

I was unaware that you could use escapes outside of string literals, let
alone for identifiers.

There may be good arguments against this proposal, but this does not seem
> to be one of them.
>

And the fact that you can use unicode characters in identifiers actually
makes this proposal unworkable for different reasons. This means that
U+00B7 by itself is currently a *valid identifier*. Which means that
`\u00B7` could very well be legitimate code in C++. And therefore, so could
the direct Unicode encoding of it.

Which means we cannot retroactively transform these into built-in operators
without (theoretically) breaking people. So the only way to make this work
is to change the feature to permit users to declare arbitrary operators,
which can be any identifier.


>
>> Hence not being backwards compatible with files in the
>> previously-supported character set.
>>
>>
>>> For the end user, convenience for free is better than nothing.
>>>
>>
>> Can you provide an explanation for how ditching EBCDIC and thus breaking
>> compatibility with those files is "free"?
>>
>> And readability is a bit more than convenience.
>>>
>>>
>>>>
>>>>
>>>>> > Not only that, creating more operators means giving more people the
>>>>> chance to overload them for less regular uses. And quite frankly, we get
>>>>> enough of that as is.
>>>>> The fact that a tool can be misused does not make the tool bad.
>>>>>
>>>>
>>>> Sure, but that doesn't make it *good* either. We shouldn't encourage
>>>> misuse of the language, and adding dozens of operators that have no
>>>> built-in function encourages misuse of the language. Especially without any
>>>> standard-defined meaning given to them.
>>>>
>>>
>>> What encourages misuse of the language is not having enough operators,
>>> where you end up hacking those you have in place of using those you don't.
>>>
>>
>> Or you can just do what normal people do and write `cross(a, b)`. That's
>> not a hack. And to be perfectly honest, I'd much rather we (as someone
>> earlier suggested) permit in-fix calling notation for regular functions. Or
>> at least, provide a way to declare an "operator Funcname", such that
>> `Funcname` can thereafter be used as an operator.
>>
>> It'd be a lot easier to type `a cross b` for people who don't use Unicode
>> frequently. It also wouldn't break support for non-Unicode-able character
>> sets.
>>
>> Also, is there any prior art for this feature? For example, do other
>> languages support a wide variety of Unicode operators? More recent
>> languages, like Swift and Go, do not support such features.
>>
>
> You are mistaken about Swift. Swift and Haskell support arbitrary
> user-defined custom operators, spelled with Unicode operator characters:
> https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/AdvancedOperators.html#//apple_ref/doc/uid/TP40014097-CH27-ID46,
> https://www.haskell.org/onlinereport/lexemes.html
>

> However, Rust and Dart, like C++, support overloading only for a fixed
> subset of builtin operators: https://doc.rust-lang.org/std/ops/,
> https://www.dartlang.org/guides/language/language-tour#overridable-operators
>
>
So, from a prior art perspective, we seem to have two sets of approaches to
operators:

1: The C++ way: provide a basic, fixed but overloadable set of operators.

2: Provide some default operators, but also allow people to create their
own.

Nobody seems to bother providing a bunch of Unicode operators without
providing people the ability to just invent operators out of whole cloth.

The big problem C++ has with using #2 is operator precedence. See in C++,
precedence isn't written into the language. Well, it is, but the way it is
defined is through the *grammar*. As such, `a + b * c` does `b * c` first,
not because the language says that `*` comes before `+` in some precedence
hierarchy, but because the language's grammar says it does.

Changing that is... tough. Probably. It would require (particularly in the
face of templates) being able to reinterpret the very syntax of an
expression based on some definitions in code. `a + b \u00B7 c` would have
to be parsed differently based on where it appears and how that operator is
defined. Should precedence be part of an operator's definition, so changing
it in another TU is a violation of the ODR?

It's very complicated to re-specify how all of this works in C++.

--
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/37acb443-47fd-4149-81c7-dfd7e6cdf30f%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, February 23, 2017 at 8:40:09 PM UTC-5, Richar=
d Smith 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"=
><div><div class=3D"gmail_quote">On 23 February 2017 at 17:07, Nicol Bolas =
<span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"Gsx9DCjfAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#3=
9;;return true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span></span>It require=
s that an implementation use a character set that can encode all of the cha=
racters from the basic character set. By expanding the basic character set,=
 you require implementations to potentially change the character sets they =
can take. Or more specifically, to stop supporting character sets that cann=
ot encode all of the characters from the expanded basic character set.<br><=
/div></blockquote><div><br></div><div>I fail to see why this would require =
expanding the set of characters in the basic source character set. As for n=
ot supporting character sets that cannot represent all of unicode, that is =
not at all a novel requirement. A conforming implementation is already requ=
ired to support \uXXXX and \U00XXXXXX escapes within identifiers, string li=
terals, ...</div></div></div></div></blockquote><div><br>I was unaware that=
 you could use escapes outside of string literals, let alone for identifier=
s.<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"lt=
r"><div><div class=3D"gmail_quote"><div></div><div>There may be good argume=
nts against this proposal, but this does not seem to be one of them.</div><=
/div></div></div></blockquote><div><br>And the fact that you can use unicod=
e characters in identifiers actually makes this proposal unworkable=20
for different reasons. This means that U+00B7 by itself is currently a <i>v=
alid identifier</i>.
 Which means that `\u00B7` could very well be legitimate code in C++.=20
And therefore, so could the direct Unicode encoding of it.<br><br>Which=20
means we cannot retroactively transform these into built-in operators=20
without (theoretically) breaking people. So the only way to make this work =
is to change=20
the feature to permit users to declare arbitrary operators, which can be
 any identifier.<br><br></div><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"><div><div class=3D"gmail_quote"><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hence not be=
ing backwards compatible with files in the previously-supported character s=
et.<br>=C2=A0</div><span><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div>For the end user, convenience for free is better than=
 nothing.<br></div></div></blockquote><div><br></div></span>Can you provide=
 an explanation for how ditching EBCDIC and thus breaking compatibility wit=
h those files is &quot;free&quot;?<span><br><br><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex"><div dir=3D"ltr"><div>And readability is a bit more =
than convenience.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div dir=3D"ltr"><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr">&gt; Not only that, creating more operato=
rs means giving more people the=20
chance to overload them for less regular uses. And quite frankly, we get
 enough of that as is.<br>The fact that a tool can be misused does not make=
 the tool bad.</div></blockquote><div><br>Sure, but that doesn&#39;t make i=
t <i>good</i> either. We shouldn&#39;t encourage misuse of the language, an=
d adding dozens of operators that have no built-in function encourages misu=
se of the language. Especially without any standard-defined meaning given t=
o them.<br></div></div></blockquote><div><br>What encourages misuse of the =
language is not having enough operators, where you end up hacking those you=
 have in place of using those you don&#39;t.<br></div></div></blockquote></=
span><div><br>Or you can just do what normal people do and write `cross(a, =
b)`. That&#39;s not a hack. And to be perfectly honest, I&#39;d much rather=
 we (as someone earlier suggested) permit in-fix calling notation for regul=
ar functions. Or at least, provide a way to declare an &quot;operator Funcn=
ame&quot;, such that `Funcname` can thereafter be used as an operator.<br><=
br>It&#39;d be a lot easier to type `a cross b` for people who don&#39;t us=
e Unicode frequently. It also wouldn&#39;t break support for non-Unicode-ab=
le character sets.<br><br>Also, is there any prior art for this feature? Fo=
r example, do other languages support a wide variety of Unicode operators? =
More recent languages, like Swift and Go, do not support such features.<br>=
</div></div></blockquote><div><br></div><div>You are mistaken about Swift. =
Swift and Haskell support arbitrary user-defined custom operators, spelled =
with Unicode operator characters: <a href=3D"https://developer.apple.com/li=
brary/content/documentation/Swift/Conceptual/Swift_Programming_Language/Adv=
ancedOperators.html#//apple_ref/doc/uid/TP40014097-CH27-ID46" target=3D"_bl=
ank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.co=
m/url?q\x3dhttps%3A%2F%2Fdeveloper.apple.com%2Flibrary%2Fcontent%2Fdocument=
ation%2FSwift%2FConceptual%2FSwift_Programming_Language%2FAdvancedOperators=
..html%23%2F%2Fapple_ref%2Fdoc%2Fuid%2FTP40014097-CH27-ID46\x26sa\x3dD\x26sn=
tz\x3d1\x26usg\x3dAFQjCNHdvWhUW-FCyPYcCos0BnBfSI4S4A&#39;;return true;" onc=
lick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdeve=
loper.apple.com%2Flibrary%2Fcontent%2Fdocumentation%2FSwift%2FConceptual%2F=
Swift_Programming_Language%2FAdvancedOperators.html%23%2F%2Fapple_ref%2Fdoc=
%2Fuid%2FTP40014097-CH27-ID46\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHdvWh=
UW-FCyPYcCos0BnBfSI4S4A&#39;;return true;">https://developer.apple.com/<wbr=
>library/content/documentation/<wbr>Swift/Conceptual/Swift_<wbr>Programming=
_Language/<wbr>AdvancedOperators.html#//<wbr>apple_ref/doc/uid/TP40014097-<=
wbr>CH27-ID46</a>, <a href=3D"https://www.haskell.org/onlinereport/lexemes.=
html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ht=
tps://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.haskell.org%2Fonlinereport%=
2Flexemes.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGn2z1uDD6LCdUpAiUDpE=
h9wiEIeA&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.google.=
com/url?q\x3dhttps%3A%2F%2Fwww.haskell.org%2Fonlinereport%2Flexemes.html\x2=
6sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGn2z1uDD6LCdUpAiUDpEh9wiEIeA&#39;;ret=
urn true;">https://www.haskell.org/<wbr>onlinereport/lexemes.html</a></div>=
</div></div></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"><div><div class=3D"gmail_quote"><div><br></div=
><div>However, Rust and Dart, like C++, support overloading only for a fixe=
d subset of builtin operators:=C2=A0<a href=3D"https://doc.rust-lang.org/st=
d/ops/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;=
https://www.google.com/url?q\x3dhttps%3A%2F%2Fdoc.rust-lang.org%2Fstd%2Fops=
%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGyiv8oBEhbwRm-D8XF5QtaRWwWCg&#3=
9;;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x=
3dhttps%3A%2F%2Fdoc.rust-lang.org%2Fstd%2Fops%2F\x26sa\x3dD\x26sntz\x3d1\x2=
6usg\x3dAFQjCNGyiv8oBEhbwRm-D8XF5QtaRWwWCg&#39;;return true;">https://doc.r=
ust-<wbr>lang.org/std/ops/</a>,=C2=A0<a href=3D"https://www.dartlang.org/gu=
ides/language/language-tour#overridable-operators" target=3D"_blank" rel=3D=
"nofollow" onmousedown=3D"this.href=3D&#39;https://www.dartlang.org/guides/=
language/language-tour#overridable-operators&#39;;return true;" onclick=3D"=
this.href=3D&#39;https://www.dartlang.org/guides/language/language-tour#ove=
rridable-operators&#39;;return true;">https://<wbr>www.dartlang.org/guides/=
<wbr>language/language-tour#<wbr>overridable-operators</a></div><div><br></=
div></div></div></div></blockquote><div><br>So, from a prior art perspectiv=
e, we seem to have two sets of approaches to operators:<br><br>1: The C++ w=
ay: provide a basic, fixed but overloadable set of operators.<br><br>2: Pro=
vide some default operators, but also allow people to create their own.<br>=
<br>Nobody seems to bother providing a bunch of Unicode operators without p=
roviding people the ability to just invent operators out of whole cloth.<br=
><br>The big problem C++ has with using #2 is operator precedence. See in C=
++, precedence isn&#39;t written into the language. Well, it is, but the wa=
y it is defined is through the <i>grammar</i>. As such, `a + b * c` does `b=
 * c` first, not because the language says that `*` comes before `+` in som=
e precedence hierarchy, but because the language&#39;s grammar says it does=
..<br><br>Changing that is... tough. Probably. It would require (particularl=
y in the face of templates) being able to reinterpret the very syntax of an=
 expression based on some definitions in code. `a + b \u00B7 c` would have =
to be parsed differently based on where it appears and how that operator is=
 defined. Should precedence be part of an operator&#39;s definition, so cha=
nging it in another TU is a violation of the ODR?<br><br>It&#39;s very comp=
licated to re-specify how all of this works in C++.</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/37acb443-47fd-4149-81c7-dfd7e6cdf30f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/37acb443-47fd-4149-81c7-dfd7e6cdf30f=
%40isocpp.org</a>.<br />

------=_Part_54_1455274877.1487906252106--

------=_Part_53_351787807.1487906252106--

.

This is a multi-part message in MIME format.
--------------CF368E3BF33A8BE82844D3DB
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 22/02/2017 =C3=A0 20:49, godefv@gmail.com a =C3=A9crit :
> =3D=3D Problem =3D=3D
> Some math operators are missing from the standard.
> <snip>
> =3D=3D Proposal =3D=3D
> Allow more operators, possibly using characters not currently in the=20
> c++ character set, such as "a=C2=B7b" "a=E2=88=A7b" "a=C3=97b" or possibl=
y using=20
> multiple characters such as "a**b" "a cross b" "a dot b".
> Using characters not currently in the c++ character set guaranties=20
> backward compatibility, and is easier to read I think.
>
> The =C2=B7 and =C3=97 operators are already missing in the two main math=
=20
> libraries of interest to me, which shows that it would be useful to=20
> add them.
> Interest in an exponent operator has already been shown in another=20
> topic (** and *^ have been suggested there, I think ** is better,=20
> compiler just need to parse things properly to avoid issues that we=20
> had with operators >> or >=3D and templates).
> The wedge operator is important too and even if using the operator^=20
> instead is ok, it could be added as well while we are at it.
>
> =3D=3D Related topics =3D=3D
> https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/mat=
hematical$20operators/std-proposals/Xr8H8V_fnEs/gbW1uBImoSQJ
> https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/new=
$20operators/std-proposals/uTOtGMYyJEo/KA9z8TSfnHEJ

Another important link ;-)


      Generalizing Overloading for C++2000 - Bjarne Stroustrup's
      Homepage
      <https://www.google.fr/url?sa=3Dt&rct=3Dj&q=3D&esrc=3Ds&source=3Dweb&=
cd=3D1&ved=3D0ahUKEwjeu_SLvqfSAhXpKMAKHSmNC1YQFggcMAA&url=3Dhttp%3A%2F%2Fww=
w.stroustrup.com%2Fwhitespace98.pdf&usg=3DAFQjCNFDpJqw9auUZWuYDJcUwrz-IiEjn=
g&sig2=3Ds3VoRF5sPXAKGgN-tfYvCw&cad=3Drja>


https://www.google.fr/url?sa=3Dt&rct=3Dj&q=3D&esrc=3Ds&source=3Dweb&cd=3D1&=
ved=3D0ahUKEwjeu_SLvqfSAhXpKMAKHSmNC1YQFggcMAA&url=3Dhttp%3A%2F%2Fwww.strou=
strup.com%2Fwhitespace98.pdf&usg=3DAFQjCNFDpJqw9auUZWuYDJcUwrz-IiEjng&sig2=
=3Ds3VoRF5sPXAKGgN-tfYvCw

Vicente

--=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/3cd4e796-d135-ca51-fa34-cd96017aa3a3%40wanadoo.f=
r.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 22/02/2017 =C3=A0 20:49, <a class=3D"=
moz-txt-link-abbreviated" href=3D"mailto:godefv@gmail.com">godefv@gmail.com=
</a>
      a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:53de9adb-1e05-46fc-8ac9-75fb331720fa@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">=3D=3D Problem =3D=3D<br>
        Some math operators are missing from the standard.<br>
        &lt;snip&gt;<br>
        =3D=3D Proposal =3D=3D<br>
        Allow more operators, possibly using characters not currently in
        the c++ character set, such as "a=C2=B7b" "a=E2=88=A7b" "a=C3=97b" =
or possibly
        using multiple characters such as "a**b" "a cross b" "a dot b".<br>
        Using characters not currently in the c++ character set
        guaranties backward compatibility, and is easier to read I
        think.<br>
        <br>
        The =C2=B7 and =C3=97 operators are already missing in the two main=
 math
        libraries of interest to me, which shows that it would be useful
        to add them. <br>
        Interest in an exponent operator has already been shown in
        another topic (** and *^ have been suggested there, I think **
        is better, compiler just need to parse things properly to avoid
        issues that we had with operators &gt;&gt; or &gt;=3D and
        templates).<br>
        The wedge operator is important too and even if using the
        operator^ instead is ok, it could be added as well while we are
        at it.<br>
        <br>
        =3D=3D Related topics =3D=3D<br>
<a class=3D"moz-txt-link-freetext" href=3D"https://groups.google.com/a/isoc=
pp.org/forum/#!searchin/std-proposals/mathematical$20operators/std-proposal=
s/Xr8H8V_fnEs/gbW1uBImoSQJ">https://groups.google.com/a/isocpp.org/forum/#!=
searchin/std-proposals/mathematical$20operators/std-proposals/Xr8H8V_fnEs/g=
bW1uBImoSQJ</a><br>
<a class=3D"moz-txt-link-freetext" href=3D"https://groups.google.com/a/isoc=
pp.org/forum/#!searchin/std-proposals/new$20operators/std-proposals/uTOtGMY=
yJEo/KA9z8TSfnHEJ">https://groups.google.com/a/isocpp.org/forum/#!searchin/=
std-proposals/new$20operators/std-proposals/uTOtGMYyJEo/KA9z8TSfnHEJ</a><br=
>
      </div>
    </blockquote>
    <br>
    Another important link ;-)<br>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8=
">
    <br>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8=
">
    <h3 class=3D"r"><a
href=3D"https://www.google.fr/url?sa=3Dt&amp;rct=3Dj&amp;q=3D&amp;esrc=3Ds&=
amp;source=3Dweb&amp;cd=3D1&amp;ved=3D0ahUKEwjeu_SLvqfSAhXpKMAKHSmNC1YQFggc=
MAA&amp;url=3Dhttp%3A%2F%2Fwww.stroustrup.com%2Fwhitespace98.pdf&amp;usg=3D=
AFQjCNFDpJqw9auUZWuYDJcUwrz-IiEjng&amp;sig2=3Ds3VoRF5sPXAKGgN-tfYvCw&amp;ca=
d=3Drja"
        onmousedown=3D"return
rwt(this,'','','','1','AFQjCNFDpJqw9auUZWuYDJcUwrz-IiEjng','s3VoRF5sPXAKGgN=
-tfYvCw','0ahUKEwjeu_SLvqfSAhXpKMAKHSmNC1YQFggcMAA','','',event)">Generaliz=
ing
        Overloading for C++2000 - Bjarne Stroustrup's Homepage</a></h3>
    <br>
<a class=3D"moz-txt-link-freetext" href=3D"https://www.google.fr/url?sa=3Dt=
&amp;rct=3Dj&amp;q=3D&amp;esrc=3Ds&amp;source=3Dweb&amp;cd=3D1&amp;ved=3D0a=
hUKEwjeu_SLvqfSAhXpKMAKHSmNC1YQFggcMAA&amp;url=3Dhttp%3A%2F%2Fwww.stroustru=
p.com%2Fwhitespace98.pdf&amp;usg=3DAFQjCNFDpJqw9auUZWuYDJcUwrz-IiEjng&amp;s=
ig2=3Ds3VoRF5sPXAKGgN-tfYvCw">https://www.google.fr/url?sa=3Dt&amp;rct=3Dj&=
amp;q=3D&amp;esrc=3Ds&amp;source=3Dweb&amp;cd=3D1&amp;ved=3D0ahUKEwjeu_SLvq=
fSAhXpKMAKHSmNC1YQFggcMAA&amp;url=3Dhttp%3A%2F%2Fwww.stroustrup.com%2Fwhite=
space98.pdf&amp;usg=3DAFQjCNFDpJqw9auUZWuYDJcUwrz-IiEjng&amp;sig2=3Ds3VoRF5=
sPXAKGgN-tfYvCw</a><br>
    <br>
    Vicente<br>
  </body>
</html>

<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/3cd4e796-d135-ca51-fa34-cd96017aa3a3%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3cd4e796-d135-ca51-fa34-cd96017aa3a3=
%40wanadoo.fr</a>.<br />

--------------CF368E3BF33A8BE82844D3DB--

.

------=_Part_111_1466280352.1487932641176
Content-Type: multipart/alternative;
 boundary="----=_Part_112_545938442.1487932641176"

------=_Part_112_545938442.1487932641176
Content-Type: text/plain; charset=UTF-8



> And the fact that you can use unicode characters in identifiers actually
> makes this proposal unworkable for different reasons. This means that
> U+00B7 by itself is currently a *valid identifier*. Which means that
> `\u00B7` could very well be legitimate code in C++. And therefore, so could
> the direct Unicode encoding of it.
>
> Which means we cannot retroactively transform these into built-in
> operators without (theoretically) breaking people. So the only way to make
> this work is to change the feature to permit users to declare arbitrary
> operators, which can be any identifier.
>

As I said, the proposal is fully backward compatible except if someone is
using middle dots in its code now, which I doubt.
I accept that the scenario of someone using middle dots in its code now is
*theoretically* possible though.


Another important link ;-)
>
> Generalizing Overloading for C++2000 - Bjarne Stroustrup's Homepage
> <https://www.google.fr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwjeu_SLvqfSAhXpKMAKHSmNC1YQFggcMAA&url=http%3A%2F%2Fwww.stroustrup.com%2Fwhitespace98.pdf&usg=AFQjCNFDpJqw9auUZWuYDJcUwrz-IiEjng&sig2=s3VoRF5sPXAKGgN-tfYvCw&cad=rja>


Well, I hope am not talking such nonsense as restricting to one character
variables.

--
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/aceee99f-9c0b-4942-94c4-3c6a8230b493%40isocpp.org.

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

<div dir=3D"ltr"><br><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"><div>And the fact that you can use unicode characters in identifie=
rs actually makes this proposal unworkable=20
for different reasons. This means that U+00B7 by itself is currently a <i>v=
alid identifier</i>.
 Which means that `\u00B7` could very well be legitimate code in C++.=20
And therefore, so could the direct Unicode encoding of it.<br><br>Which=20
means we cannot retroactively transform these into built-in operators=20
without (theoretically) breaking people. So the only way to make this work =
is to change=20
the feature to permit users to declare arbitrary operators, which can be
 any identifier.<br></div></div></blockquote><div><br>As I said, the propos=
al is fully backward compatible except if someone is using middle dots in i=
ts code now, which I doubt.<br>I accept that the scenario of someone using =
middle dots in its code now is *theoretically* possible though.<br><br><br>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Another important=
 link ;-)<br>
   =20
    <br>
   =20
    <h3><a href=3D"https://www.google.fr/url?sa=3Dt&amp;rct=3Dj&amp;q=3D&am=
p;esrc=3Ds&amp;source=3Dweb&amp;cd=3D1&amp;ved=3D0ahUKEwjeu_SLvqfSAhXpKMAKH=
SmNC1YQFggcMAA&amp;url=3Dhttp%3A%2F%2Fwww.stroustrup.com%2Fwhitespace98.pdf=
&amp;usg=3DAFQjCNFDpJqw9auUZWuYDJcUwrz-IiEjng&amp;sig2=3Ds3VoRF5sPXAKGgN-tf=
YvCw&amp;cad=3Drja" target=3D"_blank" rel=3D"nofollow">Generalizing
        Overloading for C++2000 - Bjarne Stroustrup&#39;s Homepage</a></h3>=
</blockquote><div><br>Well, I hope am not talking such nonsense as restrict=
ing to one character variables.<br><br></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/aceee99f-9c0b-4942-94c4-3c6a8230b493%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/aceee99f-9c0b-4942-94c4-3c6a8230b493=
%40isocpp.org</a>.<br />

------=_Part_112_545938442.1487932641176--

------=_Part_111_1466280352.1487932641176--

.

------=_Part_116_1024604527.1487934190589
Content-Type: multipart/alternative;
 boundary="----=_Part_117_182718705.1487934190589"

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


>
> I don't even know what a "compose key" is, let alone have any idea how to=
=20
> use one. So for me, the versions that use the basic character set will be=
=20
> much faster to type.
>

Just a side note about the compose key :

It is a feature found on linux that you may need to enable in your window=
=20
manager : you choose a key which will act as the compose key (like the=20
right windows key for example), and then whenever you type <compose> <key1>=
=20
<key2> sequentially, it will print the character which is the composition=
=20
of <key1> and <key2>. For example, <compose><a><e> gives =C3=A6.
On Windows, you can install wincompose (
https://github.com/samhocevar/wincompose/), which provides the same=20
functionality.

In our case :
<compose> <x> <x> gives =C3=97
<compose> <.> <-> gives =C2=B7=20
<compose> </> <\> gives =E2=88=A7

--=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/b0f067d4-2e60-43c5-bbc5-a070436bb87f%40isocpp.or=
g.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">=
I don&#39;t even know what a &quot;compose key&quot; is, let alone have any=
 idea how=20
to use one. So for me, the versions that use the basic character set=20
will be much faster to type.<br></blockquote><br>Just a side note about the=
 compose key :<br><br>It is a feature found on linux that you may need to e=
nable in your window manager : you choose a key which will act as the compo=
se key (like the right windows key for example), and then whenever you type=
 &lt;compose&gt; &lt;key1&gt; &lt;key2&gt; sequentially, it will print the =
character which is the composition of &lt;key1&gt; and &lt;key2&gt;. For ex=
ample, &lt;compose&gt;&lt;a&gt;&lt;e&gt; gives =C3=A6.<br>On Windows, you c=
an install wincompose (<a href=3D"https://github.com/samhocevar/wincompose/=
">https://github.com/samhocevar/wincompose/</a>), which provides the same f=
unctionality.<br><br>In our case :<br>&lt;compose&gt; &lt;x&gt; &lt;x&gt; g=
ives =C3=97<br>&lt;compose&gt; &lt;.&gt; &lt;-&gt; gives =C2=B7 <br>&lt;com=
pose&gt; &lt;/&gt; &lt;\&gt; gives =E2=88=A7</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/b0f067d4-2e60-43c5-bbc5-a070436bb87f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b0f067d4-2e60-43c5-bbc5-a070436bb87f=
%40isocpp.org</a>.<br />

------=_Part_117_182718705.1487934190589--

------=_Part_116_1024604527.1487934190589--

.

------=_Part_662_1179941250.1487942663483
Content-Type: multipart/alternative;
 boundary="----=_Part_663_1035601670.1487942663484"

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

On Friday, February 24, 2017 at 6:03:10 AM UTC-5, god...@gmail.com wrote:
>
> I don't even know what a "compose key" is, let alone have any idea how to=
=20
>> use one. So for me, the versions that use the basic character set will b=
e=20
>> much faster to type.
>>
>
> Just a side note about the compose key :
>
> It is a feature found on linux that you may need to enable in your window=
=20
> manager : you choose a key which will act as the compose key (like the=20
> right windows key for example), and then whenever you type <compose> <key=
1>=20
> <key2> sequentially, it will print the character which is the composition=
=20
> of <key1> and <key2>. For example, <compose><a><e> gives =C3=A6.
> On Windows, you can install wincompose (
> https://github.com/samhocevar/wincompose/), which provides the same=20
> functionality.
>
> In our case :
> <compose> <x> <x> gives =C3=97
> <compose> <.> <-> gives =C2=B7=20
> <compose> </> <\> gives =E2=88=A7
>

So on the majority of desktop platforms, I have to install an executable to=
=20
be able to cleanly use this feature? One which means I have to give up a=20
key (my keyboard for example doesn't have a right windows key) just to be=
=20
able to type those operators. Well, not without escaping them.

And if you have to type a large set of characters like "\u00B7", I'd much=
=20
rather type "cross". That way, it's clear to *everybody* what's going on.

--=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/14b483a6-ccd5-4e05-a979-13974330b826%40isocpp.or=
g.

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

<div dir=3D"ltr">On Friday, February 24, 2017 at 6:03:10 AM UTC-5, god...@g=
mail.com 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=
"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">I don&#39;t even know w=
hat a &quot;compose key&quot; is, let alone have any idea how=20
to use one. So for me, the versions that use the basic character set=20
will be much faster to type.<br></blockquote><br>Just a side note about the=
 compose key :<br><br>It is a feature found on linux that you may need to e=
nable in your window manager : you choose a key which will act as the compo=
se key (like the right windows key for example), and then whenever you type=
 &lt;compose&gt; &lt;key1&gt; &lt;key2&gt; sequentially, it will print the =
character which is the composition of &lt;key1&gt; and &lt;key2&gt;. For ex=
ample, &lt;compose&gt;&lt;a&gt;&lt;e&gt; gives =C3=A6.<br>On Windows, you c=
an install wincompose (<a href=3D"https://github.com/samhocevar/wincompose/=
" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https:=
//www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fsamhocevar%2Fwincompos=
e%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEhxtlqoYFHLTOFS-tN23xnaIcPZg&#=
39;;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\=
x3dhttps%3A%2F%2Fgithub.com%2Fsamhocevar%2Fwincompose%2F\x26sa\x3dD\x26sntz=
\x3d1\x26usg\x3dAFQjCNEhxtlqoYFHLTOFS-tN23xnaIcPZg&#39;;return true;">https=
://github.com/<wbr>samhocevar/wincompose/</a>), which provides the same fun=
ctionality.<br><br>In our case :<br>&lt;compose&gt; &lt;x&gt; &lt;x&gt; giv=
es =C3=97<br>&lt;compose&gt; &lt;.&gt; &lt;-&gt; gives =C2=B7 <br>&lt;compo=
se&gt; &lt;/&gt; &lt;\&gt; gives =E2=88=A7</div></blockquote><div><br>So on=
 the majority of desktop platforms, I have to install an executable to be a=
ble to cleanly use this feature? One which means I have to give up a key (m=
y keyboard for example doesn&#39;t have a right windows key) just to be abl=
e to type those operators. Well, not without escaping them.<br><br>And if y=
ou have to type a large set of characters like &quot;\u00B7&quot;, I&#39;d =
much rather type &quot;cross&quot;. That way, it&#39;s clear to <i>everybod=
y</i> what&#39;s going on.<br></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/14b483a6-ccd5-4e05-a979-13974330b826%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/14b483a6-ccd5-4e05-a979-13974330b826=
%40isocpp.org</a>.<br />

------=_Part_663_1035601670.1487942663484--

------=_Part_662_1179941250.1487942663483--

.

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

On Fri, Feb 24, 2017 at 2:37 AM,  <godefv@gmail.com> wrote:
>>
>> And the fact that you can use unicode characters in identifiers actually
>> makes this proposal unworkable for different reasons. This means that
U+00B7
>> by itself is currently a valid identifier. Which means that `\u00B7`
could
>> very well be legitimate code in C++. And therefore, so could the direct
>> Unicode encoding of it.
>>
>> Which means we cannot retroactively transform these into built-in
>> operators without (theoretically) breaking people. So the only way to
make
>> this work is to change the feature to permit users to declare arbitrary
>> operators, which can be any identifier.
>
> As I said, the proposal is fully backward compatible except if someone is
> using middle dots in its code now, which I doubt.

The problem with your saying this is that now you're quietly shifting your
goalposts from "the C++ standard should allow overloading of
operator(middle-dot)" to "the C++ Standard should reclassify U+00B7 from
'identifier character' to 'punctuation character'"; and that's a *crazy*
different goal.


FWIW, I was unable to google up any original rationale for the choice of
identifier ranges in [lex.name] Table 2.

Here's some reading material from the XML(?) standardization process:
http://unicode.org/mail-arch/unicode-ml/Archives-Old/UML021/0787.html  "the
lexer needs certain things (e.g. digits and the standard operators) to be
special, and then *everything* else might as well be identifier characters"
http://unicode.org/mail-arch/unicode-ml/Archives-Old/UML021/0796.html
 "once given, it's very hard to take away an identifier character, so we
should be stingy in giving them out"

It surprises me that the ranges in Table 2 were not originally aligned with
Unicode categories; for example U+203D INTERROBANG
<http://www.fileformat.info/info/unicode/char/203d/index.htm> (category
[Po]) is not an identifier character even though U+00B7 MIDDLE DOT
<http://www.fileformat.info/info/unicode/char/00b7/index.htm> (also
category [Po]) *is* an identifier character. This suggests to me that the
ranges in Table 2 might have been assigned by applying the first rationale
above ("everything should be an identifier character") with just a few
ad-hoc exceptions for things that were "obviously" Western-style
punctuation glyphs (like interrobang).


>> Another important link ;-)
>>
>> Generalizing Overloading for C++2000 - Bjarne Stroustrup's Homepage
>
> Well, I hope am not talking such nonsense as restricting to one character
> variables.

I think you missed both the point and the date of that paper. ;)

=E2=80=93Arthur

--=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/CADvuK0J16DfWJBymqZoh_JguEnjAQAnvw3GiFn5AUDHsoG7=
9%3Dw%40mail.gmail.com.

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

<div dir=3D"ltr">On Fri, Feb 24, 2017 at 2:37 AM, =C2=A0&lt;<a href=3D"mail=
to:godefv@gmail.com">godefv@gmail.com</a>&gt; wrote:<br>&gt;&gt;<br>&gt;&gt=
; And the fact that you can use unicode characters in identifiers actually<=
br>&gt;&gt; makes this proposal unworkable for different reasons. This mean=
s that U+00B7<br>&gt;&gt; by itself is currently a valid identifier. Which =
means that `\u00B7` could<br>&gt;&gt; very well be legitimate code in C++. =
And therefore, so could the direct<br>&gt;&gt; Unicode encoding of it.<br>&=
gt;&gt;<br>&gt;&gt; Which means we cannot retroactively transform these int=
o built-in<br>&gt;&gt; operators without (theoretically) breaking people. S=
o the only way to make<br>&gt;&gt; this work is to change the feature to pe=
rmit users to declare arbitrary<br>&gt;&gt; operators, which can be any ide=
ntifier.<br>&gt;<br>&gt; As I said, the proposal is fully backward compatib=
le except if someone is<br>&gt; using middle dots in its code now, which I =
doubt.<div><br></div><div>The problem with your saying this is that now you=
&#39;re quietly shifting your goalposts from &quot;the C++ standard should =
allow overloading of operator(middle-dot)&quot; to &quot;the C++ Standard s=
hould reclassify U+00B7 from &#39;identifier character&#39; to &#39;punctua=
tion character&#39;&quot;; and that&#39;s a <i>crazy</i> different goal.</d=
iv><div><br></div><div><br></div><div>FWIW, I was unable to google up any o=
riginal rationale for the choice of identifier ranges in [<a href=3D"http:/=
/lex.name">lex.name</a>] Table 2.=C2=A0</div><div><br></div><div>Here&#39;s=
 some reading material from the XML(?) standardization process:<br></div><d=
iv><div><a href=3D"http://unicode.org/mail-arch/unicode-ml/Archives-Old/UML=
021/0787.html">http://unicode.org/mail-arch/unicode-ml/Archives-Old/UML021/=
0787.html</a> =C2=A0&quot;the lexer needs certain things (e.g. digits and t=
he standard operators) to be special, and then <i>everything</i> else might=
 as well be identifier characters&quot;<br></div><div><a href=3D"http://uni=
code.org/mail-arch/unicode-ml/Archives-Old/UML021/0796.html">http://unicode=
..org/mail-arch/unicode-ml/Archives-Old/UML021/0796.html</a> =C2=A0&quot;onc=
e given, it&#39;s very hard to take away an identifier character, so we sho=
uld be stingy in giving them out&quot;<br></div><div><br></div><div><div>It=
 surprises me that the ranges in Table 2 were not originally aligned with U=
nicode categories; for example=C2=A0<a href=3D"http://www.fileformat.info/i=
nfo/unicode/char/203d/index.htm">U+203D INTERROBANG</a>=C2=A0(category [Po]=
) is not an identifier character even though=C2=A0<a href=3D"http://www.fil=
eformat.info/info/unicode/char/00b7/index.htm">U+00B7 MIDDLE DOT</a>=C2=A0(=
also category [Po])=C2=A0<i>is</i>=C2=A0an identifier character. This sugge=
sts to me that the ranges in Table 2 might have been assigned by applying t=
he first rationale above (&quot;everything should be an identifier characte=
r&quot;) with just a few ad-hoc exceptions for things that were &quot;obvio=
usly&quot; Western-style punctuation glyphs (like interrobang).</div></div>=
</div><div><br></div><div><br>&gt;&gt; Another important link ;-)<br>&gt;&g=
t;<br>&gt;&gt; Generalizing Overloading for C++2000 - Bjarne Stroustrup&#39=
;s Homepage<br>&gt;<br>&gt; Well, I hope am not talking such nonsense as re=
stricting to one character<br>&gt; variables.<br><br></div><div>I think you=
 missed both the point and the date of that paper. ;)</div><div><br></div><=
div>=E2=80=93Arthur</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/CADvuK0J16DfWJBymqZoh_JguEnjAQAnvw3Gi=
Fn5AUDHsoG79%3Dw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0J16DfWJB=
ymqZoh_JguEnjAQAnvw3GiFn5AUDHsoG79%3Dw%40mail.gmail.com</a>.<br />

--001a11443f86b770b205494b7143--

.

On Fri, Feb 24, 2017 at 4:24 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Friday, February 24, 2017 at 6:03:10 AM UTC-5, god...@gmail.com wrote:
>>
>> Just a side note about the compose key :
>>
>> It is a feature found on linux that you may need to enable in your windo=
w
>> manager : you choose a key which will act as the compose key (like the r=
ight
>> windows key for example), and then whenever you type <compose> <key1> <k=
ey2>
>> sequentially, it will print the character which is the composition of <k=
ey1>
>> and <key2>. For example, <compose><a><e> gives =C3=A6.
>> On Windows, you can install wincompose
>> (https://github.com/samhocevar/wincompose/), which provides the same
>> functionality.
>
> So on the majority of desktop platforms, I have to install an executable =
to
> be able to cleanly use this feature? One which means I have to give up a =
key
> (my keyboard for example doesn't have a right windows key) just to be abl=
e
> to type those operators.

To be fair, you do need to install *something* on Windows if you ever
want to type a Unicode character, in a program or otherwise. I don't
think there is a way to do that in a default Windows*. Compose just
seems to be the most convenient way to do that.

OS X seems to require an application too to enable compose, although
I'm not sure if the application simply configures a builtin
functionality in the OS or does something more substantial than that.

(*) I do remember it was possible to type a character code with Alt
pressed, but AFAIR, it didn't work everywhere and was limited to
ASCII.

> And if you have to type a large set of characters like "\u00B7", I'd much
> rather type "cross". That way, it's clear to everybody what's going on.

On that I agree.

--=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/CAEhD%2B6A-znnsZvUjOd%3Di_MMxE_6HqjVaWt03z6aV2uQ=
L5K42eQ%40mail.gmail.com.

.

On sexta-feira, 24 de fevereiro de 2017 02:37:21 PST godefv@gmail.com wrote:
> As I said, the proposal is fully backward compatible except if someone is
> using middle dots in its code now, which I doubt.

Check 2.10 [lex.name] to see if those characters are allowed as identifiers.

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

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2082704.M6NPMmVra3%40tjmaciei-mobl1.

.

On sexta-feira, 24 de fevereiro de 2017 11:07:42 PST Arthur O'Dwyer wrote:
> The problem with your saying this is that now you're quietly shifting you=
r
> goalposts from "the C++ standard should allow overloading of
> operator(middle-dot)" to "the C++ Standard should reclassify U+00B7 from
> 'identifier character' to 'punctuation character'"; and that's a *crazy*
> different goal.

This is valid C++:

  int paral=C2=B7lel =3D 0; // Catalan
  int =C2=B7 =3D 0;

But this isn't valid C++:

  int =E2=8B=85 =3D 0;
  int =E2=88=A7 =3D 0;

Clang prints an unhelpful even if strictly correct "non-ASCII characters ar=
e=20
not allowed outside of literals and identifiers" [1] , whereas ICC prints=
=20
"unrecognized token" and "expected an identifier"

[1] https://godbolt.org/g/Wd8zj4
--=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/1631681.4QJTNJvFT9%40tjmaciei-mobl1.

.

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

On Fri, Feb 24, 2017 at 1:58 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> On sexta-feira, 24 de fevereiro de 2017 11:07:42 PST Arthur O'Dwyer wrote=
:
> > The problem with your saying this is that now you're quietly shifting
> your
> > goalposts from "the C++ standard should allow overloading of
> > operator(middle-dot)" to "the C++ Standard should reclassify U+00B7 fro=
m
> > 'identifier character' to 'punctuation character'"; and that's a *crazy=
*
> > different goal.
>
> This is valid C++:
>
>   int paral=C2=B7lel =3D 0;    // Catalan
>   int =C2=B7 =3D 0;
>
> But this isn't valid C++:
>
>   int =E2=8B=85 =3D 0;
>   int =E2=88=A7 =3D 0;
>

Good call. For those without easy access to `od -t x1` or Python `print
repr(...)` or whatever, the dot-looking things in the first example are the
U+00B7 MIDDLE DOT that the OP was asking for; the dot-looking thing in the
second example is U+22C5 DOT OPERATOR
<http://www.fileformat.info/info/unicode/char/22c5/index.htm> which is
"preferred
to U+00B7 <http://www.fileformat.info/info/unicode/char/00b7/index.htm> for
denotation of multiplication" according to the Unicode comments field.

It's this kind of subtleties that make this whole idea of non-ASCII source
code seem like a bad idea. What's the point of *allowing* it, if nobody
will ever be able to *use* it without periodic consultation of a hex editor=
?

As for defining new operators, the killer there seems to be "precedence."
What should the precedence of operator\u22C5 be? Should the precedence of
operator\u2227 be the same as that of operator&&, or as that of operator&?
Without a unified proposal covering this kind of question (in generic
terms, not just for these two special cases), I don't think it makes sense
to discuss any specific cases.

For a really really good recent paper covering new-operator issues, see
Herb Sutter's P0515
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0515r0.pdf>. It
introduces operator<=3D> with a full discussion (page 11) of where the new
operator will fit into the precedence chart.

=E2=80=93Arthur

--=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/CADvuK0Lgrjaro93ic_R46Chkqn5mqWJKkB6cCuaU%3DptF4=
xzAbA%40mail.gmail.com.

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

<div dir=3D"ltr">On Fri, Feb 24, 2017 at 1:58 PM, Thiago Macieira <span dir=
=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiag=
o@macieira.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex"><span class=3D"m_1606911127658944156gma=
il-">On sexta-feira, 24 de fevereiro de 2017 11:07:42 PST Arthur O&#39;Dwye=
r wrote:<br>
&gt; The problem with your saying this is that now you&#39;re quietly shift=
ing your<br>
&gt; goalposts from &quot;the C++ standard should allow overloading of<br>
&gt; operator(middle-dot)&quot; to &quot;the C++ Standard should reclassify=
 U+00B7 from<br>
</span>&gt; &#39;identifier character&#39; to &#39;punctuation character&#3=
9;&quot;; and that&#39;s a *crazy*<br>
&gt; different goal.<br>
<br>
This is valid C++:<br>
<br>
=C2=A0 int paral=C2=B7lel =3D 0;=C2=A0 =C2=A0 // Catalan<br>
=C2=A0 int =C2=B7 =3D 0;<br>
<br>
But this isn&#39;t valid C++:<br>
<br>
=C2=A0 int =E2=8B=85 =3D 0;<br>
=C2=A0 int =E2=88=A7 =3D 0;<br></blockquote><div><br></div><div>Good call. =
For those without easy access to `od -t x1` or Python `print repr(...)` or =
whatever, the dot-looking things in the first example are the U+00B7 MIDDLE=
 DOT that the OP was asking for; the dot-looking thing in the second exampl=
e is <a href=3D"http://www.fileformat.info/info/unicode/char/22c5/index.htm=
" target=3D"_blank">U+22C5 DOT OPERATOR</a>=C2=A0which is &quot;<span style=
=3D"color:rgb(51,51,51);font-family:&#39;open sans&#39;,&#39;helvetica neue=
&#39;,helvetica,arial,sans-serif;font-size:14px">preferred to=C2=A0</span><=
a href=3D"http://www.fileformat.info/info/unicode/char/00b7/index.htm" styl=
e=3D"color:rgb(0,136,204);text-decoration:none;font-family:&#39;open sans&#=
39;,&#39;helvetica neue&#39;,helvetica,arial,sans-serif;font-size:14px" tar=
get=3D"_blank">U+00B7</a><span style=3D"color:rgb(51,51,51);font-family:&#3=
9;open sans&#39;,&#39;helvetica neue&#39;,helvetica,arial,sans-serif;font-s=
ize:14px">=C2=A0for denotation of multiplication</span>&quot; according to =
the Unicode comments field.</div><div><br></div><div>It&#39;s this kind of =
subtleties that make this whole idea of non-ASCII source code seem like a b=
ad idea. What&#39;s the point of <i>allowing</i> it, if nobody will ever be=
 able to <i>use</i> it without periodic consultation of a hex editor?</div>=
<div><br></div><div>As for defining new operators, the killer there seems t=
o be &quot;precedence.&quot; What should the precedence of <font face=3D"mo=
nospace, monospace">operator\u22C5</font> be? Should the precedence of <fon=
t face=3D"monospace, monospace">operator\u2227</font> be the same as that o=
f <font face=3D"monospace, monospace">operator&amp;&amp;</font>, or as that=
 of <font face=3D"monospace, monospace">operator&amp;</font>? Without a uni=
fied proposal covering this kind of question (in generic terms, not just fo=
r these two special cases), I don&#39;t think it makes sense to discuss any=
 specific cases.</div><div><br></div><div>For a really really good recent p=
aper covering new-operator issues, see Herb Sutter&#39;s <a href=3D"http://=
www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0515r0.pdf">P0515</a>. It=
 introduces <font face=3D"monospace, monospace">operator&lt;=3D&gt;</font> =
with a full discussion (page 11) of where the new operator will fit into th=
e precedence chart.</div><div><br></div><div>=E2=80=93Arthur</div></div></d=
iv></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/CADvuK0Lgrjaro93ic_R46Chkqn5mqWJKkB6c=
CuaU%3DptF4xzAbA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0Lgrjaro9=
3ic_R46Chkqn5mqWJKkB6cCuaU%3DptF4xzAbA%40mail.gmail.com</a>.<br />

--001a11443f862ee5e505494e4f0d--

.

------=_Part_425_840260981.1487983126431
Content-Type: multipart/alternative;
 boundary="----=_Part_426_1079013067.1487983126431"

------=_Part_426_1079013067.1487983126431
Content-Type: text/plain; charset=UTF-8

The DOT OPERATOR
<http://www.fileformat.info/info/unicode/char/22c5/index.htm> seems indeed
more suited. But then how do we type the correct character from similar
looking ones, that's a good question.

I am going on vacation, I will think about it. I am just trying to find
something nice, I am not saying I have the best solution already.
Thank you for all the comments !

Godeffroy

--
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/5b4dbd06-3f26-4aae-9a55-4fbe8bcaf70d%40isocpp.org.

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

<div dir=3D"ltr">The <a href=3D"http://www.fileformat.info/info/unicode/cha=
r/22c5/index.htm" target=3D"_blank" rel=3D"nofollow">DOT OPERATOR</a> seems=
 indeed more suited. But then how do we type the correct character from sim=
ilar looking ones, that&#39;s a good question.<br><br>I am going on vacatio=
n, I will think about it. I am just trying to find something nice, I am not=
 saying I have the best solution already.<br>Thank you for all the comments=
 ! <br><br>Godeffroy<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/5b4dbd06-3f26-4aae-9a55-4fbe8bcaf70d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5b4dbd06-3f26-4aae-9a55-4fbe8bcaf70d=
%40isocpp.org</a>.<br />

------=_Part_426_1079013067.1487983126431--

------=_Part_425_840260981.1487983126431--

.

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

On Wed, Feb 22, 2017 at 8:49 PM, <godefv@gmail.com> wrote:

> == Problem ==
> Some math operators are missing from the standard.
>

The problem with this problem is that it cannot be fixed as stated.

The thing is, there is NO finite set of "math operators".

There are the well known four "high school" math operators, and that's it.
Everything else is pretty much domain specific, with quite weird notation
at times.

So no matter how many more operators you add *into the standard*, it can
always be said, hey, some math operators are missing from the standard!

You will have to reformulate your problem to make it tractable.

Personally, I am sceptical about any addition of a fixed set of operators,
and even more sceptical about user-defined operators. Single-character
operators are a great help in hand-written algebraic manipulations, that
much is true. But that is not how we write C++ code. For that, we normally
use keyboards, which have a fixed set of *single key press* characters, and
anything that is not in that set needs a keystroke. This is made worse by
the multitude of different "national" keyboard layouts, where those sets
are different, and still worse by the variation in the auxiliary keys that
are frequently parts of those keystrokes. None of the operators that you
proposed appear on any (modern) keyboard I know of, so it would actually be
more difficult to use them than "ordinary" operators, and probably more
difficult than using functions with reasonably short names. Add to this the
character encoding problems, and the far better readability and flexibility
afforded by functions.

Cheers,
V.

--
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/CAA7YVg2uVc8DkbKudLfxrog4NzL2a461SKM_8fBW80iWNZhWxw%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Feb 22, 2017 at 8:49 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:godef=
v@gmail.com" target=3D"_blank">godefv@gmail.com</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr">=3D=3D Problem =3D=3D<br>Some=
 math operators are missing from the standard.<br></div></blockquote><div><=
br></div><div>The problem with this problem is that it cannot be fixed as s=
tated.</div><div><br></div><div>The thing is, there is NO finite set of &qu=
ot;math operators&quot;.</div><div><br></div><div>There are the well known =
four &quot;high school&quot; math operators, and that&#39;s it. Everything =
else is pretty much domain specific, with quite weird notation at times.</d=
iv><div><br></div><div>So no matter how many more operators you add=C2=A0<i=
>into the standard</i>, it can always be said, hey, some math operators are=
 missing from the standard!</div><div><br></div><div>You will have to refor=
mulate your problem to make it tractable.</div><div><br></div><div>Personal=
ly, I am sceptical about any addition of a fixed set of operators, and even=
 more sceptical about user-defined operators. Single-character operators ar=
e a great help in hand-written algebraic manipulations, that much is true. =
But that is not how we write C++ code. For that, we normally use keyboards,=
 which have a fixed set of <i>single key press</i>=C2=A0characters, and any=
thing that is not in that set needs a keystroke. This is made worse by the =
multitude of different &quot;national&quot; keyboard layouts, where those s=
ets are different, and still worse by the variation in the auxiliary keys t=
hat are frequently parts of those keystrokes. None of the operators that yo=
u proposed appear on any (modern) keyboard I know of, so it would actually =
be more difficult to use them than &quot;ordinary&quot; operators, and prob=
ably more difficult than using functions with reasonably short names. Add t=
o this the character encoding problems, and the far better readability and =
flexibility afforded by functions.</div><div><br></div><div>Cheers,</div><d=
iv>V.</div></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/CAA7YVg2uVc8DkbKudLfxrog4NzL2a461SKM_=
8fBW80iWNZhWxw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2uVc8DkbKu=
dLfxrog4NzL2a461SKM_8fBW80iWNZhWxw%40mail.gmail.com</a>.<br />

--001a11489c762abed90549585fdc--

.

On 2017-02-24 23:32, Arthur O'Dwyer wrote:
> On Fri, Feb 24, 2017 at 1:58 PM, Thiago Macieira <thiago@macieira.org
> <mailto:thiago@macieira.org>> wrote:
>
>     On sexta-feira, 24 de fevereiro de 2017 11:07:42 PST Arthur O'Dwyer
>     wrote:
>     > The problem with your saying this is that now you're quietly shifti=
ng your
>     > goalposts from "the C++ standard should allow overloading of
>     > operator(middle-dot)" to "the C++ Standard should reclassify U+00B7=
 from
>     > 'identifier character' to 'punctuation character'"; and that's a
>     *crazy*
>     > different goal.
>
>     This is valid C++:
>
>       int paral=C2=B7lel =3D 0;    // Catalan
>       int =C2=B7 =3D 0;
>
>     But this isn't valid C++:
>
>       int =E2=8B=85 =3D 0;
>       int =E2=88=A7 =3D 0;
>
>
> Good call. For those without easy access to `od -t x1` or Python `print
> repr(...)` or whatever, the dot-looking things in the first example are
> the U+00B7 MIDDLE DOT that the OP was asking for; the dot-looking thing
> in the second example is U+22C5 DOT OPERATOR
> <http://www.fileformat.info/info/unicode/char/22c5/index.htm> which is
> "preferred to U+00B7
> <http://www.fileformat.info/info/unicode/char/00b7/index.htm> for
> denotation of multiplication" according to the Unicode comments field.
>

Interestingly, the dots are different in Thiago's original mail, but=20
look the same in the quoted part here.

Indicates that portability of the source code would be questionable, not=20
only for the poor EBCDIC users.



    Bo Persson





--=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/o8rqaf%24vbh%241%40blaine.gmane.org.

.

Em s=C3=A1bado, 25 de fevereiro de 2017, =C3=A0s 03:37:57 PST, Bo Persson e=
screveu:
> > int =C2=B7 =3D 0;
> >=20
> > But this isn't valid C++:
> >=20
> > int =E2=8B=85 =3D 0;

> Interestingly, the dots are different in Thiago's original mail, but
> look the same in the quoted part here.

They may *look* the same (they are homographs) but they are not the same, n=
ot=20
even in your email. The source of your email shows (UTF-8 encoding, quoted-
printable transfer encoding):

>       int =3DC2=3DB7 =3D3D 0;
>
>     But this isn't valid C++:
>
>       int =3DE2=3D8B=3D85 =3D3D 0;

--=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/1860166.65xQ725G03%40tjmaciei-mobl1.

.

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

On Sat, Feb 25, 2017 at 1:46 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> Em s=C3=A1bado, 25 de fevereiro de 2017, =C3=A0s 03:37:57 PST, Bo Persson=
 escreveu:
> > > int =C2=B7 =3D 0;
> > >
> > > But this isn't valid C++:
> > >
> > > int =E2=8B=85 =3D 0;
>
> > Interestingly, the dots are different in Thiago's original mail, but
> > look the same in the quoted part here.
>
> They may *look* the same (they are homographs) but they are not the same,
> not
> even in your email. The source of your email shows (UTF-8 encoding, quote=
d-
> printable transfer encoding):
>
>

Just to make the argument more rigorous though -- there are also lots of
homographs for the letter A:

A =CE=91 =D0=90 =E1=B4=80 =E1=B4=AC

Certainly we allow the letter A in identifiers, so the existence of
homographs is not in itself necessarily disqualifying. We may of course
wish to limit their proliferation.

--=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/CADbh%2BeTKqnkpRCZVYt-WkSRDy9o83qu1hqsKYQpShSeUL=
q%2B06g%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Feb 25, 2017 at 1:46 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span=
 class=3D"gmail-">Em s=C3=A1bado, 25 de fevereiro de 2017, =C3=A0s 03:37:57=
 PST, Bo Persson escreveu:<br>
&gt; &gt; int =C2=B7 =3D 0;<br>
&gt; &gt;<br>
&gt; &gt; But this isn&#39;t valid C++:<br>
&gt; &gt;<br>
&gt; &gt; int =E2=8B=85 =3D 0;<br>
<br>
</span><span class=3D"gmail-">&gt; Interestingly, the dots are different in=
 Thiago&#39;s original mail, but<br>
&gt; look the same in the quoted part here.<br>
<br>
</span>They may *look* the same (they are homographs) but they are not the =
same, not<br>
even in your email. The source of your email shows (UTF-8 encoding, quoted-=
<br>
printable transfer encoding):<br>
<br></blockquote><div><br></div><div><br></div><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><div>Just to make the argument more rigorous thou=
gh -- there are also lots of homographs for the letter A:</div><div>=C2=A0<=
/div></div>A =CE=91 =D0=90 =E1=B4=80 =E1=B4=AC<br></div><div class=3D"gmail=
_extra"><br></div><div>Certainly we allow the letter A in identifiers, so t=
he existence of homographs is not in itself necessarily disqualifying. We m=
ay of course wish to limit their proliferation.</div><div>=C2=A0</div></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/CADbh%2BeTKqnkpRCZVYt-WkSRDy9o83qu1hq=
sKYQpShSeULq%2B06g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeTKqn=
kpRCZVYt-WkSRDy9o83qu1hqsKYQpShSeULq%2B06g%40mail.gmail.com</a>.<br />

--94eb2c05eb344e5520054960fb7d--

.

On 2017-02-25 20:46, Thiago Macieira wrote:
> Em s=C3=A1bado, 25 de fevereiro de 2017, =C3=A0s 03:37:57 PST, Bo Persson=
 escreveu:
>>> int =C2=B7 =3D 0;
>>>
>>> But this isn't valid C++:
>>>
>>> int =E2=8B=85 =3D 0;
>
>> Interestingly, the dots are different in Thiago's original mail, but
>> look the same in the quoted part here.
>
> They may *look* the same (they are homographs) but they are not the same,=
 not
> even in your email. The source of your email shows (UTF-8 encoding, quote=
d-
> printable transfer encoding):
>
>>       int =3DC2=3DB7 =3D3D 0;
>>
>>     But this isn't valid C++:
>>
>>       int =3DE2=3D8B=3D85 =3D3D 0;
>

I don't know if this is an argument for or against the proposal, but as=20
my news reader doesn't want to show hex codes, I copied the text to=20
another program. There they both showed up as B7.


     Bo Persson


--=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/o8t49b%24gga%241%40blaine.gmane.org.

.

On 2017-02-26 00:34, Bo Persson wrote:
> On 2017-02-25 20:46, Thiago Macieira wrote:
>> Em s=C3=A1bado, 25 de fevereiro de 2017, =C3=A0s 03:37:57 PST, Bo Persso=
n escreveu:
>>>> int =C2=B7 =3D 0;
>>>>
>>>> But this isn't valid C++:
>>>>
>>>> int =E2=8B=85 =3D 0;
>>
>>> Interestingly, the dots are different in Thiago's original mail, but
>>> look the same in the quoted part here.
>>
>> They may *look* the same (they are homographs) but they are not the
>> same, not
>> even in your email. The source of your email shows (UTF-8 encoding,
>> quoted-
>> printable transfer encoding):
>>
>>>       int =3DC2=3DB7 =3D3D 0;
>>>
>>>     But this isn't valid C++:
>>>
>>>       int =3DE2=3D8B=3D85 =3D3D 0;
>>
>
> I don't know if this is an argument for or against the proposal, but as
> my news reader doesn't want to show hex codes, I copied the text to
> another program. There they both showed up as B7.
>
>

Oh, and when copy-pasting  the original message they did not.


     Bo Persson



--=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/o8t4dg%24gga%242%40blaine.gmane.org.

.

Em s=C3=A1bado, 25 de fevereiro de 2017, =C3=A0s 15:34:08 PST, Bo Persson e=
screveu:
> On 2017-02-25 20:46, Thiago Macieira wrote:
> > Em s=C3=A1bado, 25 de fevereiro de 2017, =C3=A0s 03:37:57 PST, Bo Perss=
on escreveu:
> >>> int =C2=B7 =3D 0;
> >>>=20
> >>> But this isn't valid C++:
> >>>=20
> >>> int =E2=8B=85 =3D 0;

> I don't know if this is an argument for or against the proposal, but as
> my news reader doesn't want to show hex codes, I copied the text to
> another program. There they both showed up as B7.

That's weird. U+00B7 is listed in "see also" for U+22C5, but it should neve=
r=20
have been normalised to it. Nothing in the Unicode data files call for it. =
So=20
the problem is in your MUA.

I'm glad we're not developing C++ in email clients.

Homography by itself is not a reason for the C++ committee to deny the use=
=20
requested by the OP. Like Brittany said, we already have quite a few=20
homographs of valid identifier letters that are allowed.

My email was to point out that U+00B7 that the OP asked for as dot-product=
=20
could not be used, since it's allowed by the C++ standard in identifiers=20
(probably so that Catalans can name their variables "paral=C2=B7lel" like=
=20
https://en.wikipedia.org/wiki/Avinguda_del_Paral%C2%B7lel ). Instead, the O=
P=20
would have to settle for the actual dot product symbol as requested by=20
Unicode, U+22C5, which is a mathematical symbol (Sm) and currently not allo=
wed=20
by the C++ standard in identifiers.

So, yes, it is possible to add more operators in the C++ language using=20
mathematical symbols from the Unicode reserved range. Whether that's a good=
=20
idea or not, I couldn't say.

--=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/1582114.YO2EXH4VTc%40tjmaciei-mobl1.

.

On 02/26/17 03:15, Thiago Macieira wrote:
> Em s=C3=A1bado, 25 de fevereiro de 2017, =C3=A0s 15:34:08 PST, Bo Persson=
 escreveu:
>> On 2017-02-25 20:46, Thiago Macieira wrote:
>>> Em s=C3=A1bado, 25 de fevereiro de 2017, =C3=A0s 03:37:57 PST, Bo Perss=
on escreveu:
>>>>> int =C2=B7 =3D 0;
>>>>>
>>>>> But this isn't valid C++:
>>>>>
>>>>> int =E2=8B=85 =3D 0;
>
>> I don't know if this is an argument for or against the proposal, but as
>> my news reader doesn't want to show hex codes, I copied the text to
>> another program. There they both showed up as B7.
>
> That's weird. U+00B7 is listed in "see also" for U+22C5, but it should ne=
ver
> have been normalised to it. Nothing in the Unicode data files call for it=
.. So
> the problem is in your MUA.
>
> I'm glad we're not developing C++ in email clients.
>
> Homography by itself is not a reason for the C++ committee to deny the us=
e
> requested by the OP.

I think on the contrary - it is a very good reason to prohibit such=20
characters in identifiers, keywords and operators. Anywhere where a=20
wrong character is able to subvert the program meaning, the character=20
should be clearly distinguishable from any other allowed character. If=20
this is not currently the case, I consider it a mistake.

--=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/ac336593-4659-30b9-9d93-1d93820e8379%40gmail.com=
..

.

Em domingo, 26 de fevereiro de 2017, =C3=A0s 04:14:08 PST, Andrey Semashev=
=20
escreveu:
> I think on the contrary - it is a very good reason to prohibit such
> characters in identifiers, keywords and operators. Anywhere where a
> wrong character is able to subvert the program meaning, the character
> should be clearly distinguishable from any other allowed character. If
> this is not currently the case, I consider it a mistake.

These four variables can already be declared at the same time:

int A =3D 1;
int =CE=91 =3D 2;
int =D0=90 =3D 3;
int =EF=BC=A1 =3D 4;

See https://godbolt.org/g/kynSrG
--=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/32354100.Gx1MVcFHWJ%40tjmaciei-mobl1.

.

------=_Part_821_264658639.1488196163515
Content-Type: multipart/alternative;
 boundary="----=_Part_822_1133847321.1488196163515"

------=_Part_822_1133847321.1488196163515
Content-Type: text/plain; charset=UTF-8



<https://raw.githubusercontent.com/henrahmagix/semicolon-troll/master/benjohnson-tweet.png>

--
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/932eaa6c-befe-4019-8c12-311a9f00a298%40isocpp.org.

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

<p class=3D"separator" style=3D"text-align: center; clear: both;"><a imagea=
nchor=3D"1" href=3D"https://raw.githubusercontent.com/henrahmagix/semicolon=
-troll/master/benjohnson-tweet.png" style=3D"margin-left: 1em; margin-right=
: 1em;"><img style=3D"" src=3D"https://raw.githubusercontent.com/henrahmagi=
x/semicolon-troll/master/benjohnson-tweet.png" height=3D"174" width=3D"320"=
 border=3D"0"></a></p><br>

<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/932eaa6c-befe-4019-8c12-311a9f00a298%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/932eaa6c-befe-4019-8c12-311a9f00a298=
%40isocpp.org</a>.<br />

------=_Part_822_1133847321.1488196163515--

------=_Part_821_264658639.1488196163515--

.