Hi,

  [1]  proposes two functions that allow to overload lambdas and
function objects, but also member and non-member functions.

* overload selects the best overload using C++ overload resolution and
* first_overload selects the first overload using C++ overload resolution.

Any feedback is welcome.

Vicente Botet

[1]
https://github.com/viboes/tags/blob/master/doc/proposals/overload/D0051.pdf

--

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

.

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

On Tue, Sep 15, 2015 at 12:52 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:

> Hi,
>
>  [1]  proposes two functions that allow to overload lambdas and function
> objects, but also member and non-member functions.
>
> * overload selects the best overload using C++ overload resolution and
> * first_overload selects the first overload using C++ overload resolution.
>
> Any feedback is welcome.
>
> Vicente Botet
>
> [1]
> https://github.com/viboes/tags/blob/master/doc/proposals/overload/D0051.pdf


+1

I'm glad this is being proposed. Something to consider: if all of the
proposed invocation traits components end up in the language at some point,
I believe that it also may be possible to implement a version of "overload"
that does not copy/move any of the passed-in function arguments, but
instead holds them by reference, or at least that was my belief when I
originally looked through invocation traits (I never actually went through
and attempted it, so it it might not actually be enough -- I only suspected
that it may be). The principle behind using invocation traits there is that
you'd make the value-based version that you already have, but in a purely
unevaluated context, and then use invocation traits facilities to determine
exactly which operator() overload was picked (this facility was a part of
the proposal though I'm not sure that this part will be in C++17). With
that information, you should then be able to call the appropriate function
in the "tie_overloads" implementation without ever having copied any of the
underlying function objects. Again, I never fully examined the possibility,
I only suspected that invocation traits would allow this to be implemented.
If so, it might be sufficient rationale to also push all of the facilities
 in the invocation traits proposal into the language, or otherwise
introduce similar facilities that would actually make such a
"tie_overloads" function possible to implement.

Regarding your open points:

1) Should the callable be passed by value? In my opinion, no it should not,
and this is the growing trend in other proposals as well.

2) A better name for the proposed function? I would personally suggest
"overloads" as opposed to "overload." I understand that "overload" is
intended to be a verb here, which is fine, I just personally consider that
thinking of it as a noun is convenient such that you can have something
like "tie_overloads" or "forward_as_overloads" to do the other things I
mentioned earlier in this reply. If the name is "overload," I don't see an
obvious way to be consistent (I may just not be being creative enough). At
the very least, even if there is no "tie" based version of the overload
templates to be initially proposed, it seems to me to make sense to be
aware that one may come at some point in a future standard.

3) Do we want to expose the result type of these function? In a world with
decltype this seems unnecessary as proposed. I do, however, think that it
might be important if "overload" has an optional syntax:

//////////
overload<desired_return_type>([](a) {/**/}, [](b) {/**/})
//////////

The idea of the above is that when the overload is invoked, the return type
of the wrapped function call is always "desired_return_type," converting
the result if necessary (and producing an error if there is no conversion).
Internally this could be exposed as nested typedef. The idea is that this
can be useful when using "overload" as an argument to something like
visitation of a variant and can even improve compile-times if visitation
would otherwise try to deduce the return type by minimizing template
instantiations. An example of what I mean using boost apply_visitor as an
example:

//////////
auto result
  = apply_visitor(overload<int>([](a const& arg1, b const& arg2) {/**/}
/*...*/) , variant_1, variant_2);
//////////

To understand why this is helpful, consider what happens if you didn't
explicitly specify "int". Internal to the implementation, in order to
deduce the result of the overall visitation (assuming we want to do this at
all), it would have to instantiate all of the possibilities and use
something like common_type, or possibly produce a hard error in the case
that the types do not match. By, instead, explicitly specifying the return
type for overloads, apply_visitor would be able to see that result type and
use it without having to do some kind of complicated deduction. You could
(and likely should) also be able to explicitly specify the result type
directly with apply_visitor by doing "apply_visitor<int>," though having it
optionally done directly with "overloads" makes this more generally useful
in context other than variant visitation as well (for instance, algorithms
that operate on elements of tuples).

