Topic: d1193 (Unpublished) - Explicit Return Types for


Author: The PhD <phdofthehouse@gmail.com>
Date: Sat, 24 Nov 2018 23:23:10 -0800 (PST)
Raw View
------=_Part_903_1419789467.1543130590951
Content-Type: multipart/alternative;
 boundary="----=_Part_904_420961593.1543130590952"

------=_Part_904_420961593.1543130590952
Content-Type: text/plain; charset="UTF-8"

Dear Future Proposals,

     This is a proposal I have been working on for quite some time. It was
the first proposal I wanted to write before I got swamped with std::embed
and everything else I've been working on. It is called "Explicit Return
Types for (Implicit) Conversions", and will appear in the post-San Diego
mailing: https://thephd.github.io/vendor/future_cxx/papers/d1193.html. The
goal of this paper was to provide an opt-in way to add return types for
conversions, which allow a user to override the compiler's current and
default behavior. Because it is an opt-in feature, it has no impact on any
code unless a conversion is explicitly and deliberately changed to use it.
For example:

struct S {
     operator int () const { return 0; }
};

This code will continue to be well-formed and its meaning does not change.
It can only change if you add something that is currently ill-formed in C++
syntax today: a return type before the "operator" keyword. This means that
code from C++11, C++14, C++17, etc. goes completely unchanged. Nothing
actually changes until someone explicitly opts-in with the return type:

struct S {
     double operator int () const { return 0.0; }
};

The goal of this proposal is to allow better control for proxy, expression
template, and intermediary convertible types in C++. Particularly, they are
to make working with weird types like std::tie's tuples better and allow
for a richer class of reference deduction and return value response for
omni-convertible proxies which mimic return-type polymorphism.

     Please let me know what you think of the proposal, especially its
current wording.

Thank You,
JeanHeyd

--
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/331d08dc-54ad-4681-abe8-986b66bf354a%40isocpp.org.

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

<div dir=3D"ltr">Dear Future Proposals,<br><br>=C2=A0=C2=A0=C2=A0=C2=A0 Thi=
s is a proposal I have been working on for quite some time. It was the firs=
t proposal I wanted to write before I got swamped with std::embed and every=
thing else I&#39;ve been working on. It is called &quot;Explicit Return Typ=
es for (Implicit) Conversions&quot;, and will appear in the post-San Diego =
mailing: <a href=3D"https://thephd.github.io/vendor/future_cxx/papers/d1193=
..html">https://thephd.github.io/vendor/future_cxx/papers/d1193.html</a>. Th=
e goal of this paper was to provide an opt-in way to add return types for c=
onversions, which allow a user to override the compiler&#39;s current and d=
efault behavior. Because it is an opt-in feature, it has no impact on any c=
ode unless a conversion is explicitly and deliberately changed to use it. F=
or example:<br><div><br><div style=3D"background-color: rgb(250, 250, 250);=
 border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; =
overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprin=
t"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">struct</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> S </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">operator</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">i=
nt</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">return</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span></div></code></div><br>This code will conti=
nue to be well-formed and its meaning does not change. It can only change i=
f you add something that is currently ill-formed in C++ syntax today: a ret=
urn type before the &quot;operator&quot; keyword. This means that code from=
 C++11, C++14, C++17, etc. goes completely unchanged. Nothing actually chan=
ges until someone explicitly opts-in with the return type:<br><br><div styl=
e=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187)=
; border-style: solid; border-width: 1px; overflow-wrap: break-word;" class=
=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> S </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">double</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">operator</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">const=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" clas=
s=3D"styled-by-prettify">0.0</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span></div>=
</code></div><br>The goal of this proposal is to allow better control for p=
roxy, expression template, and intermediary convertible types in C++. Parti=
cularly, they are to make working with weird types like std::tie&#39;s tupl=
es better and allow for a richer class of reference deduction and return va=
lue response for omni-convertible proxies which mimic return-type polymorph=
ism.<br><br>=C2=A0=C2=A0=C2=A0=C2=A0 Please let me know what you think of t=
he proposal, especially its current wording.<br><br>Thank You,<br>JeanHeyd<=
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/331d08dc-54ad-4681-abe8-986b66bf354a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/331d08dc-54ad-4681-abe8-986b66bf354a=
%40isocpp.org</a>.<br />

------=_Part_904_420961593.1543130590952--

------=_Part_903_1419789467.1543130590951--

.


Author: mihailnajdenov@gmail.com
Date: Sun, 25 Nov 2018 06:13:18 -0800 (PST)
Raw View
------=_Part_942_1053870082.1543155199023
Content-Type: multipart/alternative;
 boundary="----=_Part_943_1952283235.1543155199024"

------=_Part_943_1952283235.1543155199024
Content-Type: text/plain; charset="UTF-8"

Hello

I would prefer more concrete examples - what problems are solved. You might
add some real word cases from sol2 and what not
You also should consider adding comments of what the code does behind the
scenes - how the conversions are picked/chained

About the core of the proposal.

It is not completely clear to me what conversions are allowed. At one hand
you say that one custom conversion rules is not changed, on the other you
say
"// ... return anything"
So, the return type can only do what conversions exactly, assuming one
custom conversion is already consumed by the operator.

Will the expected type be able to be convert-*construct* from the returned
type?



