------=_Part_3248_1645552774.1543539826236
Content-Type: multipart/alternative;
 boundary="----=_Part_3249_569669352.1543539826236"

------=_Part_3249_569669352.1543539826236
Content-Type: text/plain; charset="UTF-8"

I would like to float an idea for handling operator overloading with
Parametric Expressions P1221R0/D1221
which has not been looked at by the committee yet. In that paper I made
some vague assertions about how
to handle operator overloading so I am considering a couple of options.

Note that there is no overloading or ADL with non-operator parametric
expressions. I would like to keep it
that way, but operator overloading is a bit different.


*OPTION #1*
In the set of overload candidates, what if a viable parametric expression
was always preferred over normal
candidates? Since parametric expression recursion is not allowed, it would
not be viable within its own
definition so it would be allowed to call the operator again where the
parametric expression is not
considered.

Allowing it to server as a wrapper in this way could provide a couple of
possibilities for users:


   -   Transform or lift values before calling overloaded operator that
   might include ADL candidates
   -   Control evaluation of inputs before calling overloaded operator that
   might include ADL candidates
   -   Bypass ADL entirely (which is useful since operators are typically
   unqualified)


*OPTION #2*

Always prefer viable function candidates over parametric expressions - the
story ends, you wake up in your
bed and believe whatever you want to believe.

Your consideration and feedback is greatly appreciated.


Thanks,
Jason Rice

--
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/9b3ff05d-47d0-44a7-a4c4-0415dbc3b966%40isocpp.org.

------=_Part_3249_569669352.1543539826236
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I would like to float an idea for handling operator overlo=
ading with Parametric Expressions P1221R0/D1221<br>which has not been looke=
d at by the committee yet. In that paper I made some vague assertions about=
 how<br>to handle operator overloading so I am considering a couple of opti=
ons.<br><br>Note that there is no overloading or ADL with non-operator para=
metric expressions. I would like to keep it<br>that way, but operator overl=
oading is a bit different.<br><br><b>OPTION #1<br></b><br>In the set of ove=
rload candidates, what if a viable parametric expression was always preferr=
ed over normal<br>candidates? Since parametric expression recursion is not =
allowed, it would not be viable within its own=C2=A0 <br>definition so it w=
ould be allowed to call the operator again where the parametric expression =
is not<br>considered.<br><br>Allowing it to server as a wrapper in this way=
 could provide a couple of possibilities for users:<br><br><ul><li>=C2=A0 T=
ransform or lift values before calling overloaded operator that might inclu=
de ADL candidates</li><li>=C2=A0 Control evaluation of inputs before callin=
g overloaded operator that might include ADL candidates</li><li>=C2=A0 Bypa=
ss ADL entirely (which is useful since operators are typically unqualified)=
</li></ul><br><b>OPTION #2</b><br><br>Always prefer viable function candida=
tes over parametric expressions - the story ends, you wake up in your<br>be=
d and believe whatever you want to believe.<br><br>Your consideration and f=
eedback is greatly appreciated.<br><br><br>Thanks,<br>Jason Rice<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/9b3ff05d-47d0-44a7-a4c4-0415dbc3b966%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9b3ff05d-47d0-44a7-a4c4-0415dbc3b966=
%40isocpp.org</a>.<br />

------=_Part_3249_569669352.1543539826236--

------=_Part_3248_1645552774.1543539826236--

.