Much of this rationale is somewhat predicated on us getting a proper
variant in the language, but that rationale is still useful given that such
libraries exist in the real world already and it would be great if
"overload" had such use-cases explicitly in mind, regardless.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Sep 15, 2015 at 12:52 PM, Vicente J. Botet Escriba <span dir=3D"ltr">&l=
t;<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicente.bot=
et@wanadoo.fr</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb=
(204,204,204);border-left-style:solid;padding-left:1ex">Hi,<br>
<br>
=C2=A0[1]=C2=A0 proposes two functions that allow to overload lambdas and f=
unction objects, but also member and non-member functions.<br>
<br>
* overload selects the best overload using C++ overload resolution and<br>
* first_overload selects the first overload using C++ overload resolution.<=
br>
<br>
Any feedback is welcome.<br>
<br>
Vicente Botet<br>
<br>
[1] <a href=3D"https://github.com/viboes/tags/blob/master/doc/proposals/ove=
rload/D0051.pdf" rel=3D"noreferrer" target=3D"_blank">https://github.com/vi=
boes/tags/blob/master/doc/proposals/overload/D0051.pdf</a></blockquote><div=
><br></div><div>+1</div><div><br></div><div>I&#39;m glad this is being prop=
osed. Something to consider: if all of the proposed invocation traits compo=
nents end up in the language at some point, I believe that it also may be p=
ossible to implement a version of &quot;overload&quot; that does not copy/m=
ove any of the passed-in function arguments, but instead holds them by refe=
rence, or at least that was my belief when I originally looked through invo=
cation traits (I never actually went through and attempted it, so it it mig=
ht not actually be enough -- I only suspected that it may be). The principl=
e behind using invocation traits there is that you&#39;d make the value-bas=
ed version that you already have, but in a purely unevaluated context, and =
then use invocation traits facilities to determine exactly which operator()=
 overload was picked (this facility was a part of the proposal though I&#39=
;m not sure that this part will be in C++17). With that information, you sh=
ould then be able to call the appropriate function in the &quot;tie_overloa=
ds&quot; implementation without ever having copied any of the underlying fu=
nction objects. Again, I never fully examined the possibility, I only suspe=
cted that invocation traits would allow this to be implemented. If so, it m=
ight be sufficient rationale to also push all of the facilities =C2=A0in th=
e invocation traits proposal into the language, or otherwise introduce simi=
lar facilities that would actually make such a &quot;tie_overloads&quot; fu=
nction possible to implement.</div><div><br></div><div>Regarding your open =
points:</div><div><br></div><div>1) Should the callable be passed by value?=
 In my opinion, no it should not, and this is the growing trend in other pr=
oposals as well.</div><div><br></div><div>2) A better name for the proposed=
 function? I would personally suggest &quot;overloads&quot; as opposed to &=
quot;overload.&quot; I understand that &quot;overload&quot; is intended to =
be a verb here, which is fine, I just personally consider that thinking of =
it as a noun is convenient such that you can have something like &quot;tie_=
overloads&quot; or &quot;forward_as_overloads&quot; to do the other things =
I mentioned earlier in this reply. If the name is &quot;overload,&quot; I d=
on&#39;t see an obvious way to be consistent (I may just not be being creat=
ive enough). At the very least, even if there is no &quot;tie&quot; based v=
ersion of the overload templates to be initially proposed, it seems to me t=
o make sense to be aware that one may come at some point in a future standa=
rd.=C2=A0</div><div><br></div><div>3) Do we want to expose the result type =
of these function? In a world with decltype this seems unnecessary as propo=
sed. I do, however, think that it might be important if &quot;overload&quot=
; has an optional syntax:</div><div><br></div><div>//////////</div><div>ove=
rload&lt;desired_return_type&gt;([](a) {/**/}, [](b) {/**/})<br></div><div>=
//////////</div><div><br></div><div>The idea of the above is that when the =
overload is invoked, the return type of the wrapped function call is always=
 &quot;desired_return_type,&quot; converting the result if necessary (and p=
roducing an error if there is no conversion). Internally this could be expo=
sed as nested typedef. The idea is that this can be useful when using &quot=
;overload&quot; as an argument to something like visitation of a variant an=
d can even improve compile-times if visitation would otherwise try to deduc=
e the return type by minimizing template instantiations. An example of what=
 I mean using boost apply_visitor as an example:</div><div><br></div><div>/=
/////////</div><div>auto result</div><div>=C2=A0 =3D apply_visitor(overload=
&lt;int&gt;([](a const&amp; arg1, b const&amp; arg2) {/**/} /*...*/) , vari=
ant_1, variant_2);</div><div>//////////</div><div><br></div><div>To underst=
and why this is helpful, consider what happens if you didn&#39;t explicitly=
 specify &quot;int&quot;. Internal to the implementation, in order to deduc=
e the result of the overall visitation (assuming we want to do this at all)=
, it would have to instantiate all of the possibilities and use something l=
ike common_type, or possibly produce a hard error in the case that the type=
s do not match. By, instead, explicitly specifying the return type for over=
loads, apply_visitor would be able to see that result type and use it witho=
ut having to do some kind of complicated deduction. You could (and likely s=
hould) also be able to explicitly specify the result type directly with app=
ly_visitor by doing &quot;apply_visitor&lt;int&gt;,&quot; though having it =
optionally done directly with &quot;overloads&quot; makes this more general=
ly useful in context other than variant visitation as well (for instance, a=
lgorithms that operate on elements of tuples).</div><div><br></div><div>Muc=
h of this rationale is somewhat predicated on us getting a proper variant i=
n the language, but that rationale is still useful given that such librarie=
s exist in the real world already and it would be great if &quot;overload&q=
uot; had such use-cases explicitly in mind, regardless.</div></div></div></=
div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1142e64860c18a051fd00045--

.

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