On Sunday, November 25, 2018 at 9:23:11 AM UTC+2, The PhD wrote:
>
> Dear Future Proposals,
>
>      This is a proposal I have been working on for quite some time. It was
> the first proposal I wanted to write before I got swamped with std::embed
> and everything else I've been working on. It is called "Explicit Return
> Types for (Implicit) Conversions", and will appear in the post-San Diego
> mailing: https://thephd.github.io/vendor/future_cxx/papers/d1193.html.
> The goal of this paper was to provide an opt-in way to add return types for
> conversions, which allow a user to override the compiler's current and
> default behavior. Because it is an opt-in feature, it has no impact on any
> code unless a conversion is explicitly and deliberately changed to use it.
> For example:
>
> struct S {
>      operator int () const { return 0; }
> };
>
> This code will continue to be well-formed and its meaning does not change.
> It can only change if you add something that is currently ill-formed in C++
> syntax today: a return type before the "operator" keyword. This means that
> code from C++11, C++14, C++17, etc. goes completely unchanged. Nothing
> actually changes until someone explicitly opts-in with the return type:
>
> struct S {
>      double operator int () const { return 0.0; }
> };
>
> The goal of this proposal is to allow better control for proxy, expression
> template, and intermediary convertible types in C++. Particularly, they are
> to make working with weird types like std::tie's tuples better and allow
> for a richer class of reference deduction and return value response for
> omni-convertible proxies which mimic return-type polymorphism.
>
>      Please let me know what you think of the proposal, especially its
> current wording.
>
> Thank You,
> JeanHeyd
>

--
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/a8e37916-8da3-4ff7-a117-1856e6f1a458%40isocpp.org.

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

<div dir=3D"ltr">Hello<div><br></div><div>I would prefer more concrete exam=
ples - what problems are solved. You might add some real word cases from so=
l2 and what not</div><div>You also should consider adding comments of what =
the code does behind the scenes - how the conversions are picked/chained</d=
iv><div><br></div><div><div>About the core of the proposal.=C2=A0</div><div=
><br></div><div>It is not completely clear to me what conversions are allow=
ed. At one hand you say that one custom conversion rules is not changed, on=
 the other you say=C2=A0</div><div>&quot;// ... return anything&quot;</div>=
So, the return type can only do what conversions exactly, assuming one cust=
om conversion is already consumed by the operator.</div><div><br>Will the e=
xpected type be able to be convert-<i>construct</i> from the returned type?=
=C2=A0</div><div><br></div><div><br><div><br>On Sunday, November 25, 2018 a=
t 9:23:11 AM UTC+2, The PhD 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">Dear Future Proposals,<br><br>=C2=A0=C2=A0=C2=A0=C2=
=A0 This is a proposal I have been working on for quite some time. It was t=
he first proposal I wanted to write before I got swamped with std::embed an=
d everything else I&#39;ve been working on. It is called &quot;Explicit Ret=
urn Types for (Implicit) Conversions&quot;, and will appear in the post-San=
 Diego mailing: <a href=3D"https://thephd.github.io/vendor/future_cxx/paper=
