Topic: n4560: tagged_tuple and unnamed structs
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 30 Dec 2015 14:20:32 +0100
Raw View
This is a multi-part message in MIME format.
--------------060305090904080704020000
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Hi,
n4560 introduce the classes tagged, tagged_pair and tagged_tuple. Here=20
follows the rationale as described in n4560:
/[Editor=E2=80=99s note: This type exists so that the algorithms can return=
=20
pair- and tuple-like objects with named accessors, as requested by LEWG.=20
Rather than create a bunch of one-off class types with no relation to=20
pair and tuple, I opted instead to create a general utility. I=E2=80=99ll n=
ote=20
that this functionality can be merged into pair and tuple directly with=20
minimal breakage, but I opted for now to keep it separate.]//
/
I was wondering if
tagged_pair<tag::in(I), tag::fun(Fun)>
couldn't be better be represented by the unnamed aggregate
struct {
I in;
Fun fun;
}
which has less noise.
There is a syntactic issue however. While it is correct to declare a=20
variable of an unnamed struct as in
struct {
int first;
int second;
} p {1, 2};
assert(p.first =3D=3D 1);
assert(p.second =3D=3D 2);
I'm getting a compile error while trying to return an unnamed struct=20
from a function (I don't know where in the standard this limitation appears=
)
struct { // ERROR
int first;
int second;
}
a_pair()
{
return {1, -1};
}
error: '(anonymous struct at pair_pass.cpp:91:7)' cannot be defined in=20
the result type of a function
struct {
Note that we can use an alias to fix the compile error
using Named =3D
struct {
int first;
int second;
};
Named
a_pair()
{
return {1, -1}; // OK
}
As stated in=20
http://stackoverflow.com/questions/8026579/can-anonymous-class-be-used-as-r=
eturn-types-in-c,=20
returning unnamed structs worked in gcc-4.5.2.
This will be close to having function returning multiple values.
Is there any reason to don't support functions/lambdas returning unnamed=20
structs?
If the standard allowed them, do you think that they could replace the=20
proposed tagged_ classes in the Range TS?
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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--------------060305090904080704020000
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
Hi,<br>
<br>
n4560 introduce the classes tagged, tagged_pair and tagged_tuple.
Here follows the rationale as described in n4560:<br>
<meta charset=3D"utf-8">
<br>
<i>[Editor=E2=80=99s note: This type exists so that the algorithms can
return pair- and tuple-like objects with named
accessors, as requested by LEWG. Rather than create a bunch of
one-off class types with no relation to pair
and tuple, I opted instead to create a general utility. I=E2=80=99ll =
note
that this functionality can be merged into
pair and tuple directly with minimal breakage, but I opted for now
to keep it separate.]</i><i><br>
</i><br>
<br>
I was wondering if<br>
<br>
=C2=A0=C2=A0=C2=A0 tagged_pair<tag::in(I), tag::fun(Fun)><br>
<br>
couldn't be better be represented by the unnamed aggregate<br>
<br>
=C2=A0=C2=A0=C2=A0 struct {<br>
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 I in;<br>
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Fun fun;<br>
=C2=A0=C2=A0=C2=A0 }<br>
<br>
which has less noise.<br>
<br>
There is a syntactic issue however. While it is correct to declare a
variable of an unnamed struct as in<br>
<br>
=C2=A0=C2=A0=C2=A0 struct {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int first;<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int second;<br>
=C2=A0=C2=A0=C2=A0 } p {1, 2};<br>
=C2=A0=C2=A0=C2=A0 assert(p.first =3D=3D 1);<br>
=C2=A0=C2=A0=C2=A0 assert(p.second =3D=3D 2);<br>
<br>
I'm getting a compile error while trying to return an unnamed struct
from a function (I don't know where in the standard this limitation
appears)<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct {=C2=A0=C2=A0 // ERROR<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int first;<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int second;<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a_pair()<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return {1, -1};<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>
<br>
error: '(anonymous struct at pair_pass.cpp:91:7)' cannot be defined
in the result type of a function<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct {<br>
<br>
<br>
Note that we can use an alias to fix the compile error<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 using Named =3D<br>
=C2=A0=C2=A0=C2=A0=C2=A0 struct {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int first;<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int second;<br>
=C2=A0=C2=A0=C2=A0=C2=A0 };<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 Named<br>
=C2=A0=C2=A0=C2=A0=C2=A0 a_pair()<br>
=C2=A0=C2=A0=C2=A0=C2=A0 {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return {1, -1};=C2=A0 // OK<=
br>
=C2=A0=C2=A0=C2=A0=C2=A0 }<br>
<br>
As stated in
<a class=3D"moz-txt-link-freetext" href=3D"http://stackoverflow.com/que=
stions/8026579/can-anonymous-class-be-used-as-return-types-in-c">http://sta=
ckoverflow.com/questions/8026579/can-anonymous-class-be-used-as-return-type=
s-in-c</a>,
returning unnamed structs worked in gcc-4.5.2.<br>
<br>
This will be close to having function returning multiple values.<br>
Is there any reason to don't support functions/lambdas returning
unnamed structs?<br>
<br>
If the standard allowed them, do you think that they could replace
the proposed tagged_ classes in the Range TS?<br>
<br>
Vicente<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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--------------060305090904080704020000--
.
Author: Giovanni Piero Deretta <gpderetta@gmail.com>
Date: Wed, 30 Dec 2015 06:24:57 -0800 (PST)
Raw View
------=_Part_529_336327052.1451485497433
Content-Type: multipart/alternative;
boundary="----=_Part_530_719875645.1451485497433"
------=_Part_530_719875645.1451485497433
Content-Type: text/plain; charset=UTF-8
On Wednesday, December 30, 2015 at 1:20:35 PM UTC, Vicente J. Botet Escriba
wrote:
>
> [...]
> I'm getting a compile error while trying to return an unnamed struct from
> a function (I don't know where in the standard this limitation appears)
>
> struct { // ERROR
> int first;
> int second;
> }
> a_pair()
> {
> return {1, -1};
> }
>
> error: '(anonymous struct at pair_pass.cpp:91:7)' cannot be defined in the
> result type of a function
> struct {
>
> [...]
> Is there any reason to don't support functions/lambdas returning unnamed
> structs?
>
This works in C++14:
auto a_pair ()
{
struct { int first; int second; } r {0, 1};
return r;
}
Is this similar to what you had in mind?
-- gpd
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_530_719875645.1451485497433
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, December 30, 2015 at 1:20:35 PM UTC, Vicente J. Botet Escriba=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
[...]<br>
I'm getting a compile error while trying to return an unnamed struc=
t
from a function (I don't know where in the standard this limitation
appears)<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct {=C2=A0=C2=A0 // ERROR<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int first;<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int second;<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a_pair()<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return {1, -1};<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>
<br>
error: '(anonymous struct at pair_pass.cpp:91:7)' cannot be def=
ined
in the result type of a function<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct {<br>
<br>
[...]<br>
Is there any reason to don't support functions/lambdas returning
unnamed structs?<br></div></blockquote><div><br>This works in C++14:<br=
><br>auto a_pair ()<br>{<br>=C2=A0=C2=A0 struct { int first; int second; } =
r {0, 1};<br>=C2=A0=C2=A0 return r;<br>}<br><br>Is this similar to what you=
had in mind?<br><br>-- gpd<br>=C2=A0</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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_530_719875645.1451485497433--
------=_Part_529_336327052.1451485497433--
.
Author: "T. C." <rs2740@gmail.com>
Date: Wed, 30 Dec 2015 11:20:58 -0800 (PST)
Raw View
------=_Part_6210_919335758.1451503259094
Content-Type: multipart/alternative;
boundary="----=_Part_6211_204296795.1451503259094"
------=_Part_6211_204296795.1451503259094
Content-Type: text/plain; charset=UTF-8
On Wednesday, December 30, 2015 at 8:20:35 AM UTC-5, Vicente J. Botet
Escriba wrote:
>
>
> I'm getting a compile error while trying to return an unnamed struct from
> a function (I don't know where in the standard this limitation appears)
>
>
[dcl.fct]/11:
Types shall not be defined in return or parameter types.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_6211_204296795.1451503259094
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Wednesday, December 30, 2015 at 8:20:35 AM UTC-5, Vicente J. Bot=
et Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><br>
I'm getting a compile error while trying to return an unnamed struc=
t
from a function (I don't know where in the standard this limitation
appears)<br><br></div></blockquote><div><br></div><div>[dcl.fct]/11:</d=
iv><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204);=
border-left-style: solid; padding-left: 1ex;">Types shall not be defined i=
n return or parameter types.</blockquote><div><br></div><div>=C2=A0</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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_6211_204296795.1451503259094--
------=_Part_6210_919335758.1451503259094--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 30 Dec 2015 14:38:37 -0500
Raw View
On 2015-12-30 14:20, T. C. wrote:
> On Wednesday, December 30, 2015 at 8:20:35 AM UTC-5, Vicente J. Botet
> Escriba wrote:
>> I'm getting a compile error while trying to return an unnamed struct from
>> a function (I don't know where in the standard this limitation appears)
>
> [dcl.fct]/11:
>
> Types shall not be defined in return or parameter types.
Bah. What's the reason for this restriction (which obviously isn't
enforced by all compilers)?
--
Matthew
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 30 Dec 2015 11:52:49 -0800 (PST)
Raw View
------=_Part_2007_1136480812.1451505169806
Content-Type: multipart/alternative;
boundary="----=_Part_2008_671653045.1451505169806"
------=_Part_2008_671653045.1451505169806
Content-Type: text/plain; charset=UTF-8
On Wednesday, December 30, 2015 at 2:39:01 PM UTC-5, Matthew Woehlke wrote:
>
> On 2015-12-30 14:20, T. C. wrote:
> > On Wednesday, December 30, 2015 at 8:20:35 AM UTC-5, Vicente J. Botet
> > Escriba wrote:
> >> I'm getting a compile error while trying to return an unnamed struct
> from
> >> a function (I don't know where in the standard this limitation appears)
> >
> > [dcl.fct]/11:
> >
> > Types shall not be defined in return or parameter types.
>
> Bah. What's the reason for this restriction (which obviously isn't
> enforced by all compilers)?
>
Well, to be honest, until C++11 there was basically no way to use such a
return value. Well, you could pass them to a function that uses template
argument deduction. But you could never locally declare such a variable. So
it probably wasn't considered useful.
Nobody probably considered that `auto` made such anonymous structs more
viable.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2008_671653045.1451505169806
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, December 30, 2015 at 2:39:01 PM UTC-5, Matth=
ew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-12-30=
14:20, T. C. wrote:
<br>> On Wednesday, December 30, 2015 at 8:20:35 AM UTC-5, Vicente J. Bo=
tet=20
<br>> Escriba wrote:
<br>>> I'm getting a compile error while trying to return an unna=
med struct from=20
<br>>> a function (I don't know where in the standard this limita=
tion appears)
<br>>
<br>> [dcl.fct]/11:
<br>>=20
<br>> Types shall not be defined in return or parameter types.
<br>
<br>Bah. What's the reason for this restriction (which obviously isn=
9;t
<br>enforced by all compilers)?
<br></blockquote><div><br>Well, to be honest, until C++11 there was basical=
ly no way to use such a return value. Well, you could pass them to a functi=
on that uses template argument deduction. But you could never locally decla=
re such a variable. So it probably wasn't considered useful.<br><br>Nob=
ody probably considered that `auto` made such anonymous structs more viable=
..<br></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" 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_2008_671653045.1451505169806--
------=_Part_2007_1136480812.1451505169806--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 30 Dec 2015 22:01:28 +0200
Raw View
On 30 December 2015 at 21:52, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, December 30, 2015 at 2:39:01 PM UTC-5, Matthew Woehlke wrote:
>>
>> On 2015-12-30 14:20, T. C. wrote:
>> > On Wednesday, December 30, 2015 at 8:20:35 AM UTC-5, Vicente J. Botet
>> > Escriba wrote:
>> >> I'm getting a compile error while trying to return an unnamed struct
>> >> from
>> >> a function (I don't know where in the standard this limitation appears)
>> >
>> > [dcl.fct]/11:
>> >
>> > Types shall not be defined in return or parameter types.
>>
>> Bah. What's the reason for this restriction (which obviously isn't
>> enforced by all compilers)?
>
>
> Well, to be honest, until C++11 there was basically no way to use such a
> return value. Well, you could pass them to a function that uses template
> argument deduction. But you could never locally declare such a variable. So
> it probably wasn't considered useful.
>
> Nobody probably considered that `auto` made such anonymous structs more
> viable.
If auto isn't used, we should remember that functions can have
multiple declarations,
so latter declarations should be grokked to have the same
defined-in-return-type return
type. For members of class templates, and with any number of aliases between the
class template definition and the outside-class-template-definition
definition of a member of
a class template, the equivalence of return types gets fairly complex
fairly quickly.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 30 Dec 2015 21:04:11 +0100
Raw View
This is a multi-part message in MIME format.
--------------080002020004080605020104
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 30/12/2015 20:20, T. C. a =C3=A9crit :
>
>
> On Wednesday, December 30, 2015 at 8:20:35 AM UTC-5, Vicente J. Botet=20
> Escriba wrote:
>
>
> I'm getting a compile error while trying to return an unnamed
> struct from a function (I don't know where in the standard this
> limitation appears)
>
>
> [dcl.fct]/11:
>
> Types shall not be defined in return or parameter types.
>
>
>
Thaks for the pointer.
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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--------------080002020004080605020104
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 30/12/2015 20:20, T. C. a =C3=A9crit=
=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:ed838ea6-5462-4ec6-a8c6-592db36968b6@isocpp.org"
type=3D"cite"><br>
<br>
On Wednesday, December 30, 2015 at 8:20:35 AM UTC-5, Vicente J.
Botet Escriba wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><br>
I'm getting a compile error while trying to return an unnamed
struct from a function (I don't know where in the standard
this limitation appears)<br>
<br>
</div>
</blockquote>
<div><br>
</div>
<div>[dcl.fct]/11:</div>
<div><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;">Types shall not be
defined in return or parameter types.</blockquote>
<div><br>
</div>
<div>=C2=A0</div>
<br>
</blockquote>
Thaks for the pointer.<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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--------------080002020004080605020104--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 30 Dec 2015 15:40:58 -0500
Raw View
On 2015-12-30 15:01, Ville Voutilainen wrote:
> On 30 December 2015 at 21:52, Nicol Bolas wrote:
>> On Wednesday, December 30, 2015 at 2:39:01 PM UTC-5, Matthew Woehlke wro=
te:
>>> On 2015-12-30 14:20, T. C. wrote:
>>>> On Wednesday, December 30, 2015 at 8:20:35 AM UTC-5, Vicente J. Botet
>>>> Escriba wrote:
>>>> [dcl.fct]/11:
>>>>
>>>> Types shall not be defined in return or parameter types.
>>>
>>> Bah. What's the reason for this restriction (which obviously isn't
>>> enforced by all compilers)?
>>
>> Well, to be honest, until C++11 there was basically no way to use
>> such a return value. [...] Nobody probably considered that `auto`
>> made such anonymous structs more viable.
:-)
> If auto isn't used, we should remember that functions can have=20
> multiple declarations, so latter declarations should be grokked to
> have the same defined-in-return-type return type. For members of
> class templates, and with any number of aliases between the class
> template definition and the outside-class-template-definition=20
> definition of a member of a class template, the equivalence of return
> types gets fairly complex fairly quickly.
Agreed; IRTVPDUA=C2=B9 by itself may be useful, but relaxing [dcl.fct]/11
without IRTVPDUA is likely to be obnoxious. Certainly I don't intend to
propose that the standard enforce that two anonymous structs having the
same layout and being used as return types for the same (not considering
return type) function signature are the same type. I won't gripe if
compilers want to do that=C2=B2, but I don't think it should be required.
(=C2=B9 Inferred Return Type Via Previous Declaration, Using Auto)
(=C2=B2 FWIW, I don't think this is as hard as it sounds; compilers ought t=
o
be able to easily enough compare the canonical function signatures.)
--=20
Matthew
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Wed, 30 Dec 2015 15:02:44 -0800 (PST)
Raw View
------=_Part_4246_2124079195.1451516564660
Content-Type: multipart/alternative;
boundary="----=_Part_4247_1260138124.1451516564661"
------=_Part_4247_1260138124.1451516564661
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I think that returning by unnamed struct is the best way to return multiple=
=20
values proposed so far. A pity that it is a non-standard feature (that=20
Microsoft's compiler supports). The MSVC support is however very shallow,=
=20
this does not work:
struct { int x; const char* y; } foo()
{
return { 1, "Hej" };
}
struct { int y; const char* x; } fum()
{
return foo(); // ERROR: 'return': cannot convert from '' to ''
}
As suspected aligning the member names does not help either.
So, the question is: How hard would it be to define that this should work=
=20
-- and how. I guess that this should be limited to POD structs and that the=
=20
type of two unnamed structs should be considered compatible iff the list of=
=20
types of data members are the same.
Actually, to solve the problem that the original proposer imagined the std=
=20
algorithms in question could be changed to return a named struct and then=
=20
the tuple access methods get<> and tuple_element<> could be overloaded for=
=20
these struct types to handle backwards compatibility, complemented by a=20
cast operator to the original tuple type. This covers most of the=20
compatibility issues without language change. It is of course possible to=
=20
construct code that reveals the standard change but these should be very=20
rare in production code. Something like this:
template<typename Iter> struct equal_range_return {
Iter first;
Iter last;
operator pair<Iter, Iter>() { return { first, last }; }
};
template<int N, typename Iter> struct get_return_helper {
};
template<typename Iter> struct get_return_helper<0, Iter> {
Iter get(equal_range_return<Iter>& range) { return range.first; }
};
template<typename Iter> struct get_return_helper<1, Iter> {
Iter get(equal_range_return<Iter>& range) { return range.last; }
};
template<int N, typename Iter> Iter get(equal_range_return<Iter>& range) {
return get_return_helper<N, Iter>::get(range);
}
template<int N, typename Iter> using tuple_element_t =3D Iter;
template<typename Iter, typename T> equal_range_return<Iter>=20
equal_range(Iter from, Iter to, const T& value);
Note however that all of this is just to rename 'second' to 'last' in=20
std::equal_range. For std::mismatch the names first and second are actually=
=20
hard to better... I didn't find any other std algorithms that return two or=
=20
more values.
Given these possibilities I don't think that the rather large machinery=20
needed to introduce a second way to name members of aggregates as proposed=
=20
in N4560 is warranted. The use case is rather weak from the onset, and as=
=20
it can be emulated quite easily as shown with only minor backwards=20
compatibility issues I would not support such a proposal (if I had a say).
Allowing return by anonymous struct in a more complete way than Microsoft=
=20
currently supports has a much wider applicability and seems like a better=
=20
proposal to put work into. It also has the advantage of removing a=20
non-orthogonal restriction from the standard rather than adding a new=20
feature which increases the learning curve.
Den onsdag 30 december 2015 kl. 21:41:09 UTC+1 skrev Matthew Woehlke:
>
> On 2015-12-30 15:01, Ville Voutilainen wrote:=20
> > On 30 December 2015 at 21:52, Nicol Bolas wrote:=20
> >> On Wednesday, December 30, 2015 at 2:39:01 PM UTC-5, Matthew Woehlke=
=20
> wrote:=20
> >>> On 2015-12-30 14:20, T. C. wrote:=20
> >>>> On Wednesday, December 30, 2015 at 8:20:35 AM UTC-5, Vicente J. Bote=
t=20
> >>>> Escriba wrote:=20
> >>>> [dcl.fct]/11:=20
> >>>>=20
> >>>> Types shall not be defined in return or parameter types.=20
> >>>=20
> >>> Bah. What's the reason for this restriction (which obviously isn't=20
> >>> enforced by all compilers)?=20
> >>=20
> >> Well, to be honest, until C++11 there was basically no way to use=20
> >> such a return value. [...] Nobody probably considered that `auto`=20
> >> made such anonymous structs more viable.=20
>
> :-)=20
>
> > If auto isn't used, we should remember that functions can have=20
> > multiple declarations, so latter declarations should be grokked to=20
> > have the same defined-in-return-type return type. For members of=20
> > class templates, and with any number of aliases between the class=20
> > template definition and the outside-class-template-definition=20
> > definition of a member of a class template, the equivalence of return=
=20
> > types gets fairly complex fairly quickly.=20
>
> Agreed; IRTVPDUA=C2=B9 by itself may be useful, but relaxing [dcl.fct]/11=
=20
> without IRTVPDUA is likely to be obnoxious. Certainly I don't intend to=
=20
> propose that the standard enforce that two anonymous structs having the=
=20
> same layout and being used as return types for the same (not considering=
=20
> return type) function signature are the same type. I won't gripe if=20
> compilers want to do that=C2=B2, but I don't think it should be required.=
=20
>
> (=C2=B9 Inferred Return Type Via Previous Declaration, Using Auto)=20
>
> (=C2=B2 FWIW, I don't think this is as hard as it sounds; compilers ought=
to=20
> be able to easily enough compare the canonical function signatures.)=20
>
> --=20
> Matthew=20
>
>
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
------=_Part_4247_1260138124.1451516564661
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think that returning by unnamed struct is the best way t=
o return multiple values proposed so far. A pity that it is a non-standard =
feature (that Microsoft's compiler supports). The MSVC support is howev=
er very shallow, this does not work:<div><br></div><div><div><br></div><div=
>struct { int x; const char* y; } foo()</div><div>{</div><div><span class=
=3D"Apple-tab-span" style=3D"white-space:pre"> </span>return { 1, "Hej=
" };</div><div>}</div><div><br></div><div>struct { int y; const char* =
x; } fum()</div><div>{</div><div><span class=3D"Apple-tab-span" style=3D"wh=
ite-space:pre"> </span>return foo(); =C2=A0 =C2=A0 // ERROR: 'return=
9;: cannot convert from '' to ''</div><div>}</div><div><br>=
</div><div>As suspected aligning the member names does not help either.</di=
v><div><br></div><div>So, the question is: How hard would it be to define t=
hat this should work -- and how. I guess that this should be limited to POD=
structs and that the type of two unnamed structs should be considered comp=
atible iff the list of types of data members are the same.</div><div><br></=
div><div>Actually, to solve the problem that the original proposer imagined=
the std algorithms in question could be changed to return a named struct a=
nd then the tuple access methods get<> and tuple_element<> coul=
d be overloaded for these struct types to handle backwards compatibility, c=
omplemented by a cast operator to the original tuple type. This covers most=
of the compatibility issues without language change. It is of course possi=
ble to construct code that reveals the standard change but these should be =
very rare in production code. Something like this:</div><div><br></div><div=
><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); =
word-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><div class=3D"subprettyprint=
"><font color=3D"#660066"><br></font></div><div class=3D"subprettyprint"><f=
ont color=3D"#660066">template<typename Iter> struct equal_range_retu=
rn {</font></div><div class=3D"subprettyprint"><font color=3D"#660066"><spa=
n class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>Iter first;</f=
ont></div><div class=3D"subprettyprint"><font color=3D"#660066"><span class=
=3D"Apple-tab-span" style=3D"white-space:pre"> </span>Iter last;</font></di=
v><div class=3D"subprettyprint"><font color=3D"#660066"><span class=3D"Appl=
e-tab-span" style=3D"white-space:pre"> </span>operator pair<Iter, Iter&g=
t;() { return { first, last }; }</font></div><div class=3D"subprettyprint">=
<font color=3D"#660066">};</font></div><div class=3D"subprettyprint"><font =
color=3D"#660066"><br></font></div><div class=3D"subprettyprint"><font colo=
r=3D"#660066">template<int N, typename Iter> struct get_return_helper=
{</font></div><div class=3D"subprettyprint"><font color=3D"#660066">};</fo=
nt></div><div class=3D"subprettyprint"><font color=3D"#660066">template<=
typename Iter> struct get_return_helper<0, Iter> {</font></div><di=
v class=3D"subprettyprint"><font color=3D"#660066"><span class=3D"Apple-tab=
-span" style=3D"white-space:pre"> </span>Iter get(equal_range_return<Ite=
r>& range) { return range.first; }</font></div><div class=3D"subpret=
typrint"><font color=3D"#660066">};</font></div><div class=3D"subprettyprin=
t"><font color=3D"#660066">template<typename Iter> struct get_return_=
helper<1, Iter> {</font></div><div class=3D"subprettyprint"><font col=
or=3D"#660066"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </=
span>Iter get(equal_range_return<Iter>& range) { return range.las=
t; }</font></div><div class=3D"subprettyprint"><font color=3D"#660066">};</=
font></div><div class=3D"subprettyprint"><font color=3D"#660066"><br></font=
></div><div class=3D"subprettyprint"><font color=3D"#660066">template<in=
t N, typename Iter> Iter get(equal_range_return<Iter>& range) =
{</font></div><div class=3D"subprettyprint"><font color=3D"#660066"><span c=
lass=3D"Apple-tab-span" style=3D"white-space:pre"> </span>return get_return=
_helper<N, Iter>::get(range);</font></div><div class=3D"subprettyprin=
t"><font color=3D"#660066">}</font></div><div class=3D"subprettyprint"><fon=
t color=3D"#660066"><br></font></div><div class=3D"subprettyprint"><font co=
lor=3D"#660066">template<int N, typename Iter> using tuple_element_t =
=3D Iter;</font></div><div class=3D"subprettyprint"><font color=3D"#660066"=
><br></font></div><div class=3D"subprettyprint"><font color=3D"#660066">tem=
plate<typename Iter, typename T> equal_range_return<Iter> equal=
_range(Iter from, Iter to, const T& value);</font></div><div><br></div>=
</div></code></div><div><br></div>Note however that all of this is just to =
rename 'second' to 'last' in std::equal_range. For std::mis=
match the names first and second are actually hard to better... I didn'=
t find any other std algorithms that return two or more values.<br><br></di=
v><div>Given these possibilities I don't think that the rather large ma=
chinery needed to introduce a second way to name members of aggregates as p=
roposed in N4560 is warranted. The use case is rather weak from the onset, =
and as it can be emulated quite easily as shown with only minor backwards c=
ompatibility issues I would not support such a proposal (if I had a say).</=
div><div><br></div><div>Allowing return by anonymous struct in a more compl=
ete way than Microsoft currently supports has a much wider applicability an=
d seems like a better proposal to put work into. It also has the advantage =
of removing a non-orthogonal restriction from the standard rather than addi=
ng a new feature which increases the learning curve.</div><div><br></div><d=
iv><br></div><br>Den onsdag 30 december 2015 kl. 21:41:09 UTC+1 skrev Matth=
ew Woehlke:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-12-30 15:01=
, Ville Voutilainen wrote:
<br>> On 30 December 2015 at 21:52, Nicol Bolas wrote:
<br>>> On Wednesday, December 30, 2015 at 2:39:01 PM UTC-5, Matthew W=
oehlke wrote:
<br>>>> On 2015-12-30 14:20, T. C. wrote:
<br>>>>> On Wednesday, December 30, 2015 at 8:20:35 AM UTC-5, V=
icente J. Botet
<br>>>>> Escriba wrote:
<br>>>>> [dcl.fct]/11:
<br>>>>>
<br>>>>> Types shall not be defined in return or parameter type=
s.
<br>>>>
<br>>>> Bah. What's the reason for this restriction (which obv=
iously isn't
<br>>>> enforced by all compilers)?
<br>>>
<br>>> Well, to be honest, until C++11 there was basically no way to =
use
<br>>> such a return value. [...] Nobody probably considered that `au=
to`
<br>>> made such anonymous structs more viable.
<br>
<br>:-)
<br>
<br>> If auto isn't used, we should remember that functions can have=
=20
<br>> multiple declarations, so latter declarations should be grokked to
<br>> have the same defined-in-return-type return type. For members of
<br>> class templates, and with any number of aliases between the class
<br>> template definition and the outside-class-template-<wbr>definition=
=20
<br>> definition of a member of a class template, the equivalence of ret=
urn
<br>> types gets fairly complex fairly quickly.
<br>
<br>Agreed; IRTVPDUA=C2=B9 by itself may be useful, but relaxing [dcl.fct]/=
11
<br>without IRTVPDUA is likely to be obnoxious. Certainly I don't inten=
d to
<br>propose that the standard enforce that two anonymous structs having the
<br>same layout and being used as return types for the same (not considerin=
g
<br>return type) function signature are the same type. I won't gripe if
<br>compilers want to do that=C2=B2, but I don't think it should be req=
uired.
<br>
<br>(=C2=B9 Inferred Return Type Via Previous Declaration, Using Auto)
<br>
<br>(=C2=B2 FWIW, I don't think this is as hard as it sounds; compilers=
ought to
<br>be able to easily enough compare the canonical function signatures.)
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></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" 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_4247_1260138124.1451516564661--
------=_Part_4246_2124079195.1451516564660--
.
Author: "T. C." <rs2740@gmail.com>
Date: Wed, 30 Dec 2015 15:24:23 -0800 (PST)
Raw View
------=_Part_787_1065929006.1451517863908
Content-Type: multipart/alternative;
boundary="----=_Part_788_977822655.1451517863908"
------=_Part_788_977822655.1451517863908
Content-Type: text/plain; charset=UTF-8
On Wednesday, December 30, 2015 at 6:02:45 PM UTC-5, Bengt Gustafsson wrote:
> The MSVC support is however very shallow, this does not work:
Distinct unnamed struct definitions create distinct types. This assertion
doesn't fire:
typedef struct { int i; } A;
typedef struct { int i; } B;
static_assert(!std::is_same<A, B>{}, "");
If they were the same type, you'd violate [basic.def.odr]/1: "No
translation unit shall contain more than one definition of any [...] class
type [...]."
Creating a special rule for just function return types seems questionable
at best.
> Note however that all of this is just to rename 'second' to 'last' in
> std::equal_range. For std::mismatch the names first and second are actually
> hard to better... I didn't find any other std algorithms that return two or
> more values.
>
minmax. minmax_element. partition_copy.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_788_977822655.1451517863908
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Wednesday, December 30, 2015 at 6:02:45 PM UTC-5, B=
engt Gustafsson wrote:<div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 2=
04, 204); border-left-style: solid; padding-left: 1ex;">The MSVC support is=
however very shallow, this does not work:</blockquote><div><br></div><div>=
Distinct unnamed struct definitions create distinct types. This assertion d=
oesn't fire:</div><div><br></div><div class=3D"prettyprint" style=3D"bo=
rder: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-color=
: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyp=
rint"><span style=3D"color: #008;" class=3D"styled-by-prettify">typedef</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #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"> i</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">}</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> A</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">typedef</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">struct</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</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"> i</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"col=
or: #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"> B</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>static_assert</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(!</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">is_same</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">A</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> B</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">>{},</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-p=
rettify">""</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">);</span></div></code></div><div><br></div><div>If they were the=
same type, you'd violate [basic.def.odr]/1: "No translation unit =
shall contain more than one definition of any [...] class type [...]."=
</div><div><br></div><div>Creating a special rule for just function return =
types seems questionable at best.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div>Note however that al=
l of this is just to rename 'second' to 'last' in std::equa=
l_range. For std::mismatch the names first and second are actually hard to =
better... I didn't find any other std algorithms that return two or mor=
e values.<br></div></div></div></blockquote><div><br></div><div>minmax. min=
max_element.=C2=A0partition_copy.</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" 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_788_977822655.1451517863908--
------=_Part_787_1065929006.1451517863908--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 30 Dec 2015 17:51:59 -0800 (PST)
Raw View
------=_Part_1553_1818529117.1451526719665
Content-Type: multipart/alternative;
boundary="----=_Part_1554_805090558.1451526719665"
------=_Part_1554_805090558.1451526719665
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, December 30, 2015 at 6:02:45 PM UTC-5, Bengt Gustafsson wrote=
:
>
> I think that returning by unnamed struct is the best way to return=20
> multiple values proposed so far. A pity that it is a non-standard feature=
=20
> (that Microsoft's compiler supports). The MSVC support is however very=20
> shallow, this does not work:
>
>
> struct { int x; const char* y; } foo()
> {
> return { 1, "Hej" };
> }
>
> struct { int y; const char* x; } fum()
> {
> return foo(); // ERROR: 'return': cannot convert from '' to ''
> }
>
> As suspected aligning the member names does not help either.
>
> So, the question is: How hard would it be to define that this should work=
=20
> -- and how.
>
Very hard. Well, at least directly.
Building on what T. C., a *lot* of C++ seems built on the idea that each=20
type definition is distinct and that there is only one definition for each=
=20
type. To rewrite those rules would be... painful.
However, since we're specifically talking about a very specific case, it=20
*might* be reasonable to have a special rule that says that two anonymous=
=20
structs that are layout-compatible are not the same types, but they would=
=20
be "equivalent types". And two equivalent anonymous structs would be=20
implicitly convertible from one to the other (and can also participate in=
=20
elision where appropriate).
Any explicit conversions would of course take priority. Granted, explicit=
=20
conversions would require extreme trickery to declare (using `decltype` and=
=20
such).
=20
> I guess that this should be limited to POD structs and that the type of=
=20
> two unnamed structs should be considered compatible iff the list of types=
=20
> of data members are the same.
>
> Actually, to solve the problem that the original proposer imagined the st=
d=20
> algorithms in question could be changed to return a named struct and then=
=20
> the tuple access methods get<> and tuple_element<> could be overloaded fo=
r=20
> these struct types to handle backwards compatibility, complemented by a=
=20
> cast operator to the original tuple type. This covers most of the=20
> compatibility issues without language change. It is of course possible to=
=20
> construct code that reveals the standard change but these should be very=
=20
> rare in production code. Something like this:
>
>
> template<typename Iter> struct equal_range_return {
> Iter first;
> Iter last;
> operator pair<Iter, Iter>() { return { first, last }; }
> };
>
> template<int N, typename Iter> struct get_return_helper {
> };
> template<typename Iter> struct get_return_helper<0, Iter> {
> Iter get(equal_range_return<Iter>& range) { return range.first; }
> };
> template<typename Iter> struct get_return_helper<1, Iter> {
> Iter get(equal_range_return<Iter>& range) { return range.last; }
> };
>
> template<int N, typename Iter> Iter get(equal_range_return<Iter>& range) =
{
> return get_return_helper<N, Iter>::get(range);
> }
>
> template<int N, typename Iter> using tuple_element_t =3D Iter;
>
> template<typename Iter, typename T> equal_range_return<Iter>=20
> equal_range(Iter from, Iter to, const T& value);
>
>
> Note however that all of this is just to rename 'second' to 'last' in=20
> std::equal_range. For std::mismatch the names first and second are actual=
ly=20
> hard to better... I didn't find any other std algorithms that return two =
or=20
> more values.
>
> Given these possibilities I don't think that the rather large machinery=
=20
> needed to introduce a second way to name members of aggregates as propose=
d=20
> in N4560 is warranted. The use case is rather weak from the onset, and as=
=20
> it can be emulated quite easily as shown with only minor backwards=20
> compatibility issues I would not support such a proposal (if I had a say)=
..
>
> Allowing return by anonymous struct in a more complete way than Microsoft=
=20
> currently supports has a much wider applicability and seems like a better=
=20
> proposal to put work into. It also has the advantage of removing a=20
> non-orthogonal restriction from the standard rather than adding a new=20
> feature which increases the learning curve.
>
>
>
> Den onsdag 30 december 2015 kl. 21:41:09 UTC+1 skrev Matthew Woehlke:
>>
>> On 2015-12-30 15:01, Ville Voutilainen wrote:=20
>> > On 30 December 2015 at 21:52, Nicol Bolas wrote:=20
>> >> On Wednesday, December 30, 2015 at 2:39:01 PM UTC-5, Matthew Woehlke=
=20
>> wrote:=20
>> >>> On 2015-12-30 14:20, T. C. wrote:=20
>> >>>> On Wednesday, December 30, 2015 at 8:20:35 AM UTC-5, Vicente J.=20
>> Botet=20
>> >>>> Escriba wrote:=20
>> >>>> [dcl.fct]/11:=20
>> >>>>=20
>> >>>> Types shall not be defined in return or parameter types.=20
>> >>>=20
>> >>> Bah. What's the reason for this restriction (which obviously isn't=
=20
>> >>> enforced by all compilers)?=20
>> >>=20
>> >> Well, to be honest, until C++11 there was basically no way to use=20
>> >> such a return value. [...] Nobody probably considered that `auto`=20
>> >> made such anonymous structs more viable.=20
>>
>> :-)=20
>>
>> > If auto isn't used, we should remember that functions can have=20
>> > multiple declarations, so latter declarations should be grokked to=20
>> > have the same defined-in-return-type return type. For members of=20
>> > class templates, and with any number of aliases between the class=20
>> > template definition and the outside-class-template-definition=20
>> > definition of a member of a class template, the equivalence of return=
=20
>> > types gets fairly complex fairly quickly.=20
>>
>> Agreed; IRTVPDUA=C2=B9 by itself may be useful, but relaxing [dcl.fct]/1=
1=20
>> without IRTVPDUA is likely to be obnoxious. Certainly I don't intend to=
=20
>> propose that the standard enforce that two anonymous structs having the=
=20
>> same layout and being used as return types for the same (not considering=
=20
>> return type) function signature are the same type. I won't gripe if=20
>> compilers want to do that=C2=B2, but I don't think it should be required=
..=20
>>
>> (=C2=B9 Inferred Return Type Via Previous Declaration, Using Auto)=20
>>
>> (=C2=B2 FWIW, I don't think this is as hard as it sounds; compilers ough=
t to=20
>> be able to easily enough compare the canonical function signatures.)=20
>>
>> --=20
>> Matthew=20
>>
>>
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
------=_Part_1554_805090558.1451526719665
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, December 30, 2015 at 6:02:45 PM UTC-5, Bengt Gustafsson wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I think that=
returning by unnamed struct is the best way to return multiple values prop=
osed so far. A pity that it is a non-standard feature (that Microsoft's=
compiler supports). The MSVC support is however very shallow, this does no=
t work:<div><br></div><div><div><br></div><div>struct { int x; const char* =
y; } foo()</div><div>{</div><div><span style=3D"white-space:pre"> </span>re=
turn { 1, "Hej" };</div><div>}</div><div><br></div><div>struct { =
int y; const char* x; } fum()</div><div>{</div><div><span style=3D"white-sp=
ace:pre"> </span>return foo(); =C2=A0 =C2=A0 // ERROR: 'return': ca=
nnot convert from '' to ''</div><div>}</div><div><br></div>=
<div>As suspected aligning the member names does not help either.</div><div=
><br></div><div>So, the question is: How hard would it be to define that th=
is should work -- and how.</div></div></div></blockquote><div><br>Very hard=
.. Well, at least directly.<br><br>Building on what T. C., a <i>lot</i> of C=
++ seems built on the idea that each type definition is distinct and that t=
here is only one definition for each type. To rewrite those rules would be.=
... painful.<br><br>However, since we're specifically talking about a ve=
ry specific case, it <i>might</i> be reasonable to have a special rule that=
says that two anonymous structs that are layout-compatible are not the sam=
e types, but they would be "equivalent types". And two equivalent=
anonymous structs would be implicitly convertible from one to the other (a=
nd can also participate in elision where appropriate).<br><br>Any explicit =
conversions would of course take priority. Granted, explicit conversions wo=
uld require extreme trickery to declare (using `decltype` and such).<br><br=
><br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div> I guess that this should be limited to POD structs and that =
the type of two unnamed structs should be considered compatible iff the lis=
t of types of data members are the same.</div><div><br></div><div>Actually,=
to solve the problem that the original proposer imagined the std algorithm=
s in question could be changed to return a named struct and then the tuple =
access methods get<> and tuple_element<> could be overloaded fo=
r these struct types to handle backwards compatibility, complemented by a c=
ast operator to the original tuple type. This covers most of the compatibil=
ity issues without language change. It is of course possible to construct c=
ode that reveals the standard change but these should be very rare in produ=
ction code. Something like this:</div><div><br></div><div><div style=3D"bor=
der:1px solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(25=
0,250,250)"><code><div><div><font color=3D"#660066"><br></font></div><div><=
font color=3D"#660066">template<typename Iter> struct equal_range_ret=
urn {</font></div><div><font color=3D"#660066"><span style=3D"white-space:p=
re"> </span>Iter first;</font></div><div><font color=3D"#660066"><span styl=
e=3D"white-space:pre"> </span>Iter last;</font></div><div><font color=3D"#6=
60066"><span style=3D"white-space:pre"> </span>operator pair<Iter, Iter&=
gt;() { return { first, last }; }</font></div><div><font color=3D"#660066">=
};</font></div><div><font color=3D"#660066"><br></font></div><div><font col=
or=3D"#660066">template<int N, typename Iter> struct get_return_helpe=
r {</font></div><div><font color=3D"#660066">};</font></div><div><font colo=
r=3D"#660066">template<typename Iter> struct get_return_helper<0, =
Iter> {</font></div><div><font color=3D"#660066"><span style=3D"white-sp=
ace:pre"> </span>Iter get(equal_range_return<Iter>& range) { retu=
rn range.first; }</font></div><div><font color=3D"#660066">};</font></div><=
div><font color=3D"#660066">template<typename Iter> struct get_return=
_helper<1, Iter> {</font></div><div><font color=3D"#660066"><span sty=
le=3D"white-space:pre"> </span>Iter get(equal_range_return<Iter>&=
range) { return range.last; }</font></div><div><font color=3D"#660066">};<=
/font></div><div><font color=3D"#660066"><br></font></div><div><font color=
=3D"#660066">template<int N, typename Iter> Iter get(equal_range_retu=
rn<Iter>& range) {</font></div><div><font color=3D"#660066"><span=
style=3D"white-space:pre"> </span>return get_return_helper<N, Iter>:=
:get(range);</font></div><div><font color=3D"#660066">}</font></div><div><f=
ont color=3D"#660066"><br></font></div><div><font color=3D"#660066">templat=
e<int N, typename Iter> using tuple_element_t =3D Iter;</font></div><=
div><font color=3D"#660066"><br></font></div><div><font color=3D"#660066">t=
emplate<typename Iter, typename T> equal_range_return<Iter> equ=
al_range(Iter from, Iter to, const T& value);</font></div><div><br></di=
v></div></code></div><div><br></div>Note however that all of this is just t=
o rename 'second' to 'last' in std::equal_range. For std::m=
ismatch the names first and second are actually hard to better... I didn=
9;t find any other std algorithms that return two or more values.<br><br></=
div><div>Given these possibilities I don't think that the rather large =
machinery needed to introduce a second way to name members of aggregates as=
proposed in N4560 is warranted. The use case is rather weak from the onset=
, and as it can be emulated quite easily as shown with only minor backwards=
compatibility issues I would not support such a proposal (if I had a say).=
</div><div><br></div><div>Allowing return by anonymous struct in a more com=
plete way than Microsoft currently supports has a much wider applicability =
and seems like a better proposal to put work into. It also has the advantag=
e of removing a non-orthogonal restriction from the standard rather than ad=
ding a new feature which increases the learning curve.</div><div><br></div>=
<div><br></div><br>Den onsdag 30 december 2015 kl. 21:41:09 UTC+1 skrev Mat=
thew Woehlke:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 2015-12-30 15:01, V=
ille Voutilainen wrote:
<br>> On 30 December 2015 at 21:52, Nicol Bolas wrote:
<br>>> On Wednesday, December 30, 2015 at 2:39:01 PM UTC-5, Matthew W=
oehlke wrote:
<br>>>> On 2015-12-30 14:20, T. C. wrote:
<br>>>>> On Wednesday, December 30, 2015 at 8:20:35 AM UTC-5, V=
icente J. Botet
<br>>>>> Escriba wrote:
<br>>>>> [dcl.fct]/11:
<br>>>>>
<br>>>>> Types shall not be defined in return or parameter type=
s.
<br>>>>
<br>>>> Bah. What's the reason for this restriction (which obv=
iously isn't
<br>>>> enforced by all compilers)?
<br>>>
<br>>> Well, to be honest, until C++11 there was basically no way to =
use
<br>>> such a return value. [...] Nobody probably considered that `au=
to`
<br>>> made such anonymous structs more viable.
<br>
<br>:-)
<br>
<br>> If auto isn't used, we should remember that functions can have=
=20
<br>> multiple declarations, so latter declarations should be grokked to
<br>> have the same defined-in-return-type return type. For members of
<br>> class templates, and with any number of aliases between the class
<br>> template definition and the outside-class-template-<wbr>definition=
=20
<br>> definition of a member of a class template, the equivalence of ret=
urn
<br>> types gets fairly complex fairly quickly.
<br>
<br>Agreed; IRTVPDUA=C2=B9 by itself may be useful, but relaxing [dcl.fct]/=
11
<br>without IRTVPDUA is likely to be obnoxious. Certainly I don't inten=
d to
<br>propose that the standard enforce that two anonymous structs having the
<br>same layout and being used as return types for the same (not considerin=
g
<br>return type) function signature are the same type. I won't gripe if
<br>compilers want to do that=C2=B2, but I don't think it should be req=
uired.
<br>
<br>(=C2=B9 Inferred Return Type Via Previous Declaration, Using Auto)
<br>
<br>(=C2=B2 FWIW, I don't think this is as hard as it sounds; compilers=
ought to
<br>be able to easily enough compare the canonical function signatures.)
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></div></div></blockquote>
<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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_1554_805090558.1451526719665--
------=_Part_1553_1818529117.1451526719665--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 30 Dec 2015 18:40:25 -0800 (PST)
Raw View
------=_Part_2404_334780037.1451529626002
Content-Type: multipart/alternative;
boundary="----=_Part_2405_1662524049.1451529626008"
------=_Part_2405_1662524049.1451529626008
Content-Type: text/plain; charset=UTF-8
On Wednesday, December 30, 2015 at 8:52:00 PM UTC-5, Nicol Bolas wrote:
>
> On Wednesday, December 30, 2015 at 6:02:45 PM UTC-5, Bengt Gustafsson
> wrote:
>>
>> I think that returning by unnamed struct is the best way to return
>> multiple values proposed so far. A pity that it is a non-standard feature
>> (that Microsoft's compiler supports). The MSVC support is however very
>> shallow, this does not work:
>>
>>
>> struct { int x; const char* y; } foo()
>> {
>> return { 1, "Hej" };
>> }
>>
>> struct { int y; const char* x; } fum()
>> {
>> return foo(); // ERROR: 'return': cannot convert from '' to ''
>> }
>>
>> As suspected aligning the member names does not help either.
>>
>> So, the question is: How hard would it be to define that this should work
>> -- and how.
>>
>
> Very hard. Well, at least directly.
>
> Building on what T. C., a *lot* of C++ seems built on the idea that each
> type definition is distinct and that there is only one definition for each
> type. To rewrite those rules would be... painful.
>
> However, since we're specifically talking about a very specific case, it
> *might* be reasonable to have a special rule that says that two anonymous
> structs that are layout-compatible are not the same types, but they would
> be "equivalent types". And two equivalent anonymous structs would be
> implicitly convertible from one to the other (and can also participate in
> elision where appropriate).
>
> Any explicit conversions would of course take priority. Granted, explicit
> conversions would require extreme trickery to declare (using `decltype` and
> such).
>
Note that the layout compatibility rule implies that the two types are
standard layout. So types which are not standard layout wouldn't be able to
get this implicit conversion.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2405_1662524049.1451529626008
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, December 30, 2015 at 8:52:00 PM UTC-5, Nicol Bolas wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">On Wednesday, December 30, 2015 at=
6:02:45 PM UTC-5, Bengt Gustafsson wrote:<blockquote class=3D"gmail_quote"=
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">I think that returning by unnamed struct is the bes=
t way to return multiple values proposed so far. A pity that it is a non-st=
andard feature (that Microsoft's compiler supports). The MSVC support i=
s however very shallow, this does not work:<div><br></div><div><div><br></d=
iv><div>struct { int x; const char* y; } foo()</div><div>{</div><div><span =
style=3D"white-space:pre"> </span>return { 1, "Hej" };</div><div>=
}</div><div><br></div><div>struct { int y; const char* x; } fum()</div><div=
>{</div><div><span style=3D"white-space:pre"> </span>return foo(); =C2=A0 =
=C2=A0 // ERROR: 'return': cannot convert from '' to '&=
#39;</div><div>}</div><div><br></div><div>As suspected aligning the member =
names does not help either.</div><div><br></div><div>So, the question is: H=
ow hard would it be to define that this should work -- and how.</div></div>=
</div></blockquote><div><br>Very hard. Well, at least directly.<br><br>Buil=
ding on what T. C., a <i>lot</i> of C++ seems built on the idea that each t=
ype definition is distinct and that there is only one definition for each t=
ype. To rewrite those rules would be... painful.<br><br>However, since we&#=
39;re specifically talking about a very specific case, it <i>might</i> be r=
easonable to have a special rule that says that two anonymous structs that =
are layout-compatible are not the same types, but they would be "equiv=
alent types". And two equivalent anonymous structs would be implicitly=
convertible from one to the other (and can also participate in elision whe=
re appropriate).<br><br>Any explicit conversions would of course take prior=
ity. Granted, explicit conversions would require extreme trickery to declar=
e (using `decltype` and such).</div></blockquote><div><br>Note that the lay=
out compatibility rule implies that the two types are standard layout. So t=
ypes which are not standard layout wouldn't be able to get this implici=
t conversion.<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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_2405_1662524049.1451529626008--
------=_Part_2404_334780037.1451529626002--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 31 Dec 2015 07:17:00 +0100
Raw View
This is a multi-part message in MIME format.
--------------080009010900010402080703
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 31/12/2015 00:02, Bengt Gustafsson a =C3=A9crit :
> I think that returning by unnamed struct is the best way to return=20
> multiple values proposed so far. A pity that it is a non-standard=20
> feature (that Microsoft's compiler supports). The MSVC support is=20
> however very shallow, this does not work:
>
>
> struct { int x; const char* y; } foo()
> {
> return { 1, "Hej" };
> }
>
> struct { int y; const char* x; } fum()
> {
> return foo(); // ERROR: 'return': cannot convert from '' to ''
> }
>
> As suspected aligning the member names does not help either.
>
> So, the question is: How hard would it be to define that this should=20
> work -- and how. I guess that this should be limited to POD structs=20
> and that the type of two unnamed structs should be considered=20
> compatible iff the list of types of data members are the same.
Agreed.
>
> Actually, to solve the problem that the original proposer imagined the=20
> std algorithms in question could be changed to return a named struct=20
> and then the tuple access methods get<> and tuple_element<> could be=20
> overloaded for these struct types to handle backwards compatibility,=20
> complemented by a cast operator to the original tuple type. This=20
> covers most of the compatibility issues without language change. It is=20
> of course possible to construct code that reveals the standard change=20
> but these should be very rare in production code. Something like this:
>
> |
>
> template<typename Iter> struct equal_range_return {
> Iter first;
> Iter last;
> operator pair<Iter, Iter>() { return { first, last }; }
> };
>
> template<int N, typename Iter> struct get_return_helper {
> };
> template<typename Iter> struct get_return_helper<0, Iter> {
> Iter get(equal_range_return<Iter>& range) { return range.first; }
> };
> template<typename Iter> struct get_return_helper<1, Iter> {
> Iter get(equal_range_return<Iter>& range) { return range.last; }
> };
>
> template<int N, typename Iter> Iter get(equal_range_return<Iter>& range) =
{
> return get_return_helper<N, Iter>::get(range);
> }
>
> template<int N, typename Iter> using tuple_element_t =3D Iter;
>
> template<typename Iter, typename T> equal_range_return<Iter>=20
> equal_range(Iter from, Iter to, const T& value);
>
> |
>
> Note however that all of this is just to rename 'second' to 'last' in=20
> std::equal_range. For std::mismatch the names first and second are=20
> actually hard to better... I didn't find any other std algorithms that=20
> return two or more values.
>
> Given these possibilities I don't think that the rather large=20
> machinery needed to introduce a second way to name members of=20
> aggregates as proposed in N4560 is warranted. The use case is rather=20
> weak from the onset, and as it can be emulated quite easily as shown=20
> with only minor backwards compatibility issues I would not support=20
> such a proposal (if I had a say).
>
I admit I missed the backward compatibility requirements of the tagged_=20
classes and I share your concern.
> Allowing return by anonymous struct in a more complete way than=20
> Microsoft currently supports has a much wider applicability and seems=20
> like a better proposal to put work into. It also has the advantage of=20
> removing a non-orthogonal restriction from the standard rather than=20
> adding a new feature which increases the learning curve.
>
Any contribution in this direction is welcome.
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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--------------080009010900010402080703
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 31/12/2015 00:02, Bengt Gustafsson a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:d6232453-52b0-4bf1-af2c-4d004309b111@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">I think that returning by unnamed struct is the
best way to return multiple values proposed so far. A pity that
it is a non-standard feature (that Microsoft's compiler
supports). The MSVC support is however very shallow, this does
not work:
<div><br>
</div>
<div>
<div><br>
</div>
<div>struct { int x; const char* y; } foo()</div>
<div>{</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </=
span>return
{ 1, "Hej" };</div>
<div>}</div>
<div><br>
</div>
<div>struct { int y; const char* x; } fum()</div>
<div>{</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </=
span>return
foo(); =C2=A0 =C2=A0 // ERROR: 'return': cannot convert from ''=
to ''</div>
<div>}</div>
<div><br>
</div>
<div>As suspected aligning the member names does not help
either.</div>
<div><br>
</div>
<div>So, the question is: How hard would it be to define that
this should work -- and how. I guess that this should be
limited to POD structs and that the type of two unnamed
structs should be considered compatible iff the list of
types of data members are the same.</div>
</div>
</div>
</blockquote>
Agreed.
<blockquote
cite=3D"mid:d6232453-52b0-4bf1-af2c-4d004309b111@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>
<div><br>
</div>
<div>Actually, to solve the problem that the original proposer
imagined the std algorithms in question could be changed to
return a named struct and then the tuple access methods
get<> and tuple_element<> could be overloaded
for these struct types to handle backwards compatibility,
complemented by a cast operator to the original tuple type.
This covers most of the compatibility issues without
language change. It is of course possible to construct code
that reveals the standard change but these should be very
rare in production code. Something like this:</div>
<div><br>
</div>
<div>
<div class=3D"prettyprint" style=3D"border: 1px solid rgb(187,
187, 187); word-wrap: break-word; background-color:
rgb(250, 250, 250);"><code class=3D"prettyprint">
<div class=3D"subprettyprint">
<div class=3D"subprettyprint"><font color=3D"#660066"><br=
>
</font></div>
<div class=3D"subprettyprint"><font color=3D"#660066">tem=
plate<typename
Iter> struct equal_range_return {</font></div>
<div class=3D"subprettyprint"><font color=3D"#660066"><sp=
an class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>Iter
first;</font></div>
<div class=3D"subprettyprint"><font color=3D"#660066"><sp=
an class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>Iter
last;</font></div>
<div class=3D"subprettyprint"><font color=3D"#660066"><sp=
an class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>operator
pair<Iter, Iter>() { return { first, last };
}</font></div>
<div class=3D"subprettyprint"><font color=3D"#660066">};<=
/font></div>
<div class=3D"subprettyprint"><font color=3D"#660066"><br=
>
</font></div>
<div class=3D"subprettyprint"><font color=3D"#660066">tem=
plate<int
N, typename Iter> struct get_return_helper {</font=
></div>
<div class=3D"subprettyprint"><font color=3D"#660066">};<=
/font></div>
<div class=3D"subprettyprint"><font color=3D"#660066">tem=
plate<typename
Iter> struct get_return_helper<0, Iter> {</f=
ont></div>
<div class=3D"subprettyprint"><font color=3D"#660066"><sp=
an class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>Iter
get(equal_range_return<Iter>& range) {
return range.first; }</font></div>
<div class=3D"subprettyprint"><font color=3D"#660066">};<=
/font></div>
<div class=3D"subprettyprint"><font color=3D"#660066">tem=
plate<typename
Iter> struct get_return_helper<1, Iter> {</f=
ont></div>
<div class=3D"subprettyprint"><font color=3D"#660066"><sp=
an class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>Iter
get(equal_range_return<Iter>& range) {
return range.last; }</font></div>
<div class=3D"subprettyprint"><font color=3D"#660066">};<=
/font></div>
<div class=3D"subprettyprint"><font color=3D"#660066"><br=
>
</font></div>
<div class=3D"subprettyprint"><font color=3D"#660066">tem=
plate<int
N, typename Iter> Iter
get(equal_range_return<Iter>& range) {</fon=
t></div>
<div class=3D"subprettyprint"><font color=3D"#660066"><sp=
an class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>return
get_return_helper<N, Iter>::get(range);</font><=
/div>
<div class=3D"subprettyprint"><font color=3D"#660066">}</=
font></div>
<div class=3D"subprettyprint"><font color=3D"#660066"><br=
>
</font></div>
<div class=3D"subprettyprint"><font color=3D"#660066">tem=
plate<int
N, typename Iter> using tuple_element_t =3D Iter;<=
/font></div>
<div class=3D"subprettyprint"><font color=3D"#660066"><br=
>
</font></div>
<div class=3D"subprettyprint"><font color=3D"#660066">tem=
plate<typename
Iter, typename T>
equal_range_return<Iter> equal_range(Iter
from, Iter to, const T& value);</font></div>
<div><br>
</div>
</div>
</code></div>
<div><br>
</div>
Note however that all of this is just to rename 'second' to
'last' in std::equal_range. For std::mismatch the names
first and second are actually hard to better... I didn't
find any other std algorithms that return two or more
values.<br>
<br>
</div>
<div>Given these possibilities I don't think that the rather
large machinery needed to introduce a second way to name
members of aggregates as proposed in N4560 is warranted. The
use case is rather weak from the onset, and as it can be
emulated quite easily as shown with only minor backwards
compatibility issues I would not support such a proposal (if
I had a say).</div>
<div><br>
</div>
</div>
</div>
</blockquote>
I admit I missed the backward compatibility requirements of the
tagged_ classes and I share your concern.<br>
<blockquote
cite=3D"mid:d6232453-52b0-4bf1-af2c-4d004309b111@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>
<div>Allowing return by anonymous struct in a more complete
way than Microsoft currently supports has a much wider
applicability and seems like a better proposal to put work
into. It also has the advantage of removing a non-orthogonal
restriction from the standard rather than adding a new
feature which increases the learning curve.</div>
<div><br>
</div>
</div>
</div>
</blockquote>
Any contribution in this direction is welcome.<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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--------------080009010900010402080703--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 31 Dec 2015 12:45:24 +0100
Raw View
This is a multi-part message in MIME format.
--------------080308060904060106070309
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 31/12/2015 02:51, Nicol Bolas a =C3=A9crit :
> On Wednesday, December 30, 2015 at 6:02:45 PM UTC-5, Bengt Gustafsson=20
> wrote:
>
> I think that returning by unnamed struct is the best way to return
> multiple values proposed so far. A pity that it is a non-standard
> feature (that Microsoft's compiler supports). The MSVC support is
> however very shallow, this does not work:
>
>
> struct { int x; const char* y; } foo()
> {
> return { 1, "Hej" };
> }
>
> struct { int y; const char* x; } fum()
> {
> return foo(); // ERROR: 'return': cannot convert from '' to ''
> }
>
> As suspected aligning the member names does not help either.
>
> So, the question is: How hard would it be to define that this
> should work -- and how.
>
>
> Very hard. Well, at least directly.
>
> Building on what T. C., a /lot/ of C++ seems built on the idea that=20
> each type definition is distinct and that there is only one definition=20
> for each type. To rewrite those rules would be... painful.
>
> However, since we're specifically talking about a very specific case,=20
> it /might/ be reasonable to have a special rule that says that two=20
> anonymous structs
unnamed structs :) anonymous structs is something different.
> that are layout-compatible are not the same types, but they would be=20
> "equivalent types". And two equivalent anonymous structs would be=20
> implicitly convertible from one to the other (and can also participate=20
> in elision where appropriate).
>
I believe that introducing conversion would make things more complex=20
that necessary, IMO we need that we have the same type.
Next follows an *alternative*: I don't know yet how, but in the same way=20
we consider that these two functions return the same type
tagged_pair<tag::x(int), tag::y(const char*> foo()
{
return { 1, "Hej" };
}
tagged_pair<tag::x(int), tag::y(const char*)> fum()
{
return foo(); // OK
}
even if we have two instantiations of the template tagged_pair and that=20
the resulting type is the same, I would like to be able to use something=20
as simple as
KEYWORD { int x; const char* y; }
to mean the instantiation of a type that contains an int named x and a=20
const char* named y.
My first trial has been with unnamed structs (KEYWORD=3D=3Dstruct), but=20
currently this implies the definition of two distinct types :(
What I'm looking for and I believe we need is that
is_same<KEYWORD { int x; const char* y; }, KEYWORD { int x; const=20
char* y; }>
in the same way
is_same<tagged_pair<tag::x(int), tag::y(const char*)>,=20
tagged_pair<tag::x(int), tag::y(const char*)>>
is_same<char*, char*>
is_same<int[3], int[3]>
is_same<int, int>
That is, KEYWORD {...} would just be another way to construct new types,=20
as we do with T*, T&, const T, volatile T, T[n].
KEYWORD {} could be limited to contain only data members. The extreme=20
case could be that the member data are even unnamed
KEYWORD { int ; const char*; }
This should define almost the same as tuple<int, const char*>.
Conversion from two such types that have the same data member types but=20
with different data member names would be desirable.
Conversion(promotion) from two such types that have the convertible data=20
member types would be desirable.
If in addition std::pair<T,U> were convertible from any type KEYWORD { T=20
_1; U _2;} (for any field names), the backward compatibility issue could=20
be almost ensured. How to define this conversion needs more insight.
The question is then if we want to define something new at the language=20
level that represents a named tuple that could be used in particular to=20
return multiple values from a function.
Bike-shading for KEYWORD:
* auto?
auto { int x; const char* y; }
=3D> overuse of auto
* decltype?
decltype { int x; const char* y; }
* struct?
struct { int x; const char* y; }
=3D> would need some changes on the meaning of an unnamed struct :(
* nothing?
{ int x; const char* y; }
=3D> IMHO this seems the more elegant.
Vicente
> Any explicit conversions would of course take priority. Granted,=20
> explicit conversions would require extreme trickery to declare (using=20
> `decltype` and such).
>
>
> I guess that this should be limited to POD structs and that the
> type of two unnamed structs should be considered compatible iff
> the list of types of data members are the same.
>
>
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--------------080308060904060106070309
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 31/12/2015 02:51, Nicol Bolas a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:dc3e398a-c1ce-49f5-93cf-d8d67cc1c0d1@isocpp.org"
type=3D"cite">On Wednesday, December 30, 2015 at 6:02:45 PM UTC-5,
Bengt Gustafsson wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div dir=3D"ltr">I think that returning by unnamed struct is the
best way to return multiple values proposed so far. A pity
that it is a non-standard feature (that Microsoft's compiler
supports). The MSVC support is however very shallow, this does
not work:
<div><br>
</div>
<div>
<div><br>
</div>
<div>struct { int x; const char* y; } foo()</div>
<div>{</div>
<div><span style=3D"white-space:pre"> </span>return { 1, "Hej"
};</div>
<div>}</div>
<div><br>
</div>
<div>struct { int y; const char* x; } fum()</div>
<div>{</div>
<div><span style=3D"white-space:pre"> </span>return foo(); =C2=
=A0 =C2=A0
// ERROR: 'return': cannot convert from '' to ''</div>
<div>}</div>
<div><br>
</div>
<div>As suspected aligning the member names does not help
either.</div>
<div><br>
</div>
<div>So, the question is: How hard would it be to define
that this should work -- and how.</div>
</div>
</div>
</blockquote>
<div><br>
Very hard. Well, at least directly.<br>
<br>
Building on what T. C., a <i>lot</i> of C++ seems built on the
idea that each type definition is distinct and that there is
only one definition for each type. To rewrite those rules would
be... painful.<br>
<br>
However, since we're specifically talking about a very specific
case, it <i>might</i> be reasonable to have a special rule that
says that two anonymous structs </div>
</blockquote>
unnamed structs :) anonymous structs is something different.<br>
<blockquote
cite=3D"mid:dc3e398a-c1ce-49f5-93cf-d8d67cc1c0d1@isocpp.org"
type=3D"cite">
<div>that are layout-compatible are not the same types, but they
would be "equivalent types". And two equivalent anonymous
structs would be implicitly convertible from one to the other
(and can also participate in elision where appropriate).<br>
<br>
</div>
</blockquote>
I believe that introducing conversion would make things more complex
that necessary, IMO we need that we have the same type.<br>
<br>
Next follows an <b>alternative</b>: I don't know yet how, but in
the same way we consider that these two functions return the same
type<br>
<br>
<div>tagged_pair<tag::x(int), tag::y(const char*> foo()</div>
<div>{</div>
<div><span style=3D"white-space:pre"> </span>return { 1, "Hej" };</div>
<div>}</div>
<div><br>
</div>
<div>tagged_pair<tag::x(int), tag::y(const char*)> fum()</div>
<div>{</div>
<div><span style=3D"white-space:pre"> </span>return foo(); =C2=A0 =C2=
=A0 // OK</div>
<div>}</div>
<br>
even if we have two instantiations of the template tagged_pair and
that the resulting type is the same, I would like to be able to use
something as simple as<br>
<br>
=C2=A0=C2=A0=C2=A0 KEYWORD { int x; const char* y; }<br>
<br>
to mean the instantiation of a type that contains an int named x and
a const char* named y.<br>
<br>
My first trial has been with unnamed structs (KEYWORD=3D=3Dstruct), but
currently this implies the definition of two distinct types :(<br>
<br>
What I'm looking for and I believe we need is that<br>
<br>
=C2=A0=C2=A0=C2=A0 is_same<KEYWORD { int x; const char* y; }, KEYWOR=
D { int x;
const char* y; }><br>
<br>
in the same way<br>
<br>
=C2=A0=C2=A0=C2=A0 is_same<tagged_pair<tag::x(int), tag::y(const =
char*)>,
tagged_pair<tag::x(int), tag::y(const char*)>><br>
=C2=A0=C2=A0=C2=A0 is_same<char*, char*><br>
=C2=A0=C2=A0=C2=A0 is_same<int[3], int[3]><br>
=C2=A0=C2=A0=C2=A0 is_same<int, int><br>
<br>
That is, KEYWORD {...} would just be another way to construct new
types, as we do with T*, T&, const T, volatile T, T[n].<br>
<br>
KEYWORD {} could be limited to contain only data members. The
extreme case could be that the member data are even unnamed<br>
<br>
=C2=A0=C2=A0=C2=A0 KEYWORD { int ; const char*; }<br>
<br>
This should define almost the same as tuple<int, const char*>.<br=
>
<br>
Conversion from two such types that have the same data member types
but with different data member names would be desirable.<br>
Conversion(promotion) from two such types that have the convertible
data member types would be desirable.<br>
<br>
If in addition std::pair<T,U> were convertible from any type
KEYWORD { T _1; U _2;} (for any field names), the backward
compatibility issue could be almost ensured. How to define this
conversion needs more insight.<br>
<br>
The question is then if we want to define something new at the
language level that represents a named tuple that could be used in
particular to return multiple values from a function.<br>
<br>
Bike-shading for KEYWORD: <br>
<br>
* auto?<br>
<br>
=C2=A0=C2=A0=C2=A0 auto { int x; const char* y; }<br>
<br>
=C2=A0=C2=A0=C2=A0 =3D> overuse of auto<br>
<br>
* decltype?<br>
<br>
=C2=A0=C2=A0=C2=A0 decltype { int x; const char* y; }<br>
<br>
* struct?<br>
<br>
=C2=A0=C2=A0=C2=A0 struct { int x; const char* y; }<br>
<br>
=C2=A0=C2=A0=C2=A0 =3D> would need some changes on the meaning of an=
unnamed
struct :(<br>
<br>
* nothing?<br>
<br>
=C2=A0=C2=A0=C2=A0 { int x; const char* y; }<br>
<br>
=C2=A0=C2=A0=C2=A0 =3D> IMHO this seems the more elegant.<br>
<br>
Vicente<br>
<br>
<blockquote
cite=3D"mid:dc3e398a-c1ce-49f5-93cf-d8d67cc1c0d1@isocpp.org"
type=3D"cite">
<div>Any explicit conversions would of course take priority.
Granted, explicit conversions would require extreme trickery to
declare (using `decltype` and such).<br>
<br>
<br>
=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div dir=3D"ltr">
<div>
<div> I guess that this should be limited to POD structs and
that the type of two unnamed structs should be considered
compatible iff the list of types of data members are the
same.</div>
<div><br>
</div>
<br>
</div>
</div>
</blockquote>
</blockquote>
<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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--------------080308060904060106070309--
.
Author: Giovanni Piero Deretta <gpderetta@gmail.com>
Date: Thu, 31 Dec 2015 04:28:35 -0800 (PST)
Raw View
------=_Part_4154_251484505.1451564915401
Content-Type: multipart/alternative;
boundary="----=_Part_4155_720911127.1451564915411"
------=_Part_4155_720911127.1451564915411
Content-Type: text/plain; charset=UTF-8
On Thursday, December 31, 2015 at 11:45:27 AM UTC, Vicente J. Botet Escriba
wrote:
What I'm looking for and I believe we need is that
>
> is_same<KEYWORD { int x; const char* y; }, KEYWORD { int x; const
> char* y; }>
>
are you sure you need is_same to hold (i.e. nominal type equality) ...
>
> [...]
>
That is, KEYWORD {...} would just be another way to construct new types, as
> we do with T*, T&, const T, volatile T, T[n].
>
> KEYWORD {} could be limited to contain only data members. The extreme case
> could be that the member data are even unnamed
>
> KEYWORD { int ; const char*; }
>
> This should define almost the same as tuple<int, const char*>.
>
>
instead of just:
> Conversion from two such types that have the same data member types but
> with different data member names would be desirable.
> Conversion(promotion) from two such types that have the convertible data
> member types would be desirable.
>
i.e. some sort of opt-in structural typing.
>
> If in addition std::pair<T,U> were convertible from any type KEYWORD { T
> _1; U _2;} (for any field names), the backward compatibility issue could be
> almost ensured. How to define this conversion needs more insight.
>
> The question is then if we want to define something new at the language
> level that represents a named tuple that could be used in particular to
> return multiple values from a function.
>
>
>
I was toying with a possible language extension (a ` quote operator) to
lift symbols to first class values that would allow:
auto t = std::tup(`first = 10, `second = "hello"s); // t has .first and
..second members of appropriate types
struct { int first; std::string second; } s = t; // ok
std::pair<int, std::string> p = t; // also ok
A pure macro based implementation here :
https://github.com/gpderetta/libtask/blob/broken/tests/q_test.cpp
It uses the $(<symbol>) syntax instead of `<symbol>, but it is otherwise
complete.
The library approach uses lambdas under the hood, so you can't put a
$(<symbol>) expression directly inside decltype for now.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_4155_720911127.1451564915411
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, December 31, 2015 at 11:45:27 AM UTC, Vicente=
J. Botet Escriba wrote:<div><br><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><div>
What I'm looking for and I believe we need is that<br>
<br>
=C2=A0=C2=A0=C2=A0 is_same<KEYWORD { int x; const char* y; }, KEYWOR=
D { int x;
const char* y; }><br></div></blockquote><div><br>are you sure you ne=
ed is_same to hold=C2=A0 (i.e. nominal type equality) ...<br>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div>
<br>[...] <br></div></blockquote><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
That is, KEYWORD {...} would just be another way to construct new
types, as we do with T*, T&, const T, volatile T, T[n].<br></div></=
blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FF=
FFFF" text=3D"#000000">
<br>
KEYWORD {} could be limited to contain only data members. The
extreme case could be that the member data are even unnamed<br>
<br>
=C2=A0=C2=A0=C2=A0 KEYWORD { int ; const char*; }<br>
<br>
This should define almost the same as tuple<int, const char*>.<br=
>
<br></div></blockquote><div><br>instead of just:<br>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000=
000">
Conversion from two such types that have the same data member types
but with different data member names would be desirable.<br>
Conversion(promotion) from two such types that have the convertible
data member types would be desirable.<br></div></blockquote><div><br>i.=
e. some sort of opt-in structural typing.<br>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
<br>
If in addition std::pair<T,U> were convertible from any type
KEYWORD { T _1; U _2;} (for any field names), the backward
compatibility issue could be almost ensured. How to define this
conversion needs more insight.<br>
<br>
The question is then if we want to define something new at the
language level that represents a named tuple that could be used in
particular to return multiple values from a function.<br>
<br>
<br></div></blockquote><div><br>I was toying with a possible language e=
xtension (a ` quote operator) to lift symbols to first class values that wo=
uld allow:<br><br>auto t =3D=C2=A0 std::tup(`first =3D 10, `second =3D &quo=
t;hello"s); // t has .first and .second members of appropriate types<b=
r><br>struct { int first; std::string second; } s =3D t; // ok<br><br>std::=
pair<int, std::string> p =3D t; // also ok<br><br>A pure macro based =
implementation here : https://github.com/gpderetta/libtask/blob/broken/test=
s/q_test.cpp<br><br>It uses the $(<symbol>) syntax instead of `<sy=
mbol>, but it is otherwise complete.<br><br>The library approach uses la=
mbdas under the hood, so you can't put a $(<symbol>) expression d=
irectly inside decltype for now.<br><br></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" 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_4155_720911127.1451564915411--
------=_Part_4154_251484505.1451564915401--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 31 Dec 2015 09:44:19 -0500
Raw View
On 2015-12-30 18:02, Bengt Gustafsson wrote:
> I think that returning by unnamed struct is the best way to return multip=
le=20
> values proposed so far. A pity that it is a non-standard feature (that=20
> Microsoft's compiler supports). The MSVC support is however very shallow,=
=20
> this does not work:
>=20
>=20
> struct { int x; const char* y; } foo()
> {
> return { 1, "Hej" };
> }
>=20
> struct { int y; const char* x; } fum()
> {
> return foo(); // ERROR: 'return': cannot convert from '' to ''
> }
Well... yeah. I'm not convinced this *should* work, however.
(Presumably, though, you could use ARTIFRS=C2=B9 here, though. But only if
fum() doesn't need a separate declaration.)
(=C2=B9 Automatic Return Type Inferred From Return Statement)
Anyway, with the addition of P0144 / P0151, you could make it work like:
struct { int y; char const* x } fum()
{
auto <x, y> =3D foo();
return { x, y };
}
....and maybe some day you'll even be able to write:
struct { int y; char const* x } fum()
{
return { [*]foo() };
}
> So, the question is: How hard would it be to define that this should work=
=20
> -- and how. I guess that this should be limited to POD structs and that t=
he=20
> type of two unnamed structs should be considered compatible iff the list =
of=20
> types of data members are the same.
struct /*polar*/ { double r; double t; };
struct /*cartesian*/ { double x; double y; };
Should those be equivalent? I think not. Again, I'm not convinced that
equivalence is a good thing. Sure, it makes some things easier, but it
seems *very* open to abuse. I'm not convinced there aren't better ways
(like tuple expansion) to achieve the same things.
--=20
Matthew
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 31 Dec 2015 09:52:55 -0500
Raw View
On 2015-12-31 06:45, Vicente J. Botet Escriba wrote:
> I believe that introducing conversion would make things more complex
> that necessary, IMO we need that we have the same type.
> [...]
>
> What I'm looking for and I believe we need is that
>
> is_same<KEYWORD { int x; const char* y; }, KEYWORD { int x; const
> char* y; }>
>
> KEYWORD {} could be limited to contain only data members. The extreme
> case could be that the member data are even unnamed
>
> KEYWORD { int ; const char*; }
>
> This should define almost the same as tuple<int, const char*>.
Uh... yeah. Only, why "almost"?
The whole justification for using anonymous structs *instead of* tuple
is that the values are *named*. If they're not named, you've defeated
the purpose. In that case, why not just use tuple?
> Conversion from two such types that have the same data member types but
> with different data member names would be desirable.
Uh... no. No it isn't. (Not implicitly, at least! See my other post for
an example why.)
And I'd still prefer to see this, for doing so explicitly:
struct { int a; double b; } x;
struct { int c; double d; } y;
x = ...;
y = { [*]x };
> If in addition std::pair<T,U> were convertible from any type KEYWORD { T
> _1; U _2;} (for any field names), the backward compatibility issue could
> be almost ensured. How to define this conversion needs more insight.
Now *that* would be useful. (Hmm... actually, given reflection,
shouldn't this be possible with the addition of an appropriate template
ctor to std::pair? Naturally, std::tuple should get the same treatment.)
....or we could just hand-wave the details and leave it to compilers to
figure out (which might anyway be more efficient).
--
Matthew
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 31 Dec 2015 11:13:10 -0500
Raw View
On 2015-12-30 14:20, T. C. wrote:
> [dcl.fct]/11:
>
> Types shall not be defined in return or parameter types.
In N3242 / N3690 / N3797, that's /9, not /11... Am I looking in the
wrong place? Or is /11 from an earlier version?
--
Matthew
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 31 Dec 2015 18:21:37 +0200
Raw View
On 31 December 2015 at 18:13, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> On 2015-12-30 14:20, T. C. wrote:
>> [dcl.fct]/11:
>>
>> Types shall not be defined in return or parameter types.
>
> In N3242 / N3690 / N3797, that's /9, not /11... Am I looking in the
> wrong place? Or is /11 from an earlier version?
Perhaps n4567?
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 31 Dec 2015 11:41:11 -0500
Raw View
On 2015-12-31 11:21, Ville Voutilainen wrote:
> On 31 December 2015 at 18:13, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>> On 2015-12-30 14:20, T. C. wrote:
>>> [dcl.fct]/11:
>>>
>>> Types shall not be defined in return or parameter types.
>>
>> In N3242 / N3690 / N3797, that's /9, not /11... Am I looking in the
>> wrong place? Or is /11 from an earlier version?
>
>
> Perhaps n4567?
Arf... the only place I'm seeing that linked is buried in the list of
post-Kona mailing papers. In particular, it's NOT the "latest publicly
available draft" at http://www.open-std.org/jtc1/sc22/wg21/ (i.e. the
latest publicly available draft... isn't).
Thanks.
--
Matthew
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 31 Dec 2015 18:51:26 +0200
Raw View
On 31 December 2015 at 18:41, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>> Perhaps n4567?
> Arf... the only place I'm seeing that linked is buried in the list of
> post-Kona mailing papers. In particular, it's NOT the "latest publicly
> available draft" at http://www.open-std.org/jtc1/sc22/wg21/ (i.e. the
> latest publicly available draft... isn't).
The whole site is a volunteer effort, the maintainer doesn't necessarily always
manage to keep it up-to-date. Always look at the most recent mailing
for the most recent draft. Chances are that the reason the link to the
"most recent draft"
is not kept up to date is that ISO has restricted its rules, and N-papers
shouldn't even be available outside 'LiveLink' (don't ask, don't tell).
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 31 Dec 2015 18:15:51 +0100
Raw View
Le 31/12/2015 15:52, Matthew Woehlke a =C3=A9crit :
> On 2015-12-31 06:45, Vicente J. Botet Escriba wrote:
>> I believe that introducing conversion would make things more complex
>> that necessary, IMO we need that we have the same type.
>> [...]
>>
>> What I'm looking for and I believe we need is that
>>
>> is_same<KEYWORD { int x; const char* y; }, KEYWORD { int x; const
>> char* y; }>
>>
>> KEYWORD {} could be limited to contain only data members. The extreme
>> case could be that the member data are even unnamed
>>
>> KEYWORD { int ; const char*; }
>>
>> This should define almost the same as tuple<int, const char*>.
> Uh... yeah. Only, why "almost"?
KEYWORD { int ; const char*; } wouldn't have default constructor, member sw=
ap, constructor from std::pair, ...
>
> The whole justification for using anonymous structs *instead of* tuple
> is that the values are *named*. If they're not named, you've defeated
> the purpose. In that case, why not just use tuple?
You can. My intent was to make evident that KEYWORD { T ; U; } could be=20
another way to represent almost a std::tuple.
>
>> Conversion from two such types that have the same data member types but
>> with different data member names would be desirable.
> Uh... no. No it isn't. (Not implicitly, at least! See my other post for
> an example why.)
Agreed, your example polar/cartesian is an example where the tags are=20
giving meaning to the type. However I don't believe this is the correct=20
way, the double should be different in polar and cartesian.
Note also that we have conversion from pair to tuple and this doesn't=20
surprise anyone.
> And I'd still prefer to see this, for doing so explicitly:
>
> struct { int a; double b; } x;
> struct { int c; double d; } y;
> x =3D ...;
> y =3D { [*]x };
Yes, I remember the (python like) thread.
>> If in addition std::pair<T,U> were convertible from any type KEYWORD { T
>> _1; U _2;} (for any field names), the backward compatibility issue could
>> be almost ensured. How to define this conversion needs more insight.
> Now *that* would be useful. (Hmm... actually, given reflection,
> shouldn't this be possible with the addition of an appropriate template
> ctor to std::pair? Naturally, std::tuple should get the same treatment.)
The problem I see is how to name the fields :(
This is why I said for any field names and I don't know how to do it yet if
struct { int a; double b; }
and
struct { int c; double d; }
are different types, or if they don't have some kind of automatic conversio=
n.
> ...or we could just hand-wave the details and leave it to compilers to
> figure out (which might anyway be more efficient).
>
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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 31 Dec 2015 13:03:04 -0500
Raw View
On 2015-12-31 12:15, Vicente J. Botet Escriba wrote:
> Le 31/12/2015 15:52, Matthew Woehlke a =C3=A9crit :
>> On 2015-12-31 06:45, Vicente J. Botet Escriba wrote:
>>> Conversion from two such types that have the same data member types but
>>> with different data member names would be desirable.
>>
>> Uh... no. No it isn't. (Not implicitly, at least! See my other post for
>> an example why.)
>
> Agreed, your example polar/cartesian is an example where the tags are
> giving meaning to the type. However I don't believe this is the correct
> way, the double should be different in polar and cartesian.
I'm not sure I agree, but at worst that just means I gave a bad example.
There surely exists aggregates with the same layout but significantly
different semantics. (Heck, there exist aliases for the same *primitive
types* that have significantly different semantics. Just consider the
reasons that folks want strong type aliases.)
> Note also that we have conversion from pair to tuple and this doesn't
> surprise anyone.
Yes, but I also expect that; neither pair nor tuple assigns any meaning
to their members other than what is imparted by the members' indices.
IOW, std::pair<T, U> and std::tuple<T, U> are semantically equivalent.
This is *NOT* necessarily true for two aggregates with the same layout.
(It also, to be fair, isn't necessarily *false* either, but...)
>> And I'd still prefer to see this, for doing so explicitly:
>>
>> struct { int a; double b; } x;
>> struct { int c; double d; } y;
>> x =3D ...;
>> y =3D { [*]x };
>
> Yes, I remember the (python like) thread.
:-)
The main point there, however, should be that it (IMHO) makes more sense
to have a really cheap (to type) way to explicitly force conversion
between different-but-same-layout aggregates. Declaring aggregates to be
tuple-like already gets us partway there, as provides some hope that
we'll eventually have something like the above. (That said, I'd bet
there are ways to do this with library tricks already.)
If we have such a method, the "need" for implicit conversions is
significantly reduced.
To be clear, I *do* think it would be useful to have a way to
*explicitly* convert between layout-compatible aggregates. I just feel
that the key word there is "explicit".
--=20
Matthew
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 1 Jan 2016 13:24:24 +0100
Raw View
Le 31/12/2015 19:03, Matthew Woehlke a =C3=A9crit :
> On 2015-12-31 12:15, Vicente J. Botet Escriba wrote:
>> Le 31/12/2015 15:52, Matthew Woehlke a =C3=A9crit :
>>> On 2015-12-31 06:45, Vicente J. Botet Escriba wrote:
>>>> Conversion from two such types that have the same data member types bu=
t
>>>> with different data member names would be desirable.
>>> Uh... no. No it isn't. (Not implicitly, at least! See my other post for
>>> an example why.)
>> Agreed, your example polar/cartesian is an example where the tags are
>> giving meaning to the type. However I don't believe this is the correct
>> way, the double should be different in polar and cartesian.
> I'm not sure I agree, but at worst that just means I gave a bad example.
> There surely exists aggregates with the same layout but significantly
> different semantics. (Heck, there exist aliases for the same *primitive
> types* that have significantly different semantics. Just consider the
> reasons that folks want strong type aliases.)
After reflection, I agree with you and the tags should be part of the types=
..
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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 2 Jan 2016 12:25:16 +0100
Raw View
This is a multi-part message in MIME format.
--------------000804090703080409010905
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 31/12/2015 13:28, Giovanni Piero Deretta a =C3=A9crit :
> On Thursday, December 31, 2015 at 11:45:27 AM UTC, Vicente J. Botet=20
> Escriba wrote:
>
>
> What I'm looking for and I believe we need is that
>
> is_same<KEYWORD { int x; const char* y; }, KEYWORD { int x;
> const char* y; }>
>
>
> are you sure you need is_same to hold (i.e. nominal type equality) ...
Well, I'm not sure. Relaxing [dcl.fct]/11 seems to need some kind of=20
type equality. Having nominal typing seems to make things simpler, but=20
maybe I'm wrong.
>
>
> [...]
>
> That is, KEYWORD {...} would just be another way to construct new
> types, as we do with T*, T&, const T, volatile T, T[n].
>
>
> KEYWORD {} could be limited to contain only data members. The
> extreme case could be that the member data are even unnamed
>
> KEYWORD { int ; const char*; }
>
> This should define almost the same as tuple<int, const char*>.
>
>
> instead of just:
>
> Conversion from two such types that have the same data member
> types but with different data member names would be desirable.
>
After some more thought and Andrew polar/cartesian example, I believe=20
that this structural conversion should be explicit.
>
> Conversion(promotion) from two such types that have the
> convertible data member types would be desirable.
>
>
> i.e. some sort of opt-in structural typing.
I need either structural typing or nominal typing equality. Which one is=20
the better? For the time been I'm going towards nominal typing.
>
>
> If in addition std::pair<T,U> were convertible from any type
> KEYWORD { T _1; U _2;} (for any field names), the backward
> compatibility issue could be almost ensured. How to define this
> conversion needs more insight.
>
> The question is then if we want to define something new at the
> language level that represents a named tuple that could be used in
> particular to return multiple values from a function.
>
>
>
> I was toying with a possible language extension (a ` quote operator)=20
> to lift symbols to first class values that would allow:
>
> auto t =3D std::tup(`first =3D 10, `second =3D "hello"s); // t has .firs=
t=20
> and .second members of appropriate types
Yes, [DESIGNATED_INIT] are on the list of things to consider and=20
associate the type to an aggregate initializer
auto t =3D {`first =3D 10, `second =3D "hello"s};
[DESIGNATED_INIT]:=20
https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html "Designated=20
initializers"
>
> struct { int first; std::string second; } s =3D t; // ok
>
> std::pair<int, std::string> p =3D t; // also ok
>
> A pure macro based implementation here :=20
> https://github.com/gpderetta/libtask/blob/broken/tests/q_test.cpp
I'm missing the file
#include "q.hpp"
>
> It uses the $(<symbol>) syntax instead of `<symbol>, but it is=20
> otherwise complete.
>
> The library approach uses lambdas under the hood, so you can't put a=20
> $(<symbol>) expression directly inside decltype for now.
Please, could you elaborate. I don't see what are you looking for.
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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--------------000804090703080409010905
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 31/12/2015 13:28, Giovanni Piero
Deretta a =C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:559c396c-c662-4940-8d85-5ba6ccc7626e@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">On Thursday, December 31, 2015 at 11:45:27 AM UTC,
Vicente J. Botet Escriba wrote:
<div><br>
<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div> What I'm looking for and I believe we need is that<br>
<br>
=C2=A0=C2=A0=C2=A0 is_same<KEYWORD { int x; const char* y; }=
, KEYWORD {
int x; const char* y; }><br>
</div>
</blockquote>
<div><br>
are you sure you need is_same to hold=C2=A0 (i.e. nominal type
equality) ...<br>
</div>
</div>
</blockquote>
Well, I'm not sure. Relaxing=C2=A0 [dcl.fct]/11 seems to need some kind
of type equality. Having nominal typing seems to make things
simpler, but maybe I'm wrong.<br>
<blockquote
cite=3D"mid:559c396c-c662-4940-8d85-5ba6ccc7626e@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div> <br>
[...] <br>
</div>
</blockquote>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"> That is, KEYWORD {...}
would just be another way to construct new types, as we do
with T*, T&, const T, volatile T, T[n].<br>
</div>
</blockquote>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"> <br>
KEYWORD {} could be limited to contain only data members.
The extreme case could be that the member data are even
unnamed<br>
<br>
=C2=A0=C2=A0=C2=A0 KEYWORD { int ; const char*; }<br>
<br>
This should define almost the same as tuple<int, const
char*>.<br>
<br>
</div>
</blockquote>
<div><br>
instead of just:<br>
=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"> Conversion from two
such types that have the same data member types but with
different data member names would be desirable.<br>
</div>
</blockquote>
</div>
</blockquote>
After some more thought and Andrew polar/cartesian example, I
believe that this structural conversion should be explicit.<br>
<blockquote
cite=3D"mid:559c396c-c662-4940-8d85-5ba6ccc7626e@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"> Conversion(promotion)
from two such types that have the convertible data member
types would be desirable.<br>
</div>
</blockquote>
<div><br>
i.e. some sort of opt-in structural typing.<br>
</div>
</div>
</blockquote>
I need either structural typing or nominal typing equality. Which
one is the better? For the time been I'm going towards nominal
typing.<br>
<blockquote
cite=3D"mid:559c396c-c662-4940-8d85-5ba6ccc7626e@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"> <br>
If in addition std::pair<T,U> were convertible from
any type KEYWORD { T _1; U _2;} (for any field names), the
backward compatibility issue could be almost ensured. How to
define this conversion needs more insight.<br>
<br>
The question is then if we want to define something new at
the language level that represents a named tuple that could
be used in particular to return multiple values from a
function.<br>
<br>
<br>
</div>
</blockquote>
<div><br>
I was toying with a possible language extension (a ` quote
operator) to lift symbols to first class values that would
allow:<br>
<br>
auto t =3D=C2=A0 std::tup(`first =3D 10, `second =3D "hello"s); /=
/ t has
.first and .second members of appropriate types<br>
</div>
</div>
</blockquote>
Yes, [DESIGNATED_INIT] are on the list of things to consider and
associate the type to an aggregate initializer<br>
<br>
auto t =3D=C2=A0 {`first =3D 10, `second =3D "hello"s}; <br>
<br>
<br>
[DESIGNATED_INIT]:
<a class=3D"moz-txt-link-freetext" href=3D"https://gcc.gnu.org/onlinedo=
cs/gcc/Designated-Inits.html">https://gcc.gnu.org/onlinedocs/gcc/Designated=
-Inits.html</a> "Designated
initializers"<br>
<blockquote
cite=3D"mid:559c396c-c662-4940-8d85-5ba6ccc7626e@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div><br>
struct { int first; std::string second; } s =3D t; // ok<br>
<br>
std::pair<int, std::string> p =3D t; // also ok<br>
<br>
A pure macro based implementation here :
<a class=3D"moz-txt-link-freetext" href=3D"https://github.com/gpd=
eretta/libtask/blob/broken/tests/q_test.cpp">https://github.com/gpderetta/l=
ibtask/blob/broken/tests/q_test.cpp</a><br>
</div>
</div>
</blockquote>
I'm missing the file <br>
<br>
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8=
">
#<span class=3D"pl-k">include</span> <span class=3D"pl-s"><span
class=3D"pl-pds">"</span>q.hpp<span class=3D"pl-pds">"</span></span=
><br>
<blockquote
cite=3D"mid:559c396c-c662-4940-8d85-5ba6ccc7626e@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div><br>
It uses the $(<symbol>) syntax instead of
`<symbol>, but it is otherwise complete.<br>
<br>
The library approach uses lambdas under the hood, so you can't
put a $(<symbol>) expression directly inside decltype
for now.<br>
</div>
</div>
</blockquote>
Please, could you elaborate. I don't see what are you looking for.<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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--------------000804090703080409010905--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 2 Jan 2016 19:07:15 -0800 (PST)
Raw View
------=_Part_2623_359251110.1451790435639
Content-Type: multipart/alternative;
boundary="----=_Part_2624_1638407232.1451790435639"
------=_Part_2624_1638407232.1451790435639
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, December 30, 2015 at 8:20:35 AM UTC-5, Vicente J. Botet=20
Escriba wrote:
>
> Hi,
>
> n4560 introduce the classes tagged, tagged_pair and tagged_tuple. Here=20
> follows the rationale as described in n4560:
>
> *[Editor=E2=80=99s note: This type exists so that the algorithms can retu=
rn pair-=20
> and tuple-like objects with named accessors, as requested by LEWG. Rather=
=20
> than create a bunch of one-off class types with no relation to pair and=
=20
> tuple, I opted instead to create a general utility. I=E2=80=99ll note tha=
t this=20
> functionality can be merged into pair and tuple directly with minimal=20
> breakage, but I opted for now to keep it separate.]*
>
>
> I was wondering if
>
> tagged_pair<tag::in(I), tag::fun(Fun)>
>
> couldn't be better be represented by the unnamed aggregate
>
> struct {
> I in;
> Fun fun;
> }
>
> which has less noise.
>
Here's a question.
From my perspective, the principle reason to use a tuple is=20
*metaprogramming*. That is, you're assembling an aggregation of values from=
=20
some some user-provided construct. A tagged tuple has limited=20
metaprogramming value, but it still has some value in that regard. By=20
tagging types with names, you can develop interfaces between the sender and=
=20
the receiver of a tuple that allow you to more effectively communicate.=20
Rather than communicating by type or index, you communicate by a name, thus=
=20
giving the sending code the freedom to pick and choose where the element is=
=20
in the tuple.
That's the reason why we need tagged tuples, and the above case won't even=
=20
touch that one. Reflection-based aggregate creation might fix it, but=20
that's for C++20, if even that.
Using a tuple for plain-old multiple-return-values has always been, to me,=
=20
of somewhat dubious merit. It's not a terrible, and it's a solution that'll=
=20
be far more acceptable with structured binding. But using a *tagged* tuple=
=20
as a return value from a concrete function? No; that makes no sense.
Clearly you should be returning a struct. But that's where I don't get the=
=20
point of this proposal. Because, well, why does it *have to be* "unnamed"?=
=20
I mean, are names *that precious* that we need to have specialized syntax=
=20
to do this? Is this:
struct {int x; float y} func() {...}
Really that much better than this?
struct MeaningfulName {int x; float y};
MeaningfulName func() {...}
If the type returned by this function needs to name the individual multiple=
=20
values, then that aggregation of values probably has some meaning. 9 times=
=20
out of 10, other functions will want to return that same type. So you're=20
going to need a named type.
Just consider the main confounding problem of this proposal:
struct {int x; float y} other_func() {...}
struct {int x; float y} func() {return other_func();}
Even if we found a way to make this work, I don't really want to *see it*.=
=20
When I look at this code, I see repetition; I see the same type being=20
written twice. I see someone who has not created a named type who clearly *=
ought=20
to*.
After all, what is the point of assigning names to the members of the=20
return value? It's so that the receiver of the object knows what those=20
values mean. So that we don't have the `map::insert` idiocy where=20
"ret.second" is what tells you whether the object was correctly inserted.
If so... you need a struct. A *named* struct. `std::map` proves that, since=
=20
it has several interface functions that all return the same `pair<iterator,=
=20
bool>`, and all of them have the same meaning (the bool tells whether=20
insertion happened, the iterator says where the element is). If two types=
=20
have the same functionality and meaning, they are the same type.
And in C++, we declare two types to be the same by giving them the same=20
name.
So it seems to me that unnamed struct return values would only be useful in=
=20
cases where:
1) `tuple` is inappropriate. This would suggest that the semantic meaning=
=20
of each independent return value is both significant and not obvious from=
=20
just the type and function name (`pair` returned from `map::insert` is a=20
good example). And `tagged_tuple`, well, sucks at this for obvious reasons.
2) That function is the *only function* that returns this type or does=20
anything with it in any way. If the function has even one other overload,=
=20
then you ought to use a named type.
How often do you encounter both #1 and #2? Is this often enough to justify=
=20
such a language feature? With structured binding making tuples far more=20
usable for MRV than they have ever been, I just can't understand why we=20
need unnamed struct returns like this.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
------=_Part_2624_1638407232.1451790435639
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, December 30, 2015 at 8:20:35 AM UTC-5, Vicente J. Botet Escri=
ba wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
Hi,<br>
<br>
n4560 introduce the classes tagged, tagged_pair and tagged_tuple.
Here follows the rationale as described in n4560:<br>
=20
<br>
<i>[Editor=E2=80=99s note: This type exists so that the algorithms can
return pair- and tuple-like objects with named
accessors, as requested by LEWG. Rather than create a bunch of
one-off class types with no relation to pair
and tuple, I opted instead to create a general utility. I=E2=80=99ll =
note
that this functionality can be merged into
pair and tuple directly with minimal breakage, but I opted for now
to keep it separate.]</i><i><br>
</i><br>
<br>
I was wondering if<br>
<br>
=C2=A0=C2=A0=C2=A0 tagged_pair<tag::in(I), tag::fun(Fun)><br>
<br>
couldn't be better be represented by the unnamed aggregate<br>
<br>
=C2=A0=C2=A0=C2=A0 struct {<br>
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 I in;<br>
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Fun fun;<br>
=C2=A0=C2=A0=C2=A0 }<br>
<br>
which has less noise.<br></div></blockquote><br>Here's a question.<=
br><br>From my perspective, the principle reason to use a tuple is <i>metap=
rogramming</i>. That is, you're assembling an aggregation of values fro=
m some some user-provided construct. A tagged tuple has limited metaprogram=
ming value, but it still has some value in that regard. By tagging types wi=
th names, you can develop interfaces between the sender and the receiver of=
a tuple that allow you to more effectively communicate. Rather than commun=
icating by type or index, you communicate by a name, thus giving the sendin=
g code the freedom to pick and choose where the element is in the tuple.<br=
><br>That's the reason why we need tagged tuples, and the above case wo=
n't even touch that one. Reflection-based aggregate creation might fix =
it, but that's for C++20, if even that.<br><br>Using a tuple for plain-=
old multiple-return-values has always been, to me, of somewhat dubious meri=
t. It's not a terrible, and it's a solution that'll be far more=
acceptable with structured binding. But using a <i>tagged</i> tuple as a r=
eturn value from a concrete function? No; that makes no sense.<br><br>Clear=
ly you should be returning a struct. But that's where I don't get t=
he point of this proposal. Because, well, why does it <i>have to be</i> &qu=
ot;unnamed"? I mean, are names <i>that precious</i> that we need to ha=
ve specialized syntax to do this? Is this:<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"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{</span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> x</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"styled-by-prettify">float</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> y</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> func</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">{...}</span></div></code></div><br>Really that much better =
than this?<br><br><div class=3D"prettyprint" style=3D"background-color: rgb=
(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bor=
der-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div cl=
ass=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">struct</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Meaning=
fulName</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"colo=
r: #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">float</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> y</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br><br></span><span style=3D"color: #606;" class=3D"styled-by-prettify">Me=
aningfulName</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> func</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">{...}</span></div></=
code></div><br>If the type returned by this function needs to name the indi=
vidual multiple values, then that aggregation of values probably has some m=
eaning. 9 times out of 10, other functions will want to return that same ty=
pe. So you're going to need a named type.<br><br>Just consider the main=
confounding problem of this proposal:<br><br><div class=3D"prettyprint" st=
yle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 18=
7); border-style: solid; border-width: 1px; word-wrap: break-word;"><code c=
lass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">struct</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">{</span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">float</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> y</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> other_func</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">{...}</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">struct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">float</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> y</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> func</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> other_func</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">();}</span></div></code></div><=
br>Even if we found a way to make this work, I don't really want to <i>=
see it</i>. When I look at this code, I see repetition; I see the same type=
being written twice. I see someone who has not created a named type who cl=
early <i>ought to</i>.<br><br>After all, what is the point of assigning nam=
es to the members of the return value? It's so that the receiver of the=
object knows what those values mean. So that we don't have the `map::i=
nsert` idiocy where "ret.second" is what tells you whether the ob=
ject was correctly inserted.<br><br>If so... you need a struct. A <i>named<=
/i> struct. `std::map` proves that, since it has several interface function=
s that all return the same `pair<iterator, bool>`, and all of them ha=
ve the same meaning (the bool tells whether insertion happened, the iterato=
r says where the element is). If two types have the same functionality and =
meaning, they are the same type.<br><br>And in C++, we declare two types to=
be the same by giving them the same name.<br><br>So it seems to me that un=
named struct return values would only be useful in cases where:<br><br>1) `=
tuple` is inappropriate. This would suggest that the semantic meaning of ea=
ch independent return value is both significant and not obvious from just t=
he type and function name (`pair` returned from `map::insert` is a good exa=
mple). And `tagged_tuple`, well, sucks at this for obvious reasons.<br><br>=
2) That function is the <i>only function</i> that returns this type or does=
anything with it in any way. If the function has even one other overload, =
then you ought to use a named type.<br><br>How often do you encounter both =
#1 and #2? Is this often enough to justify such a language feature? With st=
ructured binding making tuples far more usable for MRV than they have ever =
been, I just can't understand why we need unnamed struct returns like t=
his.<br>
<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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_2624_1638407232.1451790435639--
------=_Part_2623_359251110.1451790435639--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 04 Jan 2016 12:08:43 -0500
Raw View
On 2016-01-02 22:07, Nicol Bolas wrote:
> [...]
> Clearly you should be returning a struct. But that's where I don't get th=
e=20
> point of this proposal. Because, well, why does it *have to be* "unnamed"=
?=20
> I mean, are names *that precious*=20
Yes. Imagine you have five methods in a class that have MRV's. What do
you name them?
Naming things is *hard*. Naming multiple return values=C2=B9 is *especially=
*
hard, and bloats the API unnecessarily. The more often MRV's are used,
the worse the problem becomes.
See also Vicente's response to this point. Remember, we're talking about
the cost of naming *one-off* structures.
On the flip side, I will continue to maintain that the prohibition is
unnecessary in the first place. If we were adding complexity to the
language, I would be inclined to give greater weight to your arguments.
But we're not. We're *removing* a restriction that no longer makes
sense. The net change to the standard is a *removal*... of a whole two
words, at that. Moreover, that restriction is not even uniformly
implemented in current compilers.
Note also that *allowing* anonymous struct returns is different from
*requiring* them; folks that think they should be named will still be
able to name them :-).
(=C2=B9 Except when it isn't, and they're already named.)
> that we need to have specialized syntax to do this?
"No"... but IRTVPDUA especially isn't *just* about this, but about any
instance where repeating the typename is "hard". And the [dcl.fct]/11
prohibition is just unnecessary. (Also, what about lambdas; will you
create a local struct
> 9 times out of 10, other functions will want to return that same
> type. So you're going to need a named type.
Such functions are likely *already using* named types, and have been
doing so for a long time (pre-C++11 even).
> Just consider the main confounding problem of this proposal:
>=20
> struct {int x; float y} other_func() {...}
> struct {int x; float y} func() {return other_func();}
>=20
> Even if we found a way to make this work, I don't really want to *see it*=
..=20
> When I look at this code, I see repetition; I see the same type being=20
> written twice. I see someone who has not created a named type who clearly=
*ought=20
> to*.
This sounds like a good reason to continue to make that case difficult.
Note that the IRTVPDUA proposal intentionally does not attempt to
"solve" this case.
That said, I can give you an excellent reason why you may *want*
something like this to work (named types or not, even)... library
boundaries. Perhaps other_func() is in a library ("A") that is used
privately by the library providing func() ("B"), whose implementation
details should not be leaked to users of "B".
> So it seems to me that unnamed struct return values would only be useful =
in=20
> cases where:
>=20
> 1) `tuple` is inappropriate. This would suggest that the semantic meaning=
=20
> of each independent return value is both significant and not obvious from=
=20
> just the type and function name (`pair` returned from `map::insert` is a=
=20
> good example). And `tagged_tuple`, well, sucks at this for obvious reason=
s.
Sure.
> 2) That function is the *only function* that returns this type or does=20
> anything with it in any way. If the function has even one other overload,=
=20
> then you ought to use a named type.
Fair enough.
> How often do you encounter both #1 and #2? Is this often enough to justif=
y=20
> such a language feature?
Maybe not on its own. However, these are also not the only reasons. Some
have even suggested that IRTVPDUA especially has its major justification
*apart from* being able to return anonymous structs. Personally, I am
somewhat indifferent on that point; I consider that IRTVPDUA is just a
useful and obvious feature, without being strongly opinionated on
whether anonymous structs or other things are the most important use case.
> With structured binding making tuples far more usable for MRV than
> they have ever been, I just can't understand why we need unnamed
> struct returns like this.
Structured binding, if anything, makes this feature (returning anonymous
structs) *more* useful. You already gave the main reason, in your (1) above=
..
--=20
Matthew
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.