On Tue, Sep 15, 2015 at 2:38 PM, Matt Calabrese <calabrese@google.com>
wrote:
>
> I'm glad this is being proposed. Something to consider: if all of the
> proposed invocation traits components end up in the language at some point,
> I believe that it also may be possible to implement a version of "overload"
> that does not copy/move any of the passed-in function arguments, but
> instead holds them by reference, or at least that was my belief when I
> originally looked through invocation traits (I never actually went through
> and attempted it, so it it might not actually be enough -- I only suspected
> that it may be). The principle behind using invocation traits there is that
> you'd make the value-based version that you already have, but in a purely
> unevaluated context, and then use invocation traits facilities to determine
> exactly which operator() overload was picked (this facility was a part of
> the proposal though I'm not sure that this part will be in C++17). With
> that information, you should then be able to call the appropriate function
> in the "tie_overloads" implementation without ever having copied any of the
> underlying function objects.
>

Some further thoughts regarding what I mean here -- the invocation traits
proposal suggested a metafunction that allows you to retrieve a pointer to
the function that would be invoked when passed a given set of arguments. If
you used that, it might be possible to know which function would have been
invoked. One corner-case is that if multiple of the passed-in function
objects are themselves related by inheritance, it wouldn't directly be
enough information. An "overload" invocation that is passed multiple other
results to "overload" may exhibit this problem. Perhaps there is some trick
I can't think of immediately to resolve this, but it seems like invocation
traits or similar facilities may be able to provide a solution.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Sep 15, 2015 at 2:38 PM, Matt Calabrese <span dir=3D"ltr">&lt;<a href=
=3D"mailto:calabrese@google.com" target=3D"_blank">calabrese@google.com</a>=
&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><div>I&#39;m glad this is bein=
g proposed. Something to consider: if all of the proposed invocation traits=
 components end up in the language at some point, I believe that it also ma=
y be possible to implement a version of &quot;overload&quot; that does not =
copy/move any of the passed-in function arguments, but instead holds them b=
y reference, or at least that was my belief when I originally looked throug=
h invocation traits (I never actually went through and attempted it, so it =
it might not actually be enough -- I only suspected that it may be). The pr=
inciple behind using invocation traits there is that you&#39;d make the val=
ue-based version that you already have, but in a purely unevaluated context=
, and then use invocation traits facilities to determine exactly which oper=
ator() overload was picked (this facility was a part of the proposal though=
 I&#39;m not sure that this part will be in C++17). With that information, =
you should then be able to call the appropriate function in the &quot;tie_o=
verloads&quot; implementation without ever having copied any of the underly=
ing function objects.</div></div></div></div></blockquote><div><br></div><d=
iv>Some further thoughts regarding what I mean here -- the invocation trait=
s proposal suggested a metafunction that allows you to retrieve a pointer t=
o the function that would be invoked when passed a given set of arguments. =
If you used that, it might be possible to know which function would have be=
en invoked. One corner-case is that if multiple of the passed-in function o=
bjects are themselves related by inheritance, it wouldn&#39;t directly be e=
nough information. An &quot;overload&quot; invocation that is passed multip=
le other results to &quot;overload&quot; may exhibit this problem. Perhaps =
there is some trick I can&#39;t think of immediately to resolve this, but i=
t seems like invocation traits or similar facilities may be able to provide=
 a solution.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c299663ac985051fd01f52--

.

Le 15/09/15 23:38, 'Matt Calabrese' via ISO C++ Standard - Future=20
Proposals a =C3=A9crit :
> On Tue, Sep 15, 2015 at 12:52 PM, Vicente J. Botet Escriba <
> vicente.botet@wanadoo.fr> wrote:
>
>> Hi,
>>
>>   [1]  proposes two functions that allow to overload lambdas and functio=
n
>> objects, but also member and non-member functions.
>>
>> * overload selects the best overload using C++ overload resolution and
>> * first_overload selects the first overload using C++ overload resolutio=
n.
>>
>> Any feedback is welcome.
>>
>> Vicente Botet
>>
>> [1]
>> https://github.com/viboes/tags/blob/master/doc/proposals/overload/D0051.=
pdf
>
> +1
>
> I'm glad this is being proposed. Something to consider: if all of the
> proposed invocation traits components end up in the language at some poin=
t,
> I believe that it also may be possible to implement a version of "overloa=
d"
> that does not copy/move any of the passed-in function arguments, but
> instead holds them by reference, or at least that was my belief when I
> originally looked through invocation traits (I never actually went throug=
h
> and attempted it, so it it might not actually be enough -- I only suspect=
ed
> that it may be). The principle behind using invocation traits there is th=
at
> you'd make the value-based version that you already have, but in a purely
> unevaluated context, and then use invocation traits facilities to determi=
ne
> exactly which operator() overload was picked (this facility was a part of
> the proposal though I'm not sure that this part will be in C++17).
I like the invocation traits proposal and I hope that it would be used=20
by a lot of forwarding functions. Could someone confirm if it has been=20
adopted for the next C++17 standard?
I don't see to which function do you want to apply the invocation=20
traits. IIUC, you want an overload function having the overloaded=20
functions passed by reference, isn't it?
Are you suggesting to apply these traits to the overloaded functions to=20
take care the references parameters?
> With
> that information, you should then be able to call the appropriate functio=
n
> in the "tie_overloads" implementation without ever having copied any of t=
he
> underlying function objects. Again, I never fully examined the possibilit=
y,
> I only suspected that invocation traits would allow this to be implemente=
d.
> If so, it might be sufficient rationale to also push all of the facilitie=
s
>   in the invocation traits proposal into the language, or otherwise
> introduce similar facilities that would actually make such a
> "tie_overloads" function possible to implement.
Please, could you elaborate on this tie_overload, I'm a little lost,=20
some usage examples, ...
>
> Regarding your open points:
>
> 1) Should the callable be passed by value? In my opinion, no it should no=
t,
> and this is the growing trend in other proposals as well.
To be franc, I have not think at all at the possibility to pass them by=20
reference. I was hoping that nobody was requesting them. I'll see what=20
can be done.
>
> 2) A better name for the proposed function? I would personally suggest
> "overloads" as opposed to "overload." I understand that "overload" is
> intended to be a verb here, which is fine, I just personally consider tha=
t
> thinking of it as a noun is convenient such that you can have something
> like "tie_overloads" or "forward_as_overloads" to do the other things I
> mentioned earlier in this reply. If the name is "overload," I don't see a=
n
> obvious way to be consistent (I may just not be being creative enough). A=
t
> the very least, even if there is no "tie" based version of the overload
> templates to be initially proposed, it seems to me to make sense to be
> aware that one may come at some point in a future standard.

> 3) Do we want to expose the result type of these function? In a world wit=
h
> decltype this seems unnecessary as proposed. I do, however, think that it
> might be important if "overload" has an optional syntax:
>
> //////////
> overload<desired_return_type>([](a) {/**/}, [](b) {/**/})
> //////////
Yeah, I have implemented this already to cover exactly this use case:=20
the users wants a specific return type.
> The idea of the above is that when the overload is invoked, the return ty=
pe
> of the wrapped function call is always "desired_return_type," converting
> the result if necessary (and producing an error if there is no conversion=
).
> Internally this could be exposed as nested typedef. The idea is that this
> can be useful when using "overload" as an argument to something like
> visitation of a variant and can even improve compile-times if visitation
> would otherwise try to deduce the return type by minimizing template
> instantiations. An example of what I mean using boost apply_visitor as an
> example:
>
> //////////
> auto result
>    =3D apply_visitor(overload<int>([](a const& arg1, b const& arg2) {/**/=
}
> /*...*/) , variant_1, variant_2);
> //////////
>
> To understand why this is helpful, consider what happens if you didn't
> explicitly specify "int". Internal to the implementation, in order to
> deduce the result of the overall visitation (assuming we want to do this =
at
> all), it would have to instantiate all of the possibilities and use
> something like common_type, or possibly produce a hard error in the case
> that the types do not match. By, instead, explicitly specifying the retur=
n
> type for overloads, apply_visitor would be able to see that result type a=
nd
> use it without having to do some kind of complicated deduction.
How can apply_visitor take advantage of a function object that has a=20
unique return type for all the overloads? Do you pretend that=20
apply_visitor works only with function objects that return a unique=20
return types for all the overloads? I hope not. Or that it can be able=20
to detect if the function object has a nested typedef and it can avoid=20
thus the whole deduction? Do you believe that this would reduce=20
consequently the compilation time? Is this the single argument?
> You could
> (and likely should) also be able to explicitly specify the result type
> directly with apply_visitor by doing "apply_visitor<int>," though having =
it
> optionally done directly with "overloads" makes this more generally usefu=
l
> in context other than variant visitation as well (for instance, algorithm=
s
> that operate on elements of tuples).
>
> Much of this rationale is somewhat predicated on us getting a proper
> variant in the language, but that rationale is still useful given that su=
ch
> libraries exist in the real world already and it would be great if
> "overload" had such use-cases explicitly in mind, regardless.
>
Point taken. I'll add this overload to overload;-)

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