s/d1193.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fthephd.github.io%2Fve=
ndor%2Ffuture_cxx%2Fpapers%2Fd1193.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dA=
FQjCNEqMrFZuIHp-jtmXBKdAUI7JvRfzQ&#39;;return true;" onclick=3D"this.href=
=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fthephd.github.io%2Fve=
ndor%2Ffuture_cxx%2Fpapers%2Fd1193.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dA=
FQjCNEqMrFZuIHp-jtmXBKdAUI7JvRfzQ&#39;;return true;">https://thephd.github.=
io/<wbr>vendor/future_cxx/papers/<wbr>d1193.html</a>. The goal of this pape=
r was to provide an opt-in way to add return types for conversions, which a=
llow a user to override the compiler&#39;s current and default behavior. Be=
cause it is an opt-in feature, it has no impact on any code unless a conver=
sion is explicitly and deliberately changed to use it. For example:<br><div=
><br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,1=
87,187);border-style:solid;border-width:1px"><code><div><span style=3D"colo=
r:#008">struct</span><span style=3D"color:#000"> S </span><span style=3D"co=
lor:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0</span=
><span style=3D"color:#008">operator</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#008">int</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#660">()</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#008">const</span><span style=3D"color:#000"> </span><span=
 style=3D"color:#660">{</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#008">return</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#066">0</span><span style=3D"color:#660">;</span><span style=3D"=
color:#000"> </span><span style=3D"color:#660">}</span><span style=3D"color=
:#000"><br></span><span style=3D"color:#660">};</span><span style=3D"color:=
#000"><br></span></div></code></div><br>This code will continue to be well-=
formed and its meaning does not change. It can only change if you add somet=
hing that is currently ill-formed in C++ syntax today: a return type before=
 the &quot;operator&quot; keyword. This means that code from C++11, C++14, =
C++17, etc. goes completely unchanged. Nothing actually changes until someo=
ne explicitly opts-in with the return type:<br><br><div style=3D"background=
-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;bo=
rder-width:1px"><code><div><span style=3D"color:#008">struct</span><span st=
yle=3D"color:#000"> S </span><span style=3D"color:#660">{</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0</span><span style=3D"color:#008">d=
ouble</span><span style=3D"color:#000"> </span><span style=3D"color:#008">o=
perator</span><span style=3D"color:#000"> </span><span style=3D"color:#008"=
>int</span><span style=3D"color:#000"> </span><span style=3D"color:#660">()=
</span><span style=3D"color:#000"> </span><span style=3D"color:#008">const<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">{</span=
><span style=3D"color:#000"> </span><span style=3D"color:#008">return</span=
><span style=3D"color:#000"> </span><span style=3D"color:#066">0.0</span><s=
pan style=3D"color:#660">;</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#660">}</span><span style=3D"color:#000"><br></span><span sty=
le=3D"color:#660">};</span></div></code></div><br>The goal of this proposal=
 is to allow better control for proxy, expression template, and intermediar=
y convertible types in C++. Particularly, they are to make working with wei=
rd types like std::tie&#39;s tuples better and allow for a richer class of =
reference deduction and return value response for omni-convertible proxies =
which mimic return-type polymorphism.<br><br>=C2=A0=C2=A0=C2=A0=C2=A0 Pleas=
e let me know what you think of the proposal, especially its current wordin=
g.<br><br>Thank You,<br>JeanHeyd<br></div></div></blockquote></div></div></=
div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a8e37916-8da3-4ff7-a117-1856e6f1a458%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a8e37916-8da3-4ff7-a117-1856e6f1a458=
%40isocpp.org</a>.<br />

------=_Part_943_1952283235.1543155199024--

------=_Part_942_1053870082.1543155199023--

.


Author: Balog Pal <pasa@lib.hu>
Date: Sun, 25 Nov 2018 16:57:50 -0800 (PST)
Raw View
------=_Part_958_1090464217.1543193870518
Content-Type: multipart/alternative;
 boundary="----=_Part_959_1283112269.1543193870518"

------=_Part_959_1283112269.1543193870518
Content-Type: text/plain; charset="UTF-8"

Yes, provide examples of actual use and some problem case that it actually
solves.

The example you did write is more than confusing to think about. That
operator triggers where context wants int and I provided S. So then what
happens: operator int is invoked, it returns a double that is in turn
converted to int. Wow. Why that there and back conversion is good?

If the intent is to return some int_proxy instance, that has an operator
int itself, then it might make sense, but it is 2 user-defined conversions
that would not work with current rules, how you intend to cover that
without impact on existing code?

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

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

<div dir=3D"ltr"><div>Yes, provide examples of actual use and some problem =
case that it actually solves.</div><div><br></div><div>The example you did =
write is more than confusing to think about. That operator triggers where c=
ontext wants int and I provided S. So then what happens: operator int is in=
voked, it returns a double that is in turn converted to int. Wow. Why that =
there and back conversion is good?</div><div><br></div><div>If the intent i=
s to return some int_proxy instance, that has an operator int itself, then =
it might make sense, but it is 2 user-defined conversions that would not wo=
rk with current rules, how you intend to cover that without impact on exist=
ing code?<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/6d5ed13d-c31a-4218-88b0-e0dd4bef3f72%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6d5ed13d-c31a-4218-88b0-e0dd4bef3f72=
%40isocpp.org</a>.<br />

------=_Part_959_1283112269.1543193870518--

------=_Part_958_1090464217.1543193870518--

.


Author: The PhD <phdofthehouse@gmail.com>
Date: Sun, 25 Nov 2018 19:08:56 -0800 (PST)
Raw View
------=_Part_997_919856269.1543201736600
Content-Type: multipart/alternative;
 boundary="----=_Part_998_153927326.1543201736601"

------=_Part_998_153927326.1543201736601
Content-Type: text/plain; charset="UTF-8"

The paper provides 2 in-depth use cases where this actually applies and
explains the feature in full; the code left here was just a sample of the
change in syntax, not the problems it solves. There is a 2-part full
motivation section, but the Tony Table also covers some as well.

To go into depth:
struct S {
     double operator int () const { return 0.0; }
};

Let us take this structure. It's a proxy for the return type out of some
complex system -- say, Javascript or Lua -- where the only numbers inside
of the VM (for Lua 5.2 and below or for Javascript) are doubles.

Without the return type, we are not allowed to communicate this limitation
to the user: if they ask for an integer out of our proxy, we must hand them
an integer. For the struct S, this is not a problem because it only has a
singular return type. But in more complicated pieces of code where proxies
and return type polymorphism lets you convert to multiple things (or you
pick a templated operator to cover all of the use cases), you have to do
one of two things:

- Always convert to (int) and if it happens to fall outside of that, pray
the `static_cast` or c-style cast you applied does the right thing
- Incur a performance hit when someone asks for an integer and do bounds
checking on the value of the double to ensure it is, indeed, an integer

This is, in fact, exactly how sol2 handles it:
https://github.com/ThePhD/sol2/blob/develop/sol/stack_check_get_unqualified.hpp#L83

It would be better if, when being asked for an integer, the library author
could return a double and let the warning pop up for the user. Now, instead
of the library picking for them or adding several different macro-based
modes to handle various different kinds of states and potential errors (or
not), the user now loudly given a warning about a lossy conversion (on, for
example, VC++) and they can now make an informed decision about what they
want without requiring the library author to engage in obscene, unreadable
and hard-to-understand SFINAE for what is a very simple task:
https://github.com/ThePhD/sol2/blob/develop/sol/proxy_base.hpp#L41

As I stated in the paper, there is no confusion about the selection: the
compiler selects the overload that is most appropriate based on the type
argument (e.g., when picking a constructor as in
http://eel.is/c++draft/class.conv#ctor). This is no different from today:
the return type never factors into the selection of such a function (and
never factors into regular overload resolution either). If it matches
perfectly, that is fine (and you wouldn't be using the extension). If it is
something that is only convertible and requires a constructor call, that is
fine. If it is an error, that is also fine: now the library is not in
charge of making an executive decision of hiding what could very well be a
logic error on the part of the user (as demonstrated with the case of
working with an internal system).

Furthermore, chaining is already impossible in today's current system. This
proposal does not change that: only built-in types are allowed to perform
multiple conversions (this is where the Safe Bool Idiom of returning some
bogus member-function-pointer type came from). You may only perform 1
conversion with user-defined types, as stated in the standard (
http://eel.is/c++draft/class.conv#4).

Are there any other concerns?

--
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/55f4ba50-6b86-4f65-858a-754c347cdeb9%40isocpp.org.

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

<div dir=3D"ltr">The paper provides 2 in-depth use cases where this actuall=
y applies and explains the feature in full; the code left here was just a s=
ample of the change in syntax, not the problems it solves. There is a 2-par=
t full motivation section, but the Tony Table also covers some as well.<br>=
<br><div>To go into depth:<br><div style=3D"background-color:rgb(250,250,25=
0);border-color:rgb(187,187,187);border-style:solid;border-width:1px"><code=
><div><span style=3D"color:#008">struct</span><span style=3D"color:#000"> S=
 </span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=
=C2=A0 =C2=A0 =C2=A0</span><span style=3D"color:#008">double</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#008">operator</span><span =
style=3D"color:#000"> </span><span style=3D"color:#008">int</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#660">()</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">const</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#008">return</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#066">0.0</span><span style=3D"colo=
r:#660">;</span><span style=3D"color:#000"> </span><span style=3D"color:#66=
0">}</span><span style=3D"color:#000"><br></span><span style=3D"color:#660"=
>};</span></div></code></div></div><div><br></div><div>Let us take this str=
ucture. It&#39;s a proxy for the return type out of some complex system -- =
say, Javascript or Lua -- where the only numbers inside of the VM (for Lua =
5.2 and below or for Javascript) are doubles.<br><br>Without the return typ=
e, we are not allowed to communicate this limitation to the user: if they a=
sk for an integer out of our proxy, we must hand them an integer. For the s=
truct S, this is not a problem because it only has a singular return type. =
But in more complicated pieces of code where proxies and return type polymo=
rphism lets you convert to multiple things (or you pick a templated operato=
r to cover all of the use cases), you have to do one of two things:<br><br>=
- Always convert to (int) and if it happens to fall outside of that, pray t=
he `static_cast` or c-style cast you applied does the right thing<br>- Incu=
r a performance hit when someone asks for an integer and do bounds checking=
 on the value of the double to ensure it is, indeed, an integer<br><br>This=
 is, in fact, exactly how sol2 handles it: <a href=3D"https://github.com/Th=
ePhD/sol2/blob/develop/sol/stack_check_get_unqualified.hpp#L83">https://git=
hub.com/ThePhD/sol2/blob/develop/sol/stack_check_get_unqualified.hpp#L83</a=
></div><div><br></div><div>It would be better if, when being asked for an i=
nteger, the library author could return a double and let the warning pop up=
 for the user. Now, instead of the library picking for them or adding sever=
al different macro-based modes to handle various different kinds of states =
and potential errors (or not), the user now loudly given a warning about a =
lossy conversion (on, for example, VC++) and they can now make an informed =
decision about what they want without requiring the library author to engag=
e in obscene, unreadable and hard-to-understand SFINAE for what is a very s=
imple task: <a href=3D"https://github.com/ThePhD/sol2/blob/develop/sol/prox=
y_base.hpp#L41">https://github.com/ThePhD/sol2/blob/develop/sol/proxy_base.=
hpp#L41</a></div><div><br></div><div>As I stated in the paper, there is no =
confusion about the selection: the compiler selects the overload that is mo=
st appropriate based on the type argument (e.g., when picking a constructor=
 as in <a href=3D"http://eel.is/c++draft/class.conv#ctor">http://eel.is/c++=
draft/class.conv#ctor</a>). This is no different from today: the return typ=
e never factors into the selection of such a function (and never factors in=
to regular overload resolution either). If it matches perfectly, that is fi=
ne (and you wouldn&#39;t be using the extension). If it is something that i=
s only convertible and requires a constructor call, that is fine. If it is =
an error, that is also fine: now the library is not in charge of making an =
executive decision of hiding what could very well be a logic error on the p=
art of the user (as demonstrated with the case of working with an internal =
system).<br><br>Furthermore, chaining is already impossible in today&#39;s =
current system. This proposal does not change that: only built-in types are=
 allowed to perform multiple conversions (this is where the Safe Bool Idiom=
 of returning some bogus member-function-pointer type came from). You may o=
nly perform 1 conversion with user-defined types, as stated in the standard=
 (<a href=3D"http://eel.is/c++draft/class.conv#4">http://eel.is/c++draft/cl=
ass.conv#4</a>).<br><br>Are there any other concerns?<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/55f4ba50-6b86-4f65-858a-754c347cdeb9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/55f4ba50-6b86-4f65-858a-754c347cdeb9=
%40isocpp.org</a>.<br />

------=_Part_998_153927326.1543201736601--

------=_Part_997_919856269.1543201736600--

.


Author: mihailnajdenov@gmail.com
Date: Sun, 25 Nov 2018 23:50:59 -0800 (PST)
Raw View
------=_Part_1087_1518601261.1543218659647
Content-Type: multipart/alternative;
 boundary="----=_Part_1088_569432378.1543218659648"

------=_Part_1088_569432378.1543218659648
Content-Type: text/plain; charset="UTF-8"



On Monday, November 26, 2018 at 5:08:56 AM UTC+2, The PhD wrote:
>
> The paper provides 2 in-depth use cases where this actually applies and
> explains the feature in full; the code left here was just a sample of the
> change in syntax, not the problems it solves. There is a 2-part full
> motivation section, but the Tony Table also covers some as well.
>

I believe the people commenting have read the paper and the lack of good,
real word examples apply to it.
The comparison table should have some nightmare code we have today on the
left (or some dream code we dream to have) and haven-send code on the right.
The examples examples are more "this is how it would work", but they don't
show us why, they don't show the power of the feature.


>
> To go into depth:
> struct S {
>      double operator int () const { return 0.0; }
> };
>
> Let us take this structure. It's a proxy for the return type out of some
> complex system -- say, Javascript or Lua -- where the only numbers inside
> of the VM (for Lua 5.2 and below or for Javascript) are doubles.
>
> Without the return type, we are not allowed to communicate this limitation
> to the user: if they ask for an integer out of our proxy, we must hand them
> an integer. For the struct S, this is not a problem because it only has a
> singular return type. But in more complicated pieces of code where proxies
> and return type polymorphism lets you convert to multiple things (or you
> pick a templated operator to cover all of the use cases), you have to do
> one of two things:
>

> - Always convert to (int) and if it happens to fall outside of that, pray
> the `static_cast` or c-style cast you applied does the right thing
> - Incur a performance hit when someone asks for an integer and do bounds
> checking on the value of the double to ensure it is, indeed, an integer
>
> This is, in fact, exactly how sol2 handles it:
> https://github.com/ThePhD/sol2/blob/develop/sol/stack_check_get_unqualified.hpp#L83
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FThePhD%2Fsol2%2Fblob%2Fdevelop%2Fsol%2Fstack_check_get_unqualified.hpp%23L83&sa=D&sntz=1&usg=AFQjCNHAlzVZFB975tws_lO4nWx1zA3bbg>
>
> It would be better if, when being asked for an integer, the library author
> could return a double and let the warning pop up for the user. Now, instead
> of the library picking for them or adding several different macro-based
> modes to handle various different kinds of states and potential errors (or
> not), the user now loudly given a warning about a lossy conversion (on, for
> example, VC++) and they can now make an informed decision about what they
> want without requiring the library author to engage in obscene, unreadable
> and hard-to-understand SFINAE for what is a very simple task:
> https://github.com/ThePhD/sol2/blob/develop/sol/proxy_base.hpp#L41
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FThePhD%2Fsol2%2Fblob%2Fdevelop%2Fsol%2Fproxy_base.hpp%23L41&sa=D&sntz=1&usg=AFQjCNF9izMo_G4qXWTVSRPBHjmCTFlW9w>
>
>
Yeah, a simplified version of these examples is what people expect to see
in the paper.



> As I stated in the paper, there is no confusion about the selection: the
> compiler selects the overload that is most appropriate based on the type
> argument (e.g., when picking a constructor as in
> http://eel.is/c++draft/class.conv#ctor). This is no different from today:
> the return type never factors into the selection of such a function (and
> never factors into regular overload resolution either). If it matches
> perfectly, that is fine (and you wouldn't be using the extension). If it is
> something that is only convertible and requires a constructor call, that is
> fine.
>

Considering, that this is not possible today:

struct B{ B(int) {} };

struct C
{
    operator int() { return {}; }
};

void f(B i) {}


int main()
{
  f(C());
}

Will this be possible with your proposal, not the exact example, but do you
count converting constructor on the return type as user conversion?

You say it is fine if it requires a construction call, thats why I am
asking.



If it is an error, that is also fine: now the library is not in charge of
> making an executive decision of hiding what could very well be a logic
> error on the part of the user (as demonstrated with the case of working
> with an internal system).
>
> Furthermore, chaining is already impossible in today's current system.
> This proposal does not change that: only built-in types are allowed to
> perform multiple conversions (this is where the Safe Bool Idiom of
> returning some bogus member-function-pointer type came from). You may only
> perform 1 conversion with user-defined types, as stated in the standard (
> http://eel.is/c++draft/class.conv#4).
>
> Are there any other concerns?
>

--
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/7a2b095b-b02e-4e00-a077-fe33948353a2%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Monday, November 26, 2018 at 5:08:56 AM UTC+2, =
The PhD wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>The paper provides 2 in-depth use cases where this actually applies and ex=
plains the feature in full; the code left here was just a sample of the cha=
nge in syntax, not the problems it solves. There is a 2-part full motivatio=
n section, but the Tony Table also covers some as well.<br></div></blockquo=
te><div><br></div><div>I believe the people commenting have read the paper =
and the lack of good, real word examples apply to it.=C2=A0</div><div>The c=
omparison table should have some nightmare code we have today on the left (=
or some dream code we dream to have) and haven-send code on the right.</div=
><div>The examples examples are more &quot;this is how it would work&quot;,=
 but they don&#39;t show us why, they don&#39;t show the power of the featu=
re.</div><div>=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"><br><div>To go into depth:<br><div style=3D"background-color:r=
gb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-wid=
th:1px"><code><div><span style=3D"color:#008">struct</span><span style=3D"c=
olor:#000"> S </span><span style=3D"color:#660">{</span><span style=3D"colo=
r:#000"><br>=C2=A0 =C2=A0 =C2=A0</span><span style=3D"color:#008">double</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#008">operator<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#008">int</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#660">()</span><=
span style=3D"color:#000"> </span><span style=3D"color:#008">const</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#660">{</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#008">return</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#066">0.0</span><span styl=
e=3D"color:#660">;</span><span style=3D"color:#000"> </span><span style=3D"=
color:#660">}</span><span style=3D"color:#000"><br></span><span style=3D"co=
lor:#660">};</span></div></code></div></div><div><br></div><div>Let us take=
 this structure. It&#39;s a proxy for the return type out of some complex s=
ystem -- say, Javascript or Lua -- where the only numbers inside of the VM =
(for Lua 5.2 and below or for Javascript) are doubles.<br><br>Without the r=
eturn type, we are not allowed to communicate this limitation to the user: =
if they ask for an integer out of our proxy, we must hand them an integer. =
For the struct S, this is not a problem because it only has a singular retu=
rn type. But in more complicated pieces of code where proxies and return ty=
pe polymorphism lets you convert to multiple things (or you pick a template=
d operator to cover all of the use cases), you have to do one of two things=
:</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>- Always convert to (int) and if it happens to fall o=
utside of that, pray the `static_cast` or c-style cast you applied does the=
 right thing<br>- Incur a performance hit when someone asks for an integer =
and do bounds checking on the value of the double to ensure it is, indeed, =
an integer<br><br>This is, in fact, exactly how sol2 handles it: <a href=3D=
"https://www.google.com/url?q=3Dhttps%3A%2F%2Fgithub.com%2FThePhD%2Fsol2%2F=
blob%2Fdevelop%2Fsol%2Fstack_check_get_unqualified.hpp%23L83&amp;sa=3DD&amp=
;sntz=3D1&amp;usg=3DAFQjCNHAlzVZFB975tws_lO4nWx1zA3bbg" target=3D"_blank" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?=
q\x3dhttps%3A%2F%2Fgithub.com%2FThePhD%2Fsol2%2Fblob%2Fdevelop%2Fsol%2Fstac=
k_check_get_unqualified.hpp%23L83\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
AlzVZFB975tws_lO4nWx1zA3bbg&#39;;return true;" onclick=3D"this.href=3D&#39;=
https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FThePhD%2Fsol2%2F=
blob%2Fdevelop%2Fsol%2Fstack_check_get_unqualified.hpp%23L83\x26sa\x3dD\x26=
sntz\x3d1\x26usg\x3dAFQjCNHAlzVZFB975tws_lO4nWx1zA3bbg&#39;;return true;">h=
ttps://github.com/ThePhD/<wbr>sol2/blob/develop/sol/stack_<wbr>check_get_un=
qualified.hpp#L83</a></div><div><br></div><div>It would be better if, when =
being asked for an integer, the library author could return a double and le=
t the warning pop up for the user. Now, instead of the library picking for =
them or adding several different macro-based modes to handle various differ=
ent kinds of states and potential errors (or not), the user now loudly give=
n a warning about a lossy conversion (on, for example, VC++) and they can n=
ow make an informed decision about what they want without requiring the lib=
rary author to engage in obscene, unreadable and hard-to-understand SFINAE =
for what is a very simple task: <a href=3D"https://www.google.com/url?q=3Dh=
ttps%3A%2F%2Fgithub.com%2FThePhD%2Fsol2%2Fblob%2Fdevelop%2Fsol%2Fproxy_base=
..hpp%23L41&amp;sa=3DD&amp;sntz=3D1&amp;usg=3DAFQjCNF9izMo_G4qXWTVSRPBHjmCTF=
lW9w" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ht=
tps://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FThePhD%2Fsol2%2Fbl=
ob%2Fdevelop%2Fsol%2Fproxy_base.hpp%23L41\x26sa\x3dD\x26sntz\x3d1\x26usg\x3=
dAFQjCNF9izMo_G4qXWTVSRPBHjmCTFlW9w&#39;;return true;" onclick=3D"this.href=
=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FThePhD%2=
Fsol2%2Fblob%2Fdevelop%2Fsol%2Fproxy_base.hpp%23L41\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNF9izMo_G4qXWTVSRPBHjmCTFlW9w&#39;;return true;">https://gi=
thub.com/ThePhD/<wbr>sol2/blob/develop/sol/proxy_<wbr>base.hpp#L41</a></div=
><div><br></div></div></blockquote><div><br></div><div>Yeah, a simplified v=
ersion of these examples is what people expect to see in the paper.</div><d=
iv><br></div><div>=C2=A0</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><div>As I stated in the paper, there is no conf=
usion about the selection: the compiler selects the overload that is most a=
ppropriate based on the type argument (e.g., when picking a constructor as =
in <a href=3D"http://eel.is/c++draft/class.conv#ctor" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x=
3dhttp%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fclass.conv%23ctor\x26sa\x3dD\x26sntz=
\x3d1\x26usg\x3dAFQjCNElLyka0YQm-rkF5aUbH1UcJGt_vA&#39;;return true;" oncli=
ck=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Feel.is%2=
Fc%2B%2Bdraft%2Fclass.conv%23ctor\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE=
lLyka0YQm-rkF5aUbH1UcJGt_vA&#39;;return true;">http://eel.is/c++draft/class=
..<wbr>conv#ctor</a>). This is no different from today: the return type neve=
r factors into the selection of such a function (and never factors into reg=
ular overload resolution either). If it matches perfectly, that is fine (an=
d you wouldn&#39;t be using the extension). If it is something that is only=
 convertible and requires a constructor call, that is fine. </div></div></b=
lockquote><div><br></div><div>Considering, that this is not possible today:=
</div><div><br></div><div><div><font face=3D"courier new, monospace">struct=
 B{ B(int) {} };</font></div><div><font face=3D"courier new, monospace"><br=
></font></div><div><font face=3D"courier new, monospace">struct C=C2=A0</fo=
nt></div><div><font face=3D"courier new, monospace">{=C2=A0</font></div><di=
v><font face=3D"courier new, monospace">=C2=A0 =C2=A0 operator int() { retu=
rn {}; }</font></div><div><font face=3D"courier new, monospace">};</font></=
div><div><font face=3D"courier new, monospace"><br></font></div><div><font =
face=3D"courier new, monospace">void f(B i) {}</font></div><div><font face=
=3D"courier new, monospace"><br></font></div><div><font face=3D"courier new=
, monospace"><br></font></div><div><font face=3D"courier new, monospace">in=
t main()</font></div><div><font face=3D"courier new, monospace">{</font></d=
iv><div><font face=3D"courier new, monospace">=C2=A0 f(C());</font></div><d=
iv><font face=3D"courier new, monospace">}</font></div></div><div><br></div=
><div>Will this be possible with your proposal, not the exact example, but =
do you count converting constructor on the return type as user conversion?<=
/div><div><br></div><div>You say it is fine if it requires a construction c=
all, thats why I am asking.=C2=A0</div><div><br></div><div><br></div><div><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
>If it is an error, that is also fine: now the library is not in charge of =
making an executive decision of hiding what could very well be a logic erro=
r on the part of the user (as demonstrated with the case of working with an=
 internal system).<br><br>Furthermore, chaining is already impossible in to=
day&#39;s current system. This proposal does not change that: only built-in=
 types are allowed to perform multiple conversions (this is where the Safe =
Bool Idiom of returning some bogus member-function-pointer type came from).=
 You may only perform 1 conversion with user-defined types, as stated in th=
e standard (<a href=3D"http://eel.is/c++draft/class.conv#4" target=3D"_blan=
k" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/u=
rl?q\x3dhttp%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fclass.conv%234\x26sa\x3dD\x26s=
ntz\x3d1\x26usg\x3dAFQjCNExknUBCREK8lRNfDbNg0OB7qOXqQ&#39;;return true;" on=
click=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Feel.i=
s%2Fc%2B%2Bdraft%2Fclass.conv%234\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE=
xknUBCREK8lRNfDbNg0OB7qOXqQ&#39;;return true;">http://eel.is/c++draft/class=
..<wbr>conv#4</a>).<br><br>Are there any other concerns?<br></div></div></bl=
ockquote></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/7a2b095b-b02e-4e00-a077-fe33948353a2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7a2b095b-b02e-4e00-a077-fe33948353a2=
%40isocpp.org</a>.<br />

------=_Part_1088_569432378.1543218659648--

------=_Part_1087_1518601261.1543218659647--

.


Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 26 Nov 2018 12:11:06 -0800
Raw View
--000000000000a15365057b96efe2
Content-Type: text/plain; charset="UTF-8"

This is a special case of a more general feature: the ability to *compute*
the type of a function template specialization from its arguments /
deduction context rather than merely *deducing* it. And we already have a
mechanism for that in another situation -- deduction guides. They're
currently limited to class templates, but the original problem they were
designed to solve was actually controlling function template deduction.

So, instead of

template<typename T>
X<T> operator T()

imagine something like

template<typename T>
X<T> convert(); // could be private

template<typename T>
operator T() -> convert<T>;

The advantage is that this is then a completely general feature, rather
than being specific to conversion functions:

template<typename ...T>
func(T...) -> impl<T...>; // can compute function signature from T... any
way you like

On Sat, 24 Nov 2018, 23:23 The PhD <phdofthehouse@gmail.com wrote:

> Dear Future Proposals,
>
>      This is a proposal I have been working on for quite some time. It was
> the first proposal I wanted to write before I got swamped with std::embed
> and everything else I've been working on. It is called "Explicit Return
> Types for (Implicit) Conversions", and will appear in the post-San Diego
> mailing: https://thephd.github.io/vendor/future_cxx/papers/d1193.html.
> The goal of this paper was to provide an opt-in way to add return types for
> conversions, which allow a user to override the compiler's current and
> default behavior. Because it is an opt-in feature, it has no impact on any
> code unless a conversion is explicitly and deliberately changed to use it.
> For example:
>
> struct S {
>      operator int () const { return 0; }
> };
>
> This code will continue to be well-formed and its meaning does not change.
> It can only change if you add something that is currently ill-formed in C++
> syntax today: a return type before the "operator" keyword. This means that
> code from C++11, C++14, C++17, etc. goes completely unchanged. Nothing
> actually changes until someone explicitly opts-in with the return type:
>
> struct S {
>      double operator int () const { return 0.0; }
> };
>
> The goal of this proposal is to allow better control for proxy, expression
> template, and intermediary convertible types in C++. Particularly, they are
> to make working with weird types like std::tie's tuples better and allow
> for a richer class of reference deduction and return value response for
> omni-convertible proxies which mimic return-type polymorphism.
>
>      Please let me know what you think of the proposal, especially its
> current wording.
>
> Thank You,
> JeanHeyd
>
> --
> 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/331d08dc-54ad-4681-abe8-986b66bf354a%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/331d08dc-54ad-4681-abe8-986b66bf354a%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

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

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

<div dir=3D"auto">This is a special case of a more general feature: the abi=
lity to *compute* the type of a function template specialization from its a=
rguments / deduction context rather than merely *deducing* it. And we alrea=
dy have a mechanism for that in another situation -- deduction guides. They=
&#39;re currently limited to class templates, but the original problem they=
 were designed to solve was actually controlling function template deductio=
n.<div dir=3D"auto"><br></div><div dir=3D"auto">So, instead of</div><div di=
r=3D"auto"><br></div><div dir=3D"auto">template&lt;typename T&gt;</div><div=
 dir=3D"auto">X&lt;T&gt; operator T()</div><div dir=3D"auto"><br></div><div=
 dir=3D"auto">imagine something like</div><div dir=3D"auto"><br></div><div =
dir=3D"auto"><div dir=3D"auto" style=3D"font-family:sans-serif">template&lt=
;typename T&gt;</div><div dir=3D"auto" style=3D"font-family:sans-serif">X&l=
t;T&gt; convert(); // could be private</div><div dir=3D"auto" style=3D"font=
-family:sans-serif"><br></div><div dir=3D"auto" style=3D"font-family:sans-s=
erif"><div dir=3D"auto">template&lt;typename T&gt;</div><div dir=3D"auto">o=
perator T() -&gt; convert&lt;T&gt;;</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">The advantage is that this is then a completely general feature=
, rather than being specific to conversion functions:</div><div dir=3D"auto=
"><br></div><div dir=3D"auto"><div dir=3D"auto">template&lt;typename ...T&g=
t;</div><div dir=3D"auto">func(T...) -&gt; impl&lt;T...&gt;; // can compute=
 function signature from T... any way you like</div></div></div></div></div=
><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, 24 Nov 2018, 23:23=
 The PhD &lt;<a href=3D"mailto:phdofthehouse@gmail.com">phdofthehouse@gmail=
..com</a> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">De=
ar Future Proposals,<br><br>=C2=A0=C2=A0=C2=A0=C2=A0 This is a proposal I h=
ave been working on for quite some time. It was the first proposal I wanted=
 to write before I got swamped with std::embed and everything else I&#39;ve=
 been working on. It is called &quot;Explicit Return Types for (Implicit) C=
onversions&quot;, and will appear in the post-San Diego mailing: <a href=3D=
"https://thephd.github.io/vendor/future_cxx/papers/d1193.html" target=3D"_b=
lank" rel=3D"noreferrer">https://thephd.github.io/vendor/future_cxx/papers/=
d1193.html</a>. The goal of this paper was to provide an opt-in way to add =
return types for conversions, which allow a user to override the compiler&#=
39;s current and default behavior. Because it is an opt-in feature, it has =
no impact on any code unless a conversion is explicitly and deliberately ch=
anged to use it. For example:<br><div><br><div style=3D"background-color:rg=
b(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-widt=
h:1px" class=3D"m_209428020446072032prettyprint"><code class=3D"m_209428020=
446072032prettyprint"><div class=3D"m_209428020446072032subprettyprint"><sp=
an style=3D"color:#008" class=3D"m_209428020446072032styled-by-prettify">st=
ruct</span><span style=3D"color:#000" class=3D"m_209428020446072032styled-b=
y-prettify"> S </span><span style=3D"color:#660" class=3D"m_209428020446072=
032styled-by-prettify">{</span><span style=3D"color:#000" class=3D"m_209428=
020446072032styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0</span><span style=
=3D"color:#008" class=3D"m_209428020446072032styled-by-prettify">operator</=
span><span style=3D"color:#000" class=3D"m_209428020446072032styled-by-pret=
tify"> </span><span style=3D"color:#008" class=3D"m_209428020446072032style=
d-by-prettify">int</span><span style=3D"color:#000" class=3D"m_209428020446=
072032styled-by-prettify"> </span><span style=3D"color:#660" class=3D"m_209=
428020446072032styled-by-prettify">()</span><span style=3D"color:#000" clas=
s=3D"m_209428020446072032styled-by-prettify"> </span><span style=3D"color:#=
008" class=3D"m_209428020446072032styled-by-prettify">const</span><span sty=
le=3D"color:#000" class=3D"m_209428020446072032styled-by-prettify"> </span>=
<span style=3D"color:#660" class=3D"m_209428020446072032styled-by-prettify"=
>{</span><span style=3D"color:#000" class=3D"m_209428020446072032styled-by-=
prettify"> </span><span style=3D"color:#008" class=3D"m_209428020446072032s=
tyled-by-prettify">return</span><span style=3D"color:#000" class=3D"m_20942=
8020446072032styled-by-prettify"> </span><span style=3D"color:#066" class=
=3D"m_209428020446072032styled-by-prettify">0</span><span style=3D"color:#6=
60" class=3D"m_209428020446072032styled-by-prettify">;</span><span style=3D=
"color:#000" class=3D"m_209428020446072032styled-by-prettify"> </span><span=
 style=3D"color:#660" class=3D"m_209428020446072032styled-by-prettify">}</s=
pan><span style=3D"color:#000" class=3D"m_209428020446072032styled-by-prett=
ify"><br></span><span style=3D"color:#660" class=3D"m_209428020446072032sty=
led-by-prettify">};</span><span style=3D"color:#000" class=3D"m_20942802044=
6072032styled-by-prettify"><br></span></div></code></div><br>This code will=
 continue to be well-formed and its meaning does not change. It can only ch=
ange if you add something that is currently ill-formed in C++ syntax today:=
 a return type before the &quot;operator&quot; keyword. This means that cod=
e from C++11, C++14, C++17, etc. goes completely unchanged. Nothing actuall=
y changes until someone explicitly opts-in with the return type:<br><br><di=
v style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);=
border-style:solid;border-width:1px" class=3D"m_209428020446072032prettypri=
nt"><code class=3D"m_209428020446072032prettyprint"><div class=3D"m_2094280=
20446072032subprettyprint"><span style=3D"color:#008" class=3D"m_2094280204=
46072032styled-by-prettify">struct</span><span style=3D"color:#000" class=
=3D"m_209428020446072032styled-by-prettify"> S </span><span style=3D"color:=
#660" class=3D"m_209428020446072032styled-by-prettify">{</span><span style=
=3D"color:#000" class=3D"m_209428020446072032styled-by-prettify"><br>=C2=A0=
 =C2=A0 =C2=A0</span><span style=3D"color:#008" class=3D"m_2094280204460720=
32styled-by-prettify">double</span><span style=3D"color:#000" class=3D"m_20=
9428020446072032styled-by-prettify"> </span><span style=3D"color:#008" clas=
s=3D"m_209428020446072032styled-by-prettify">operator</span><span style=3D"=
color:#000" class=3D"m_209428020446072032styled-by-prettify"> </span><span =
style=3D"color:#008" class=3D"m_209428020446072032styled-by-prettify">int</=
span><span style=3D"color:#000" class=3D"m_209428020446072032styled-by-pret=
tify"> </span><span style=3D"color:#660" class=3D"m_209428020446072032style=
d-by-prettify">()</span><span style=3D"color:#000" class=3D"m_2094280204460=
72032styled-by-prettify"> </span><span style=3D"color:#008" class=3D"m_2094=
28020446072032styled-by-prettify">const</span><span style=3D"color:#000" cl=
ass=3D"m_209428020446072032styled-by-prettify"> </span><span style=3D"color=
:#660" class=3D"m_209428020446072032styled-by-prettify">{</span><span style=
=3D"color:#000" class=3D"m_209428020446072032styled-by-prettify"> </span><s=
pan style=3D"color:#008" class=3D"m_209428020446072032styled-by-prettify">r=
eturn</span><span style=3D"color:#000" class=3D"m_209428020446072032styled-=
by-prettify"> </span><span style=3D"color:#066" class=3D"m_2094280204460720=
32styled-by-prettify">0.0</span><span style=3D"color:#660" class=3D"m_20942=
8020446072032styled-by-prettify">;</span><span style=3D"color:#000" class=
=3D"m_209428020446072032styled-by-prettify"> </span><span style=3D"color:#6=
60" class=3D"m_209428020446072032styled-by-prettify">}</span><span style=3D=
"color:#000" class=3D"m_209428020446072032styled-by-prettify"><br></span><s=
pan style=3D"color:#660" class=3D"m_209428020446072032styled-by-prettify">}=
;</span></div></code></div><br>The goal of this proposal is to allow better=
 control for proxy, expression template, and intermediary convertible types=
 in C++. Particularly, they are to make working with weird types like std::=
tie&#39;s tuples better and allow for a richer class of reference deduction=
 and return value response for omni-convertible proxies which mimic return-=
type polymorphism.<br><br>=C2=A0=C2=A0=C2=A0=C2=A0 Please let me know what =
you think of the proposal, especially its current wording.<br><br>Thank You=
,<br>JeanHeyd<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" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">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/331d08dc-54ad-4681-abe8-986b66bf354a%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/331d08dc-54ad-4681-abe8-986b66bf354a%40isocpp.org</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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/CAOfiQq%3DHfm7zHAMo1-M%3DUhS9noe68WBL=
XXcYyKrmq13Aqfzg2A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DHfm=
7zHAMo1-M%3DUhS9noe68WBLXXcYyKrmq13Aqfzg2A%40mail.gmail.com</a>.<br />

--000000000000a15365057b96efe2--

.