Topic: match function on sum types
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 24 Jan 2015 10:40:51 +0100
Raw View
This is a multi-part message in MIME format.
--------------060602050706050309010605
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi,
I have written a draft proposal for an match function that can be used
on sum types as, experimental::optional/variant/expected selected types
of experimental::any and smart pointers [1].
Any comments or contributions are welcome.
BTW, is the .md a valid format for a proposal? are there some .md to
html/pdf converters?
Vicente
[1]
https://github.com/viboes/tags/blob/master/doc/proposals/match/DXXXX_Match.md
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--------------060602050706050309010605
Content-Type: text/html; charset=UTF-8
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font size="+1">Hi,<br>
<br>
I have written a draft proposal for an match function that can be
used on sum types as, </font><font size="+1"><font size="+1">experimental::</font>optional/variant/expected
selected types of experimental::any and smart pointers </font><font
size="+1">[1].<br>
<br>
Any comments or contributions are welcome.<br>
<br>
BTW, is the .md a valid format for a proposal? are there some .md
to html/pdf converters?<br>
<br>
</font><font size="+1">Vicente<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="https://github.com/viboes/tags/blob/master/doc/proposals/match/DXXXX_Match.md">https://github.com/viboes/tags/blob/master/doc/proposals/match/DXXXX_Match.md</a><br>
</font>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--------------060602050706050309010605--
.
Author: Francisco Lopes <francisco.mailing.lists@oblita.com>
Date: Sat, 24 Jan 2015 15:01:50 -0200
Raw View
--20cf30223eaf7ada9a050d68dc5f
Content-Type: text/plain; charset=UTF-8
pandoc is an awesome converter. For more power over the content there's
also asciidoc.
2015-01-24 7:40 GMT-02:00 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr
>:
> Hi,
>
> I have written a draft proposal for an match function that can be used on
> sum types as, experimental::optional/variant/expected selected types of
> experimental::any and smart pointers [1].
>
> Any comments or contributions are welcome.
>
> BTW, is the .md a valid format for a proposal? are there some .md to
> html/pdf converters?
>
> Vicente
>
> [1]
> https://github.com/viboes/tags/blob/master/doc/proposals/match/DXXXX_Match.md
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--20cf30223eaf7ada9a050d68dc5f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">pandoc is an awesome converter. For more power over the co=
ntent there's also asciidoc.<br></div><div class=3D"gmail_extra"><br><d=
iv class=3D"gmail_quote">2015-01-24 7:40 GMT-02:00 Vicente J. Botet Escriba=
<span dir=3D"ltr"><<a href=3D"mailto:vicente.botet@wanadoo.fr" target=
=3D"_blank">vicente.botet@wanadoo.fr</a>></span>:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<font size=3D"+1">Hi,<br>
<br>
I have written a draft proposal for an match function that can be
used on sum types as, </font><font size=3D"+1"><font size=3D"+1">expe=
rimental::</font>optional/variant/expected
selected types of experimental::any and smart pointers </font><font s=
ize=3D"+1">[1].<br>
<br>
Any comments or contributions are welcome.<br>
<br>
BTW, is the .md a valid format for a proposal? are there some .md
to html/pdf converters?<br>
<br>
</font><font size=3D"+1">Vicente<br>
<br>
[1]
<a href=3D"https://github.com/viboes/tags/blob/master/doc/proposals/match/D=
XXXX_Match.md" target=3D"_blank">https://github.com/viboes/tags/blob/master=
/doc/proposals/match/DXXXX_Match.md</a><span class=3D"HOEnZb"><font color=
=3D"#888888"><br>
</font></span></font><span class=3D"HOEnZb"><font color=3D"#888888">
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--20cf30223eaf7ada9a050d68dc5f--
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Sat, 24 Jan 2015 21:01:12 +0100
Raw View
This is a multi-part message in MIME format.
--------------090104010801090501000904
Content-Type: text/plain; charset=UTF-8; format=flowed
In the technical specification of the first match function you have
return match(type<R>, type<ST>, that, overload(std::forward<Fs>(fcts)));
I think you're missing a parameter expanion
return match(type<R>, type<ST>, that, overload(std::forward<Fs>(fcts)...));
Considering the return type:
The moment one calls match(x, f1, f2, ...) shouldn't the compiler
statically pick exactly one of the overloads and thus be able to exactly
deduce the return type of the call? It does not need to be common_type
or some other unified type as each instantiation of match() should have
only exactly one possible code path (if there are no ambiguous overloads
of course). At least that is how your overload() proposal seems to work
so if match() delegates to overload() this shouldn't be an issue, right?
Miro
Am 24.01.2015 um 10:40 schrieb Vicente J. Botet Escriba:
> Hi,
>
> I have written a draft proposal for an match function that can be used
> on sum types as, experimental::optional/variant/expected selected
> types of experimental::any and smart pointers [1].
>
> Any comments or contributions are welcome.
>
> BTW, is the .md a valid format for a proposal? are there some .md to
> html/pdf converters?
>
> Vicente
>
> [1]
> https://github.com/viboes/tags/blob/master/doc/proposals/match/DXXXX_Match.md
> --
>
> ---
> 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
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--------------090104010801090501000904
Content-Type: text/html; charset=UTF-8
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
In the technical specification of the first match function you have<br>
<br>
return match(type<R>, type<ST>, that,
overload(std::forward<Fs>(fcts)));<br>
<br>
I think you're missing a parameter expanion<br>
<br>
return match(type<R>, type<ST>, that,
overload(std::forward<Fs>(fcts)...));<br>
<br>
Considering the return type:<br>
The moment one calls match(x, f1, f2, ...) shouldn't the compiler
statically pick exactly one of the overloads and thus be able to
exactly deduce the return type of the call? It does not need to be
common_type or some other unified type as each instantiation of
match() should have only exactly one possible code path (if there
are no ambiguous overloads of course). At least that is how your
overload() proposal seems to work so if match() delegates to
overload() this shouldn't be an issue, right?<br>
<br>
Miro<br>
<br>
<div class="moz-cite-prefix">Am 24.01.2015 um 10:40 schrieb Vicente
J. Botet Escriba:<br>
</div>
<blockquote cite="mid:54C368A3.7060402@wanadoo.fr" type="cite">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<font size="+1">Hi,<br>
<br>
I have written a draft proposal for an match function that can
be used on sum types as, </font><font size="+1"><font size="+1">experimental::</font>optional/variant/expected
selected types of experimental::any and smart pointers </font><font
size="+1">[1].<br>
<br>
Any comments or contributions are welcome.<br>
<br>
BTW, is the .md a valid format for a proposal? are there some
.md to html/pdf converters?<br>
<br>
</font><font size="+1">Vicente<br>
<br>
[1]
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://github.com/viboes/tags/blob/master/doc/proposals/match/DXXXX_Match.md">https://github.com/viboes/tags/blob/master/doc/proposals/match/DXXXX_Match.md</a><br>
</font> -- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a moz-do-not-send="true"
href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a moz-do-not-send="true"
href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a moz-do-not-send="true"
href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--------------090104010801090501000904--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 25 Jan 2015 12:51:57 +0100
Raw View
This is a multi-part message in MIME format.
--------------000409070704050203080800
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 24/01/15 21:01, Miro Knejp a =C3=A9crit :
> In the technical specification of the first match function you have
>
> return match(type<R>, type<ST>, that, overload(std::forward<Fs>(fcts)));
>
> I think you're missing a parameter expanion
>
> return match(type<R>, type<ST>, that,=20
> overload(std::forward<Fs>(fcts)...));
Agreed. Fixed.
>
> Considering the return type:
> The moment one calls match(x, f1, f2, ...) shouldn't the compiler=20
> statically pick exactly one of the overloads and thus be able to=20
> exactly deduce the return type of the call? It does not need to be=20
> common_type or some other unified type as each instantiation of=20
> match() should have only exactly one possible code path (if there are=20
> no ambiguous overloads of course). At least that is how your=20
> overload() proposal seems to work so if match() delegates to=20
> overload() this shouldn't be an issue, right?
>
The difference with overload is that match needs to return the type=20
returned by the overloaded function while overload return the object=20
overloading all the functions. So the question is, which type to return=20
if we don't know at compile time which overload would be selected?
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------000409070704050203080800
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 24/01/15 21:01, Miro Knejp a =C3=A9cr=
it=C2=A0:<br>
</div>
<blockquote cite=3D"mid:54C3FA08.2080103@gmail.com" type=3D"cite">
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty=
pe">
In the technical specification of the first match function you
have<br>
<br>
return match(type<R>, type<ST>, that,
overload(std::forward<Fs>(fcts)));<br>
<br>
I think you're missing a parameter expanion<br>
<br>
return match(type<R>, type<ST>, that,
overload(std::forward<Fs>(fcts)...));<br>
</blockquote>
Agreed. Fixed.<br>
<blockquote cite=3D"mid:54C3FA08.2080103@gmail.com" type=3D"cite"> <br>
Considering the return type:<br>
The moment one calls match(x, f1, f2, ...) shouldn't the compiler
statically pick exactly one of the overloads and thus be able to
exactly deduce the return type of the call? It does not need to be
common_type or some other unified type as each instantiation of
match() should have only exactly one possible code path (if there
are no ambiguous overloads of course). At least that is how your
overload() proposal seems to work so if match() delegates to
overload() this shouldn't be an issue, right?<br>
<br>
</blockquote>
The difference with overload is that match needs to return the type
returned by the overloaded function while overload return the object
overloading all the functions. So the question is, which type to
return if we don't know at compile time which overload would be
selected?<br>
<br>
Vicente<br>
<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------000409070704050203080800--
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Sun, 25 Jan 2015 13:35:23 +0100
Raw View
This is a multi-part message in MIME format.
--------------040903080004080306060106
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Am 25.01.2015 um 12:51 schrieb Vicente J. Botet Escriba:
> Le 24/01/15 21:01, Miro Knejp a =C3=A9crit :
>> In the technical specification of the first match function you have
>>
>> return match(type<R>, type<ST>, that, overload(std::forward<Fs>(fcts)));
>>
>> I think you're missing a parameter expanion
>>
>> return match(type<R>, type<ST>, that,=20
>> overload(std::forward<Fs>(fcts)...));
> Agreed. Fixed.
>>
>> Considering the return type:
>> The moment one calls match(x, f1, f2, ...) shouldn't the compiler=20
>> statically pick exactly one of the overloads and thus be able to=20
>> exactly deduce the return type of the call? It does not need to be=20
>> common_type or some other unified type as each instantiation of=20
>> match() should have only exactly one possible code path (if there are=20
>> no ambiguous overloads of course). At least that is how your=20
>> overload() proposal seems to work so if match() delegates to=20
>> overload() this shouldn't be an issue, right?
>>
> The difference with overload is that match needs to return the type=20
> returned by the overloaded function while overload return the object=20
> overloading all the functions. So the question is, which type to=20
> return if we don't know at compile time which overload would be selected?
Ah yes I forgot about that, and yes in those cases where the type is=20
determined at runtime you're right. But for many parameters we *do* know=20
at compile time which overload is selected. And for those I think=20
automatic return type deduction should be used.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------040903080004080306060106
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">
<br>
<div class=3D"moz-cite-prefix">Am 25.01.2015 um 12:51 schrieb Vicente
J. Botet Escriba:<br>
</div>
<blockquote cite=3D"mid:54C4D8DD.4010906@wanadoo.fr" type=3D"cite">
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty=
pe">
<div class=3D"moz-cite-prefix">Le 24/01/15 21:01, Miro Knejp a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote cite=3D"mid:54C3FA08.2080103@gmail.com" type=3D"cite">
<meta content=3D"text/html; charset=3Dutf-8"
http-equiv=3D"Content-Type">
In the technical specification of the first match function you
have<br>
<br>
return match(type<R>, type<ST>, that,
overload(std::forward<Fs>(fcts)));<br>
<br>
I think you're missing a parameter expanion<br>
<br>
return match(type<R>, type<ST>, that,
overload(std::forward<Fs>(fcts)...));<br>
</blockquote>
Agreed. Fixed.<br>
<blockquote cite=3D"mid:54C3FA08.2080103@gmail.com" type=3D"cite"> <b=
r>
Considering the return type:<br>
The moment one calls match(x, f1, f2, ...) shouldn't the
compiler statically pick exactly one of the overloads and thus
be able to exactly deduce the return type of the call? It does
not need to be common_type or some other unified type as each
instantiation of match() should have only exactly one possible
code path (if there are no ambiguous overloads of course). At
least that is how your overload() proposal seems to work so if
match() delegates to overload() this shouldn't be an issue,
right?<br>
<br>
</blockquote>
The difference with overload is that match needs to return the
type returned by the overloaded function while overload return the
object overloading all the functions. So the question is, which
type to return if we don't know at compile time which overload
would be selected?<br>
</blockquote>
Ah yes I forgot about that, and yes in those cases where the type is
determined at runtime you're right. But for many parameters we *do*
know at compile time which overload is selected. And for those I
think automatic return type deduction should be used.<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------040903080004080306060106--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 25 Jan 2015 15:55:20 +0100
Raw View
This is a multi-part message in MIME format.
--------------070806080608080005090109
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 25/01/15 13:35, Miro Knejp a =C3=A9crit :
>
> Am 25.01.2015 um 12:51 schrieb Vicente J. Botet Escriba:
>> Le 24/01/15 21:01, Miro Knejp a =C3=A9crit :
>>> In the technical specification of the first match function you have
>>>
>>> return match(type<R>, type<ST>, that, overload(std::forward<Fs>(fcts)))=
;
>>>
>>> I think you're missing a parameter expanion
>>>
>>> return match(type<R>, type<ST>, that,=20
>>> overload(std::forward<Fs>(fcts)...));
>> Agreed. Fixed.
>>>
>>> Considering the return type:
>>> The moment one calls match(x, f1, f2, ...) shouldn't the compiler=20
>>> statically pick exactly one of the overloads and thus be able to=20
>>> exactly deduce the return type of the call? It does not need to be=20
>>> common_type or some other unified type as each instantiation of=20
>>> match() should have only exactly one possible code path (if there=20
>>> are no ambiguous overloads of course). At least that is how your=20
>>> overload() proposal seems to work so if match() delegates to=20
>>> overload() this shouldn't be an issue, right?
>>>
>> The difference with overload is that match needs to return the type=20
>> returned by the overloaded function while overload return the object=20
>> overloading all the functions. So the question is, which type to=20
>> return if we don't know at compile time which overload would be selected=
?
> Ah yes I forgot about that, and yes in those cases where the type is=20
> determined at runtime you're right. But for many parameters we *do*=20
> know at compile time which overload is selected. And for those I think=20
> automatic return type deduction should be used.
>
I agree that is is boring to repeat the return type when all the=20
overloads return the same type. Could you give some additional and=20
concrete examples?
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------070806080608080005090109
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 25/01/15 13:35, Miro Knejp a =C3=A9cr=
it=C2=A0:<br>
</div>
<blockquote cite=3D"mid:54C4E30B.7030300@gmail.com" type=3D"cite">
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty=
pe">
<br>
<div class=3D"moz-cite-prefix">Am 25.01.2015 um 12:51 schrieb
Vicente J. Botet Escriba:<br>
</div>
<blockquote cite=3D"mid:54C4D8DD.4010906@wanadoo.fr" type=3D"cite">
<meta content=3D"text/html; charset=3Dutf-8"
http-equiv=3D"Content-Type">
<div class=3D"moz-cite-prefix">Le 24/01/15 21:01, Miro Knejp a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote cite=3D"mid:54C3FA08.2080103@gmail.com" type=3D"cite">
<meta content=3D"text/html; charset=3Dutf-8"
http-equiv=3D"Content-Type">
In the technical specification of the first match function you
have<br>
<br>
return match(type<R>, type<ST>, that,
overload(std::forward<Fs>(fcts)));<br>
<br>
I think you're missing a parameter expanion<br>
<br>
return match(type<R>, type<ST>, that,
overload(std::forward<Fs>(fcts)...));<br>
</blockquote>
Agreed. Fixed.<br>
<blockquote cite=3D"mid:54C3FA08.2080103@gmail.com" type=3D"cite"> =
<br>
Considering the return type:<br>
The moment one calls match(x, f1, f2, ...) shouldn't the
compiler statically pick exactly one of the overloads and thus
be able to exactly deduce the return type of the call? It does
not need to be common_type or some other unified type as each
instantiation of match() should have only exactly one possible
code path (if there are no ambiguous overloads of course). At
least that is how your overload() proposal seems to work so if
match() delegates to overload() this shouldn't be an issue,
right?<br>
<br>
</blockquote>
The difference with overload is that match needs to return the
type returned by the overloaded function while overload return
the object overloading all the functions. So the question is,
which type to return if we don't know at compile time which
overload would be selected?<br>
</blockquote>
Ah yes I forgot about that, and yes in those cases where the type
is determined at runtime you're right. But for many parameters we
*do* know at compile time which overload is selected. And for
those I think automatic return type deduction should be used.<br>
<br>
</blockquote>
I agree that is is boring to repeat the return type when all the
overloads return the same type. Could you give some additional and
concrete examples?<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------070806080608080005090109--
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Mon, 26 Jan 2015 08:48:09 +0100
Raw View
This is a multi-part message in MIME format.
--------------030701030702080301020505
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Am 25.01.2015 um 15:55 schrieb Vicente J. Botet Escriba:
> Le 25/01/15 13:35, Miro Knejp a =C3=A9crit :
>>
>> Am 25.01.2015 um 12:51 schrieb Vicente J. Botet Escriba:
>>> Le 24/01/15 21:01, Miro Knejp a =C3=A9crit :
>>>> In the technical specification of the first match function you have
>>>>
>>>> return match(type<R>, type<ST>, that,=20
>>>> overload(std::forward<Fs>(fcts)));
>>>>
>>>> I think you're missing a parameter expanion
>>>>
>>>> return match(type<R>, type<ST>, that,=20
>>>> overload(std::forward<Fs>(fcts)...));
>>> Agreed. Fixed.
>>>>
>>>> Considering the return type:
>>>> The moment one calls match(x, f1, f2, ...) shouldn't the compiler=20
>>>> statically pick exactly one of the overloads and thus be able to=20
>>>> exactly deduce the return type of the call? It does not need to be=20
>>>> common_type or some other unified type as each instantiation of=20
>>>> match() should have only exactly one possible code path (if there=20
>>>> are no ambiguous overloads of course). At least that is how your=20
>>>> overload() proposal seems to work so if match() delegates to=20
>>>> overload() this shouldn't be an issue, right?
>>>>
>>> The difference with overload is that match needs to return the type=20
>>> returned by the overloaded function while overload return the object=20
>>> overloading all the functions. So the question is, which type to=20
>>> return if we don't know at compile time which overload would be=20
>>> selected?
>> Ah yes I forgot about that, and yes in those cases where the type is=20
>> determined at runtime you're right. But for many parameters we *do*=20
>> know at compile time which overload is selected. And for those I=20
>> think automatic return type deduction should be used.
>>
> I agree that is is boring to repeat the return type when all the=20
> overloads return the same type. Could you give some additional and=20
> concrete examples?
>
> Vicente
OK, I may have simplified the problem a bit too much.
However, seeing that match(that, fcts...) delegates the actual work to=20
match(type<ST>, that, fcts...) then the return type is whatever the=20
customization point returns. If a customization point does not exist=20
then the default is the same as overload(fcts...)(that) for which the=20
code path is exactly known.
I guess the problem is how to determine the return type for the=20
customizations where ST is of type variant, any, optional, etc, where=20
the code path is determined at runtime, in which case I'd even be=20
inclined to require all functions to return the same type.
Miro
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------030701030702080301020505
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">
<br>
<div class=3D"moz-cite-prefix">Am 25.01.2015 um 15:55 schrieb Vicente
J. Botet Escriba:<br>
</div>
<blockquote cite=3D"mid:54C503D8.1040204@wanadoo.fr" type=3D"cite">
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty=
pe">
<div class=3D"moz-cite-prefix">Le 25/01/15 13:35, Miro Knejp a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote cite=3D"mid:54C4E30B.7030300@gmail.com" type=3D"cite">
<meta content=3D"text/html; charset=3Dutf-8"
http-equiv=3D"Content-Type">
<br>
<div class=3D"moz-cite-prefix">Am 25.01.2015 um 12:51 schrieb
Vicente J. Botet Escriba:<br>
</div>
<blockquote cite=3D"mid:54C4D8DD.4010906@wanadoo.fr" type=3D"cite">
<meta content=3D"text/html; charset=3Dutf-8"
http-equiv=3D"Content-Type">
<div class=3D"moz-cite-prefix">Le 24/01/15 21:01, Miro Knejp a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote cite=3D"mid:54C3FA08.2080103@gmail.com" type=3D"cite"=
>
<meta content=3D"text/html; charset=3Dutf-8"
http-equiv=3D"Content-Type">
In the technical specification of the first match function
you have<br>
<br>
return match(type<R>, type<ST>, that,
overload(std::forward<Fs>(fcts)));<br>
<br>
I think you're missing a parameter expanion<br>
<br>
return match(type<R>, type<ST>, that,
overload(std::forward<Fs>(fcts)...));<br>
</blockquote>
Agreed. Fixed.<br>
<blockquote cite=3D"mid:54C3FA08.2080103@gmail.com" type=3D"cite"=
>
<br>
Considering the return type:<br>
The moment one calls match(x, f1, f2, ...) shouldn't the
compiler statically pick exactly one of the overloads and
thus be able to exactly deduce the return type of the call?
It does not need to be common_type or some other unified
type as each instantiation of match() should have only
exactly one possible code path (if there are no ambiguous
overloads of course). At least that is how your overload()
proposal seems to work so if match() delegates to overload()
this shouldn't be an issue, right?<br>
<br>
</blockquote>
The difference with overload is that match needs to return the
type returned by the overloaded function while overload return
the object overloading all the functions. So the question is,
which type to return if we don't know at compile time which
overload would be selected?<br>
</blockquote>
Ah yes I forgot about that, and yes in those cases where the
type is determined at runtime you're right. But for many
parameters we *do* know at compile time which overload is
selected. And for those I think automatic return type deduction
should be used.<br>
<br>
</blockquote>
I agree that is is boring to repeat the return type when all the
overloads return the same type. Could you give some additional and
concrete examples?<br>
<br>
Vicente<br>
</blockquote>
OK, I may have simplified the problem a bit too much.<br>
<br>
However, seeing that match(that, fcts...) delegates the actual work
to match(type<ST>, that, fcts...) then the return type is
whatever the customization point returns. If a customization point
does not exist then the default is the same as
overload(fcts...)(that) for which the code path is exactly known.<br>
<br>
I guess the problem is how to determine the return type for the
customizations where ST is of type variant, any, optional, etc,
where the code path is determined at runtime, in which case I'd even
be inclined to require all functions to return the same type.<br>
<br>
Miro<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------030701030702080301020505--
.