.

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

On Tue, Sep 15, 2015 at 4:12 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
>
> I like the invocation traits proposal and I hope that it would be used by
> a lot of forwarding functions. Could someone confirm if it has been adopted
> for the next C++17 standard?
> I don't see to which function do you want to apply the invocation traits.
> IIUC, you want an overload function having the overloaded functions passed
> by reference, isn't it?
> Are you suggesting to apply these traits to the overloaded functions to
> take care the references parameters?


For a usage example:

//////////
struct function_with_state {
  void operator ()(int arg) { invoked = true; }
  bool invoked = false;
};

function_with_state foo;

apply_visitor(forward_as_overloads(foo, [](a arg) { /**/ }),
variant_instance);

// You can now check foo.invoked;
bool invoked = foo.invoked;
//////////

This is an obviously contrived example, but the underlying idea is that you
want to be able to examine or continue modifying state that was mutated by
the visitation. Standard library algorithms like std::for_each effectively
accomplish this by returning the function object, which also might be
feasible if there were a form of apply_visitor that yielded the passed-in
function object in addition to or in place of the result of the function
object's invocation. Other reasons to prefer "tie_overloads" or
"forward_as_overloads" would be when even a move is costly or simply does
not exist.

The closest equivalent to my above example using only "overload" that I can
think of off-hand would be something like:

//////////
struct function_with_state {
  void operator ()(int arg) { invoked = true; }
  bool invoked = false;
};

auto fun = overloads(function_with_state(), [](a arg) { /**/ };
apply_visitor(std::ref(fun), variant_instance);

// Assumes some way to access one of the contained "overload" functions.
// Here I just use std::get with the type, but hypothetically it could be
done
// with std::get and an index, or some other way entirely. Obviously this
// would need to be proposed.
bool invoked = std::get<function_with_state>(fun).invoked;
//////////

On Tue, Sep 15, 2015 at 4:12 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:

> Yeah, I have implemented this already to cover exactly this use case: the
> users wants a specific return type.


Great! I think this would be a good addition to a complete proposal.

On Tue, Sep 15, 2015 at 4:12 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:

> How can apply_visitor take advantage of a function object that has a
> unique return type for all the overloads? Do you pretend that apply_visitor
> works only with function objects that return a unique return types for all
> the overloads? I hope not. Or that it can be able to detect if the function
> object has a nested typedef and it can avoid thus the whole deduction? Do
> you believe that this would reduce consequently the compilation time? Is
> this the single argument?


I suggest the following:

1) If apply_visitor is given an explicit result type, use that.
2) If apply_visitor is NOT given an explicit result type, use the explicit
result type of the function object if one exists.
3) If neither apply_visitor nor the function object have an explicit result
type, but all of the invocations would have the same result type, use that.
4) If none of the above are true, then we have a few final options:
  a) Produce a compile time error
  b) Return void or some stateless type
  c) Try to do some kind of common type deduction

To be optimal with compile-times, which is something that becomes a serious
consideration with variants having many states and/or doing n-ary
visitation for n > 1, users would prefer option 1 or option 2, since
otherwise the implied checking, especially if common type deduction is at
play, could be considerable.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Sep 15, 2015 at 4:12 PM, Vicente J. Botet Escriba <span dir=3D"ltr">&lt=
;<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicente.bote=
t@wanadoo.fr</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">
I like the invocation traits proposal and I hope that it would be used by a=
 lot of forwarding functions. Could someone confirm if it has been adopted =
for the next C++17 standard?<br>
I don&#39;t see to which function do you want to apply the invocation trait=
s. IIUC, you want an overload function having the overloaded functions pass=
ed by reference, isn&#39;t it?<br>
Are you suggesting to apply these traits to the overloaded functions to tak=
e care the references parameters?</blockquote><div><br></div><div>For a usa=
ge example:</div><div><br></div><div>//////////</div><div>struct function_w=
ith_state {</div><div>=C2=A0 void operator ()(int arg) { invoked =3D true; =
}</div><div>=C2=A0 bool invoked =3D false;</div><div>};</div><div><br></div=
><div>function_with_state foo;</div><div><br></div><div>apply_visitor(forwa=
rd_as_overloads(foo, [](a arg) { /**/ }), variant_instance);</div><div><br>=
</div><div>// You can now check foo.invoked;</div><div>bool invoked =3D foo=
..invoked;</div><div>//////////</div><div><br></div><div>This is an obviousl=
y contrived example, but the underlying idea is that you want to be able to=
 examine or continue modifying state that was mutated by the visitation. St=
andard library algorithms like std::for_each effectively accomplish this by=
 returning the function object, which also might be feasible if there were =
a form of apply_visitor that yielded the passed-in function object in addit=
ion to or in place of the result of the function object&#39;s invocation. O=
ther reasons to prefer &quot;tie_overloads&quot; or &quot;forward_as_overlo=
ads&quot; would be when even a move is costly or simply does not exist.</di=
v><div><br></div><div>The closest equivalent to my above example using only=
 &quot;overload&quot; that I can think of off-hand would be something like:=
</div><div><br></div><div>//////////</div><div>struct function_with_state {=
</div><div>=C2=A0 void operator ()(int arg) { invoked =3D true; }</div><div=
>=C2=A0 bool invoked =3D false;</div><div>};</div><div><br></div><div>auto =
fun =3D overloads(function_with_state(), [](a arg) { /**/ };</div><div>appl=
y_visitor(std::ref(fun), variant_instance);</div><div><br></div><div>// Ass=
umes some way to access one of the contained &quot;overload&quot; functions=
..</div><div>// Here I just use std::get with the type, but hypothetically i=
t could be done</div><div>// with std::get and an index, or some other way =
entirely. Obviously this</div><div>// would need to be proposed.</div><div>=
bool invoked =3D std::get&lt;function_with_state&gt;(fun).invoked;<br></div=
><div>//////////</div><div><br></div><div>On Tue, Sep 15, 2015 at 4:12 PM, =
Vicente J. Botet Escriba=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:vicen=
te.botet@wanadoo.fr" target=3D"_blank">vicente.botet@wanadoo.fr</a>&gt;</sp=
an>=C2=A0wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);=
border-left-style:solid;padding-left:1ex">
Yeah, I have implemented this already to cover exactly this use case: the u=
sers wants a specific return type.</blockquote><div><br></div><div>Great! I=
 think this would be a good addition to a complete proposal.</div><div>=C2=
=A0</div><div>On Tue, Sep 15, 2015 at 4:12 PM, Vicente J. Botet Escriba=C2=
=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:vicente.botet@wanadoo.fr" target=
=3D"_blank">vicente.botet@wanadoo.fr</a>&gt;</span>=C2=A0wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pad=
ding-left:1ex">
How can apply_visitor take advantage of a function object that has a unique=
 return type for all the overloads? Do you pretend that apply_visitor works=
 only with function objects that return a unique return types for all the o=
verloads? I hope not. Or that it can be able to detect if the function obje=
ct has a nested typedef and it can avoid thus the whole deduction? Do you b=
elieve that this would reduce consequently the compilation time? Is this th=
e single argument?</blockquote><div><br></div><div>I suggest the following:=
</div><div><br></div><div>1) If apply_visitor is given an explicit result t=
ype, use that.</div><div>2) If apply_visitor is NOT given an explicit resul=
t type, use the explicit result type of the function object if one exists.<=
/div><div>3) If neither apply_visitor nor the function object have an expli=
cit result type, but all of the invocations would have the same result type=
, use that.</div><div>4) If none of the above are true, then we have a few =
final options:</div><div>=C2=A0 a) Produce a compile time error</div>=C2=A0=
 b) Return void or some stateless type<div>=C2=A0 c) Try to do some kind of=
 common type deduction</div><div><br></div><div>To be optimal with compile-=
times, which is something that becomes a serious consideration with variant=
s having many states and/or doing n-ary visitation for n &gt; 1, users woul=
d prefer option 1 or option 2, since otherwise the implied checking, especi=
ally if common type deduction is at play, could be considerable.</div></div=
></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113cdccec3b18b051fd1d960--

.

Le 16/09/15 01:50, 'Matt Calabrese' via ISO C++ Standard - Future=20
Proposals a =C3=A9crit :
> On Tue, Sep 15, 2015 at 4:12 PM, Vicente J. Botet Escriba <
> vicente.botet@wanadoo.fr> wrote:
>> I like the invocation traits proposal and I hope that it would be used b=
y
>> a lot of forwarding functions. Could someone confirm if it has been adop=
ted
>> for the next C++17 standard?
>> I don't see to which function do you want to apply the invocation traits=
..
>> IIUC, you want an overload function having the overloaded functions pass=
ed
>> by reference, isn't it?
>> Are you suggesting to apply these traits to the overloaded functions to
>> take care the references parameters?

Thanks for the pass by reference example. However I don't see yet where you=
 would like to use the invocation traits. Is on the operator() defined in t=
he resulting function object?

>   =20
>
> For a usage example:
>
> //////////
> struct function_with_state {
>    void operator ()(int arg) { invoked =3D true; }
>    bool invoked =3D false;
> };
>
> function_with_state foo;
>
> apply_visitor(forward_as_overloads(foo, [](a arg) { /**/ }),
> variant_instance);
>
> // You can now check foo.invoked;
> bool invoked =3D foo.invoked;
> //////////
>
> This is an obviously contrived example, but the underlying idea is that y=
ou
> want to be able to examine or continue modifying state that was mutated b=
y
> the visitation. Standard library algorithms like std::for_each effectivel=
y
> accomplish this by returning the function object, which also might be
> feasible if there were a form of apply_visitor that yielded the passed-in
> function object in addition to or in place of the result of the function
> object's invocation. Other reasons to prefer "tie_overloads" or
> "forward_as_overloads" would be when even a move is costly or simply does
> not exist.
>
> The closest equivalent to my above example using only "overload" that I c=
an
> think of off-hand would be something like:
>
> //////////
> struct function_with_state {
>    void operator ()(int arg) { invoked =3D true; }
>    bool invoked =3D false;
> };
>
> auto fun =3D overloads(function_with_state(), [](a arg) { /**/ };
> apply_visitor(std::ref(fun), variant_instance);
I will add the possibility to pass a reference_wrapper to the match=20
proposal (See D0050)
> // Assumes some way to access one of the contained "overload" functions.
> // Here I just use std::get with the type, but hypothetically it could be
> done
> // with std::get and an index, or some other way entirely. Obviously this
> // would need to be proposed.
> bool invoked =3D std::get<function_with_state>(fun).invoked;
> //////////
So you want that the result of overload behaves like a product type. I=20
will add this to the list of further work.
> On Tue, Sep 15, 2015 at 4:12 PM, Vicente J. Botet Escriba <
> vicente.botet@wanadoo.fr> wrote:
>
>> Yeah, I have implemented this already to cover exactly this use case: th=
e
>> users wants a specific return type.
>
> Great! I think this would be a good addition to a complete proposal.
>
> On Tue, Sep 15, 2015 at 4:12 PM, Vicente J. Botet Escriba <
> vicente.botet@wanadoo.fr> wrote:
>
>> How can apply_visitor take advantage of a function object that has a
>> unique return type for all the overloads? Do you pretend that apply_visi=
tor
>> works only with function objects that return a unique return types for a=
ll
>> the overloads? I hope not. Or that it can be able to detect if the funct=
ion
>> object has a nested typedef and it can avoid thus the whole deduction? D=
o
>> you believe that this would reduce consequently the compilation time? Is
>> this the single argument?
>
> I suggest the following:
>
> 1) If apply_visitor is given an explicit result type, use that.
> 2) If apply_visitor is NOT given an explicit result type, use the explici=
t
> result type of the function object if one exists.
OK, up to this point we don't need to calculate the Cartesian product of=20
all the sum type alternatives to have the type of the possible=20
invocations. I will add this to the match proposal and check the=20
compilation times.
> 3) If neither apply_visitor nor the function object have an explicit resu=
lt
> type, but all of the invocations would have the same result type, use tha=
t.
This would need to calculate the Cartesian product only lazily, and stop=20
as soon as the types are not all the same.
> 4) If none of the above are true, then we have a few final options:
>    a) Produce a compile time error
>    b) Return void or some stateless type
>    c) Try to do some kind of common type deduction
This would need to calculate the Cartesian product only lazily, and stop=20
as soon as there is no a common type.
We could provide a meta-function that folds the Cartesian product of all=20
the sum type alternatives and applies a SFINAE friendly type=20
transformation. For 3) we need  same<A,B>::type and for 4) c) we need=20
common_type<A,B>::type.

I will add 3) and 4) in Further work section to the match proposal until=20
I implement them.
> To be optimal with compile-times, which is something that becomes a serio=
us
> consideration with variants having many states and/or doing n-ary
> visitation for n > 1, users would prefer option 1 or option 2, since
> otherwise the implied checking, especially if common type deduction is at
> play, could be considerable.
>
Got it.

Vicente

P.S. Please see the update on the same address=20
https://github.com/viboes/tags/blob/master/doc/proposals/overload/D0051.pdf

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_3405_918846413.1442417777631
Content-Type: multipart/alternative;
 boundary="----=_Part_3406_1336868641.1442417777631"

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

Perhaps you should focus your examples on cases where an inline struct=20
wouldn't be a better fit:

struct
{
  auto operator()(int i, int j ) { =E2=80=A6 }
  auto operator()(int i, string const &j ) { =E2=80=A6 }
  template<typename T, typename U>
    auto operator()(const T&i, const U&j ) { =E2=80=A6 }
) visitor;

visitor(1, std::string{"2"});

At the very least, the proposal should talk about why `overload` is needed=
=20
in the face of being able to use in-function structs like this.=20
`first_overload` changes the resolution rules, so it has utility that can't=
=20
be matched by the compiler.

But the use cases of `overload` over an in-function struct like this are=20
relatively few. It's useful mostly for the features of lambdas: variable=20
captures, automatic friendship, access to `this`, and so forth. So the=20
proposal should explain when you need `overload` compared to a struct.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">Perhaps you should focus your examples on cases where an i=
nline struct wouldn&#39;t be a better fit:<br><br><div class=3D"prettyprint=
" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187=
, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color=
: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">operator</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">()(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> i</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">int</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> j </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">=E2=80=A6</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">operator</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">()(</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> i</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">string</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">j </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=E2=80=A6<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> U</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">operator=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()(</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">i</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">const</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> U</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">j <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">=E2=80=A6</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> visi=
tor</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>visitor<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">::</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">string</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">{</span><span style=3D"color: #080;" class=3D"styled-by=
-prettify">&quot;2&quot;</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">});</span></div></code></div><br>At the very least, the propo=
sal should talk about why `overload` is needed in the face of being able to=
 use in-function structs like this. `first_overload` changes the resolution=
 rules, so it has utility that can&#39;t be matched by the compiler.<br><br=
>But the use cases of `overload` over an in-function struct like this are r=
elatively few. It&#39;s useful mostly for the features of lambdas: variable=
 captures, automatic friendship, access to `this`, and so forth. So the pro=
posal should explain when you need `overload` compared to a struct.<br></di=
v>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3406_1336868641.1442417777631--
------=_Part_3405_918846413.1442417777631--

.

Le 16/09/15 17:36, Nicol Bolas a =C3=A9crit :
> Perhaps you should focus your examples on cases where an inline struct
> wouldn't be a better fit:
>
> struct
> {
>    auto operator()(int i, int j ) { =E2=80=A6 }
>    auto operator()(int i, string const &j ) { =E2=80=A6 }
>    template<typename T, typename U>
>      auto operator()(const T&i, const U&j ) { =E2=80=A6 }
> ) visitor;
>
> visitor(1, std::string{"2"});
>
> At the very least, the proposal should talk about why `overload` is neede=
d
> in the face of being able to use in-function structs like this.
You are right but I believed that it was evident.
First, overload can combine existing functions,
second, even if we have only lambdas, this allows us to define the=20
functions as close as possible where they are used,
third, each overload can have its own data.
> `first_overload` changes the resolution rules, so it has utility that can=
't
> be matched by the compiler.
>
> But the use cases of `overload` over an in-function struct like this are
> relatively few. It's useful mostly for the features of lambdas: variable
> captures, automatic friendship, access to `this`, and so forth. So the
> proposal should explain when you need `overload` compared to a struct.
>
I'll try to add it.
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/.

.

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

On Wed, Sep 16, 2015 at 4:14 AM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:

> Le 16/09/15 01:50, 'Matt Calabrese' via ISO C++ Standard - Future
> Proposals a =C3=A9crit :
>
>> On Tue, Sep 15, 2015 at 4:12 PM, Vicente J. Botet Escriba <
>> vicente.botet@wanadoo.fr> wrote:
>>
>>> I like the invocation traits proposal and I hope that it would be used =
by
>>> a lot of forwarding functions. Could someone confirm if it has been
>>> adopted
>>> for the next C++17 standard?
>>> I don't see to which function do you want to apply the invocation trait=
s.
>>> IIUC, you want an overload function having the overloaded functions
>>> passed
>>> by reference, isn't it?
>>> Are you suggesting to apply these traits to the overloaded functions to
>>> take care the references parameters?
>>>
>>
> Thanks for the pass by reference example. However I don't see yet where
> you would like to use the invocation traits. Is on the operator() defined
> in the resulting function object?


Yeah. The invocation traits proposal specified a (intrinsic-based) template
metafunction that you give a function object type as well as argument
types, and it yields a constexpr pointer to the member function that would
be invoked if given those arguments. Anyway, the more I think about it, I'm
pretty sure that you'd only be able to get a solution that "usually" works
by way of this trait anyway, so it's probably just not feasible to
implement the tied forms even with the proposed invocation traits.


> I will add the possibility to pass a reference_wrapper to the match
> proposal (See D0050)
>
>> // Assumes some way to access one of the contained "overload" functions.
>> // Here I just use std::get with the type, but hypothetically it could b=
e
>> done
>> // with std::get and an index, or some other way entirely. Obviously thi=
s
>> // would need to be proposed.
>> bool invoked =3D std::get<function_with_state>(fun).invoked;
>> //////////
>>
> So you want that the result of overload behaves like a product type. I
> will add this to the list of further work.


Yes. If one or more of the function object's has state, it would be useful
if there were a direct way to access it.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Sep 16, 2015 at 4:14 AM, Vicente J. Botet Escriba <span dir=3D"ltr">&lt=
;<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicente.bote=
t@wanadoo.fr</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le 16/=
09/15 01:50, &#39;Matt Calabrese&#39; via ISO C++ Standard - Future Proposa=
ls a =C3=A9crit :<span class=3D""><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Tue, Sep 15, 2015 at 4:12 PM, Vicente J. Botet Escriba &lt;<br>
<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicente.botet=
@wanadoo.fr</a>&gt; wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I like the invocation traits proposal and I hope that it would be used by<b=
r>
a lot of forwarding functions. Could someone confirm if it has been adopted=
<br>
for the next C++17 standard?<br>
I don&#39;t see to which function do you want to apply the invocation trait=
s.<br>
IIUC, you want an overload function having the overloaded functions passed<=
br>
by reference, isn&#39;t it?<br>
Are you suggesting to apply these traits to the overloaded functions to<br>
take care the references parameters?<br>
</blockquote></blockquote>
<br></span>
Thanks for the pass by reference example. However I don&#39;t see yet where=
 you would like to use the invocation traits. Is on the operator() defined =
in the resulting function object?</blockquote><div><br></div><div>Yeah. The=
 invocation traits proposal specified a (intrinsic-based) template metafunc=
tion that you give a function object type as well as argument types, and it=
 yields a constexpr pointer to the member function that would be invoked if=
 given those arguments. Anyway, the more I think about it, I&#39;m pretty s=
ure that you&#39;d only be able to get a solution that &quot;usually&quot; =
works by way of this trait anyway, so it&#39;s probably just not feasible t=
o implement the tied forms even with the proposed invocation traits.</div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">
I will add the possibility to pass a reference_wrapper to the match proposa=
l (See D0050)<span class=3D""><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
// Assumes some way to access one of the contained &quot;overload&quot; fun=
ctions.<br>
// Here I just use std::get with the type, but hypothetically it could be<b=
r>
done<br>
// with std::get and an index, or some other way entirely. Obviously this<b=
r>
// would need to be proposed.<br>
bool invoked =3D std::get&lt;function_with_state&gt;(fun).invoked;<br>
//////////<br>
</blockquote></span>
So you want that the result of overload behaves like a product type. I will=
 add this to the list of further work.</blockquote><div><br></div><div>Yes.=
 If one or more of the function object&#39;s has state, it would be useful =
if there were a direct way to access it.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b47274e1743ce051fe2b854--

.

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

Le 15/09/15 21:52, Vicente J. Botet Escriba a =C3=A9crit :
> Hi,
>
>  [1]  proposes two functions that allow to overload lambdas and=20
> function objects, but also member and non-member functions.
>
> * overload selects the best overload using C++ overload resolution and
> * first_overload selects the first overload using C++ overload=20
> resolution.
>
> Any feedback is welcome.
>
> Vicente Botet
>
> [1]=20
> https://github.com/viboes/tags/blob/master/doc/proposals/overload/D0051.p=
df
>
Hi,


I have updated the proposal taking in account I hope all the comments.=20
Same link.

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

--------------010703010003080300050406
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 15/09/15 21:52, Vicente J. Botet
      Escriba a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote cite=3D"mid:55F8771B.1090108@wanadoo.fr" type=3D"cite">Hi,
      <br>
      <br>
      =C2=A0[1]=C2=A0 proposes two functions that allow to overload lambdas=
 and
      function objects, but also member and non-member functions.
      <br>
      <br>
      * overload selects the best overload using C++ overload resolution
      and
      <br>
      * first_overload selects the first overload using C++ overload
      resolution.
      <br>
      <br>
      Any feedback is welcome.
      <br>
      <br>
      Vicente Botet
      <br>
      <br>
      [1]
<a class=3D"moz-txt-link-freetext" href=3D"https://github.com/viboes/tags/b=
lob/master/doc/proposals/overload/D0051.pdf">https://github.com/viboes/tags=
/blob/master/doc/proposals/overload/D0051.pdf</a><br>
      <br>
    </blockquote>
    <font size=3D"+1">Hi,<br>
      <br>
      <br>
      I have updated the proposal taking in account I hope all the
      comments. Same link.<br>
      <br>
      Vicente</font>
  </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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--------------010703010003080300050406--

.