Topic: Ideas for extending std::tuple with field-name
Author: "'Johannes Schaub' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 12 Oct 2016 13:54:02 +0200
Raw View
2016-10-12 13:48 GMT+02:00 Johannes Schaub <schaub.johannes@googlemail.com>:
> Hello all,
>
> Using type-tags to access tuple fields is a common technique to access
> fields by "name"
>
> struct position_tag : type<double> { };
> struct color_tag : type<QColor> { };
>
> my_tuple<field<position_tag, color_tag> m;
>
> QColor c1 = std::get<color_tag>(m);
> QColor c2 = std::get<QColor>(m);
> QColor c3 = std::get<1>(m);
>
> I was thinking about extending std::tuple with support for tags. This
> can be done (i believe) most straight forward with string template
> arguments, if we would have support for them in the future
>
> std::tuple<field<double, "position">, field<QColor, "color">> getStop();
>
> auto m = getStop();
> double pos = std::get<"position">(m);
>
> An alternative (but uglier) implementation would abuse unnamed struct
> definitions in template-arguments with the "type" baseclass of above
> to communicate the type
>
> std::tuple<struct : typed<double> { type position; },
> struct : typed<QColor> { type color; }> getStop();
>
> Here, "type" is declared in base-class "typed" as a type-alias for its
> template-parameter. When tuple sees a parameter has "typed<T>" as a
> base class, it inherits from it. Therefore you could write
>
> auto m = getStop();
> QColor c = m.color;
>
> std::get<N> would cast the unnamed-struct to "struct_type::type",
> requiring a standard-layout struct (can be tested-for with a
> type-trait). So the unnamed-struct cannot "escape" to the users of the
> tuple.
>
> What do you think about the two approaches? Are there existing papers
> about perhaps other techniques?
And, a more important question: Do we need proposals for extending
std::tuple this way, or would unnamed-struct definitions in function
return types satisfy this use-case better?
struct { double position; QColor color; } getStop();
auto m = getStop();
QColor c1 = m.color;
QColor c2 = std::get<QColor>(m);
QColor c3 = std::get<1>(m);
Is there any drawback from using this technique over extending
std::tuple? As far as I'm aware, the generic functions in std:: that
operate on tuples do so by facilitating std::tuple_size, std::get etc,
so they could equally work on these one-off structs, right (of course,
it would need some "built-in" support from the implementation to
inspect above unnamed struct without the user having to write
specializations for those tuple traits, I guess?).
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANu6V4W6ahF9QpfwXyb08965XCONdounDV1zf39-OnKNLWq%3DBw%40mail.gmail.com.
.
Author: TONGARI J <tongari95@gmail.com>
Date: Wed, 12 Oct 2016 06:09:19 -0700 (PDT)
Raw View
------=_Part_8590_506358446.1476277760037
Content-Type: multipart/alternative;
boundary="----=_Part_8591_1760422009.1476277760038"
------=_Part_8591_1760422009.1476277760038
Content-Type: text/plain; charset=UTF-8
On Wednesday, October 12, 2016 at 7:48:24 PM UTC+8, Johannes Schaub wrote:
>
> Hello all,
>
> Using type-tags to access tuple fields is a common technique to access
> fields by "name"
>
> struct position_tag : type<double> { };
> struct color_tag : type<QColor> { };
>
> my_tuple<field<position_tag, color_tag> m;
>
> QColor c1 = std::get<color_tag>(m);
> QColor c2 = std::get<QColor>(m);
> QColor c3 = std::get<1>(m);
>
> I was thinking about extending std::tuple with support for tags. This
> can be done (i believe) most straight forward with string template
> arguments, if we would have support for them in the future
>
> std::tuple<field<double, "position">, field<QColor, "color">>
> getStop();
>
> auto m = getStop();
> double pos = std::get<"position">(m);
>
> An alternative (but uglier) implementation would abuse unnamed struct
> definitions in template-arguments with the "type" baseclass of above
> to communicate the type
>
> std::tuple<struct : typed<double> { type position; },
> struct : typed<QColor> { type color; }> getStop();
>
> Here, "type" is declared in base-class "typed" as a type-alias for its
> template-parameter. When tuple sees a parameter has "typed<T>" as a
> base class, it inherits from it. Therefore you could write
>
> auto m = getStop();
> QColor c = m.color;
>
> std::get<N> would cast the unnamed-struct to "struct_type::type",
> requiring a standard-layout struct (can be tested-for with a
> type-trait). So the unnamed-struct cannot "escape" to the users of the
> tuple.
>
> What do you think about the two approaches? Are there existing papers
> about perhaps other techniques?
>
I'm not aware of any existing proposal, but some experimental language
features I'm developing will allow you to do this:
std::tuple<double.position, QColor.color> getStop();
auto m = getStop();
double pos = m.position;
QColor c = m.color;
Let me know if you need more detail.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/19048c95-770c-4413-b5ff-aa405c389621%40isocpp.org.
------=_Part_8591_1760422009.1476277760038
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, October 12, 2016 at 7:48:24 PM UTC+8, Johann=
es Schaub wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hello all,
<br>
<br>Using type-tags to access tuple fields is a common technique to access
<br>fields by "name"
<br>
<br>=C2=A0 =C2=A0 struct position_tag : type<double> { };
<br>=C2=A0 =C2=A0 struct color_tag : type<QColor> { };
<br>
<br>=C2=A0 =C2=A0 my_tuple<field<position_tag, color_tag> m;
<br>
<br>=C2=A0 =C2=A0 QColor c1 =3D std::get<color_tag>(m);
<br>=C2=A0 =C2=A0 QColor c2 =3D std::get<QColor>(m);
<br>=C2=A0 =C2=A0 QColor c3 =3D std::get<1>(m);
<br>
<br>I was thinking about extending std::tuple with support for tags. This
<br>can be done (i believe) most straight forward with string template
<br>arguments, if we would have support for them in the future
<br>
<br>=C2=A0 =C2=A0 std::tuple<field<double, "position">, =
field<QColor, "color">> getStop();
<br>
<br>=C2=A0 =C2=A0 auto m =3D getStop();
<br>=C2=A0 =C2=A0 double pos =3D std::get<"position">(m);
<br>
<br>An alternative (but uglier) implementation would abuse unnamed struct
<br>definitions in template-arguments with the "type" baseclass o=
f above
<br>to communicate the type
<br>
<br>=C2=A0 =C2=A0 std::tuple<struct : typed<double> { type positio=
n; },
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0struct : typed<QColor> { type color; }> getStop();
<br>
<br>Here, "type" is declared in base-class "typed" as a=
type-alias for its
<br>template-parameter. When tuple sees a parameter has "typed<T>=
;" as a
<br>base class, it inherits from it. Therefore you could write
<br>
<br>=C2=A0 =C2=A0 auto m =3D getStop();
<br>=C2=A0 =C2=A0 QColor c =3D m.color;
<br>
<br>std::get<N> would cast the unnamed-struct to "struct_type::t=
ype",
<br>requiring a standard-layout struct (can be tested-for with a
<br>type-trait). So the unnamed-struct cannot "escape" to the use=
rs of the
<br>tuple.
<br>
<br>What do you think about the two approaches? Are there existing papers
<br>about perhaps other techniques?
<br></blockquote><div><br></div><div>I'm not aware of any existing prop=
osal, but some experimental language features I'm developing will allow=
you to do this:</div><div><br></div><div class=3D"prettyprint" style=3D"ba=
ckground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); borde=
r-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"p=
rettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">tuple</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify"><</span><span style=3D"color: #008;" class=3D"styled-by-prettify">d=
ouble</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">position</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">QColor</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">color</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> getStop</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">();</span></div><div class=3D"subprettyprint"><span style=
=3D"color: #000;" class=3D"styled-by-prettify"></span><span style=3D"color:=
#008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> m </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> getStop</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> <br></span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">double</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
pos </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> m</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">position</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: #60=
6;" class=3D"styled-by-prettify">QColor</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> c </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> m</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
color</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span></div>=
</code></div><div><br>Let me know if you need more detail.</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/19048c95-770c-4413-b5ff-aa405c389621%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/19048c95-770c-4413-b5ff-aa405c389621=
%40isocpp.org</a>.<br />
------=_Part_8591_1760422009.1476277760038--
------=_Part_8590_506358446.1476277760037--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 12 Oct 2016 07:02:29 -0700 (PDT)
Raw View
------=_Part_1137_184927517.1476280949984
Content-Type: multipart/alternative;
boundary="----=_Part_1138_1505659210.1476280949984"
------=_Part_1138_1505659210.1476280949984
Content-Type: text/plain; charset=UTF-8
On Wednesday, October 12, 2016 at 7:48:24 AM UTC-4, Johannes Schaub wrote:
>
> Hello all,
>
> Using type-tags to access tuple fields is a common technique to access
> fields by "name"
>
> struct position_tag : type<double> { };
> struct color_tag : type<QColor> { };
>
> my_tuple<field<position_tag, color_tag> m;
>
> QColor c1 = std::get<color_tag>(m);
> QColor c2 = std::get<QColor>(m);
> QColor c3 = std::get<1>(m);
>
> I was thinking about extending std::tuple with support for tags. This
> can be done (i believe) most straight forward with string template
> arguments, if we would have support for them in the future
>
> std::tuple<field<double, "position">, field<QColor, "color">>
> getStop();
>
> auto m = getStop();
> double pos = std::get<"position">(m);
>
> An alternative (but uglier) implementation would abuse unnamed struct
> definitions in template-arguments with the "type" baseclass of above
> to communicate the type
>
> std::tuple<struct : typed<double> { type position; },
> struct : typed<QColor> { type color; }> getStop();
>
> Here, "type" is declared in base-class "typed" as a type-alias for its
> template-parameter. When tuple sees a parameter has "typed<T>" as a
> base class, it inherits from it. Therefore you could write
>
> auto m = getStop();
> QColor c = m.color;
>
> std::get<N> would cast the unnamed-struct to "struct_type::type",
> requiring a standard-layout struct (can be tested-for with a
> type-trait). So the unnamed-struct cannot "escape" to the users of the
> tuple.
>
> What do you think about the two approaches? Are there existing papers
> about perhaps other techniques?
>
There are two kinds of uses of tuple. The first kind is for writing
quick-and-dirty classes, because you don't feel like writing an actual
type. The second kind is for metaprogramming uses, where you're grouping
together things by position.
For the latter use, naming tuple elements makes no sense, as the elements
only have meaning by their positions. For the former, it would be better to
allow people to create anonymous structs in various places, thus avoiding
the use of tuples for these types to begin with.
We *certainly* should not be entertaining any language-based mechanisms to
add these kinds of things in.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ad4e8bc-ee9c-454b-a1ce-bbe7a64c460a%40isocpp.org.
------=_Part_1138_1505659210.1476280949984
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, October 12, 2016 at 7:48:24 AM UTC-4=
, Johannes Schaub wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hello =
all,
<br>
<br>Using type-tags to access tuple fields is a common technique to access
<br>fields by "name"
<br>
<br>=C2=A0 =C2=A0 struct position_tag : type<double> { };
<br>=C2=A0 =C2=A0 struct color_tag : type<QColor> { };
<br>
<br>=C2=A0 =C2=A0 my_tuple<field<position_tag, color_tag> m;
<br>
<br>=C2=A0 =C2=A0 QColor c1 =3D std::get<color_tag>(m);
<br>=C2=A0 =C2=A0 QColor c2 =3D std::get<QColor>(m);
<br>=C2=A0 =C2=A0 QColor c3 =3D std::get<1>(m);
<br>
<br>I was thinking about extending std::tuple with support for tags. This
<br>can be done (i believe) most straight forward with string template
<br>arguments, if we would have support for them in the future
<br>
<br>=C2=A0 =C2=A0 std::tuple<field<double, "position">, =
field<QColor, "color">> getStop();
<br>
<br>=C2=A0 =C2=A0 auto m =3D getStop();
<br>=C2=A0 =C2=A0 double pos =3D std::get<"position">(m);
<br>
<br>An alternative (but uglier) implementation would abuse unnamed struct
<br>definitions in template-arguments with the "type" baseclass o=
f above
<br>to communicate the type
<br>
<br>=C2=A0 =C2=A0 std::tuple<struct : typed<double> { type positio=
n; },
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0struct : typed<QColor> { type color; }> getStop();
<br>
<br>Here, "type" is declared in base-class "typed" as a=
type-alias for its
<br>template-parameter. When tuple sees a parameter has "typed<T>=
;" as a
<br>base class, it inherits from it. Therefore you could write
<br>
<br>=C2=A0 =C2=A0 auto m =3D getStop();
<br>=C2=A0 =C2=A0 QColor c =3D m.color;
<br>
<br>std::get<N> would cast the unnamed-struct to "struct_type::t=
ype",
<br>requiring a standard-layout struct (can be tested-for with a
<br>type-trait). So the unnamed-struct cannot "escape" to the use=
rs of the
<br>tuple.
<br>
<br>What do you think about the two approaches? Are there existing papers
<br>about perhaps other techniques?
<br></blockquote><div><br>There are two kinds of uses of tuple. The first k=
ind is for writing quick-and-dirty classes, because you don't feel like=
writing an actual type. The second kind is for metaprogramming uses, where=
you're grouping together things by position.<br><br>For the latter use=
, naming tuple elements makes no sense, as the elements only have meaning b=
y their positions. For the former, it would be better to allow people to cr=
eate anonymous structs in various places, thus avoiding the use of tuples f=
or these types to begin with.<br><br>We <i>certainly</i> should not be ente=
rtaining any language-based mechanisms to add these kinds of things in.<br>=
</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9ad4e8bc-ee9c-454b-a1ce-bbe7a64c460a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9ad4e8bc-ee9c-454b-a1ce-bbe7a64c460a=
%40isocpp.org</a>.<br />
------=_Part_1138_1505659210.1476280949984--
------=_Part_1137_184927517.1476280949984--
.
Author: Larry Evans <cppljevans@suddenlink.net>
Date: Wed, 12 Oct 2016 13:56:11 -0500
Raw View
On 10/12/2016 09:02 AM, Nicol Bolas wrote:
>
>
> On Wednesday, October 12, 2016 at 7:48:24 AM UTC-4, Johannes Schaub wrote:
>
> Hello all,
>
> Using type-tags to access tuple fields is a common technique to access
> fields by "name"
>
> struct position_tag : type<double> { };
> struct color_tag : type<QColor> { };
>
> my_tuple<field<position_tag, color_tag> m;
>
> QColor c1 = std::get<color_tag>(m);
> QColor c2 = std::get<QColor>(m);
> QColor c3 = std::get<1>(m);
>
> I was thinking about extending std::tuple with support for tags. This
> can be done (i believe) most straight forward with string template
> arguments, if we would have support for them in the future
>
> std::tuple<field<double, "position">, field<QColor, "color">>
> getStop();
>
> auto m = getStop();
> double pos = std::get<"position">(m);
>
> An alternative (but uglier) implementation would abuse unnamed struct
> definitions in template-arguments with the "type" baseclass of above
> to communicate the type
>
> std::tuple<struct : typed<double> { type position; },
> struct : typed<QColor> { type color; }> getStop();
>
> Here, "type" is declared in base-class "typed" as a type-alias for its
> template-parameter. When tuple sees a parameter has "typed<T>" as a
> base class, it inherits from it. Therefore you could write
>
> auto m = getStop();
> QColor c = m.color;
>
> std::get<N> would cast the unnamed-struct to "struct_type::type",
> requiring a standard-layout struct (can be tested-for with a
> type-trait). So the unnamed-struct cannot "escape" to the users of the
> tuple.
>
> What do you think about the two approaches? Are there existing papers
> about perhaps other techniques?
>
>
> There are two kinds of uses of tuple. The first kind is for writing
> quick-and-dirty classes, because you don't feel like writing an actual
> type. The second kind is for metaprogramming uses, where you're grouping
> together things by position.
>
> For the latter use, naming tuple elements makes no sense, as the
> elements only have meaning by their positions. For the former, it would
> be better to allow people to create anonymous structs in various places,
> thus avoiding the use of tuples for these types to begin with.
>
> We /certainly/ should not be entertaining any language-based mechanisms
> to add these kinds of things in.
>
Nicolas, in another thread:
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/pk4s49YJpUg/CgprxLydEgAJ
gave, IIUC, a similar argument:
From my perspective, the principle reason to use a tuple
is metaprogramming. That is, you're assembling an
aggregation of values from some some user-provided
construct. A tagged tuple has limited metaprogramming
value, but it still has some value in that regard. By
tagging types with names, you can develop interfaces
between the sender and the receiver of a tuple that allow
you to more effectively communicate. Rather than
communicating by type or index, you communicate by a name,
thus giving the sending code the freedom to pick and
choose where the element is in the tuple.
Reading that thread may give us a better understanding of Nicolas' point.
-regards,
Larry
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ntm10a%24c66%241%40blaine.gmane.org.
.
Author: Larry Evans <cppljevans@suddenlink.net>
Date: Wed, 12 Oct 2016 14:21:24 -0500
Raw View
On 10/12/2016 08:09 AM, TONGARI J wrote:
> On Wednesday, October 12, 2016 at 7:48:24 PM UTC+8, Johannes Schaub wrote:
>
> Hello all,
>
> Using type-tags to access tuple fields is a common technique to access
> fields by "name"
>
> struct position_tag : type<double> { };
> struct color_tag : type<QColor> { };
>
> my_tuple<field<position_tag, color_tag> m;
>
> QColor c1 = std::get<color_tag>(m);
> QColor c2 = std::get<QColor>(m);
> QColor c3 = std::get<1>(m);
>
> I was thinking about extending std::tuple with support for tags. This
> can be done (i believe) most straight forward with string template
> arguments, if we would have support for them in the future
>
> std::tuple<field<double, "position">, field<QColor, "color">>
> getStop();
>
> auto m = getStop();
> double pos = std::get<"position">(m);
>
> An alternative (but uglier) implementation would abuse unnamed struct
> definitions in template-arguments with the "type" baseclass of above
> to communicate the type
>
> std::tuple<struct : typed<double> { type position; },
> struct : typed<QColor> { type color; }> getStop();
>
> Here, "type" is declared in base-class "typed" as a type-alias for its
> template-parameter. When tuple sees a parameter has "typed<T>" as a
> base class, it inherits from it. Therefore you could write
>
> auto m = getStop();
> QColor c = m.color;
>
> std::get<N> would cast the unnamed-struct to "struct_type::type",
> requiring a standard-layout struct (can be tested-for with a
> type-trait). So the unnamed-struct cannot "escape" to the users of the
> tuple.
>
> What do you think about the two approaches? Are there existing papers
> about perhaps other techniques?
>
>
> I'm not aware of any existing proposal, but some experimental language
> features I'm developing will allow you to do this:
>
> |
> std::tuple<double.position,QColor.color>getStop();
> autom =getStop();
> doublepos =m.position;
> QColorc =m.color;
> |
>
> Let me know if you need more detail.
What about something similar for variant?
std::variant<double.position,QColor.color>
var_pos_color=std::tuple<double>(1.2);
then:
assert(var_pos_color.position == 1.2);
assert(var_pos_color.color == undefined);
assert(var_pos_color.which == position);
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bc065abb-acc5-ce9a-2b8a-2c114c2542a2%40suddenlink.net.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 12 Oct 2016 15:48:29 -0400
Raw View
On 2016-10-12 07:58, Micha=C5=82 Dominiak wrote:
> You can already somewhat do this:
>=20
> auto get_something() {
> struct ret_type { int some_value; };
> return ret_type{ 1 };
> }
That's horrid... it requires that the function definition be inline. The
idea behind P0222+P0224 (P0224 particularly) was specifically to avoid
this requirement.
--=20
Matthew
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ntm42b%24bc7%241%40blaine.gmane.org.
.
Author: Giovanni Piero Deretta <gpderetta@gmail.com>
Date: Thu, 13 Oct 2016 02:32:02 -0700 (PDT)
Raw View
------=_Part_210_1336208799.1476351122176
Content-Type: multipart/alternative;
boundary="----=_Part_211_654358069.1476351122176"
------=_Part_211_654358069.1476351122176
Content-Type: text/plain; charset=UTF-8
On Wednesday, October 12, 2016 at 12:48:24 PM UTC+1, Johannes Schaub wrote:
>
> Hello all,
>
> Using type-tags to access tuple fields is a common technique to access
> fields by "name"
>
Two things first: I believe that the current Range proposal has something
similar already. Second, I think you can declare, but not define, types in
template arguments.
Finally, I have been (very slowly) working on a proposal about this (which
ambitiously also covers the 'overload set', 'uniform calling convention',
'named arguments', and 'operator dot overloading' design space).
What I have currently is a macro based emulation [1] that allows this:
auto tuple = tup($(foo) = 10, $(bar) = 20);
assert(tuple.foo == 10);
assert(tuple.bar == 20);
A proper language implementation would use ' .<identifier>' instead of
'$(identifier)'
[1] https://github.com/gpderetta/libtask/blob/master/tests/q_test.cpp
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1eec31c2-4e39-4318-861c-eb917b75cbe8%40isocpp.org.
------=_Part_211_654358069.1476351122176
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, October 12, 2016 at 12:48:24 PM UTC+1, Johan=
nes Schaub wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hello all,
<br>
<br>Using type-tags to access tuple fields is a common technique to access
<br>fields by "name"
<br></blockquote><div><br>Two things first: I believe that the current Rang=
e proposal has something similar already. Second, I think you can declare, =
but not define, types in template arguments.<br><br>Finally, I have been (v=
ery slowly) working on a proposal about this (which ambitiously also covers=
the 'overload set', 'uniform calling convention', 'nam=
ed arguments', and 'operator dot overloading' design space).<br=
><br>What I have currently is a macro based emulation [1] that allows this:=
<br><br><span class=3D"pl-k">=C2=A0=C2=A0 auto</span> tuple =3D <span clas=
s=3D"pl-c1">tup</span>($(foo) =3D <span class=3D"pl-c1">10</span>, $(bar) =
=3D <span class=3D"pl-c1">20</span>);<br><span class=3D"pl-c1">=C2=A0=C2=A0=
assert</span>(tuple.<span class=3D"pl-smi">foo</span> =3D=3D <span class=
=3D"pl-c1">10</span>);
<br>=C2=A0=C2=A0 <span class=3D"pl-c1">assert</span>(tuple.<span class=3D"p=
l-smi">bar</span> =3D=3D <span class=3D"pl-c1">20</span>);<br><br><br>A pro=
per language implementation would use ' .<identifier>' instea=
d of '$(identifier)'<br><br>[1] https://github.com/gpderetta/libtas=
k/blob/master/tests/q_test.cpp</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1eec31c2-4e39-4318-861c-eb917b75cbe8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1eec31c2-4e39-4318-861c-eb917b75cbe8=
%40isocpp.org</a>.<br />
------=_Part_211_654358069.1476351122176--
------=_Part_210_1336208799.1476351122176--
.
Author: TONGARI J <tongari95@gmail.com>
Date: Thu, 13 Oct 2016 02:50:41 -0700 (PDT)
Raw View
------=_Part_651_1580961813.1476352241184
Content-Type: multipart/alternative;
boundary="----=_Part_652_1618195170.1476352241185"
------=_Part_652_1618195170.1476352241185
Content-Type: text/plain; charset=UTF-8
On Thursday, October 13, 2016 at 5:32:02 PM UTC+8, Giovanni Piero Deretta
wrote:
>
> On Wednesday, October 12, 2016 at 12:48:24 PM UTC+1, Johannes Schaub wrote:
>>
>> Hello all,
>>
>> Using type-tags to access tuple fields is a common technique to access
>> fields by "name"
>>
>
> Two things first: I believe that the current Range proposal has something
> similar already. Second, I think you can declare, but not define, types in
> template arguments.
>
> Finally, I have been (very slowly) working on a proposal about this (which
> ambitiously also covers the 'overload set', 'uniform calling convention',
> 'named arguments', and 'operator dot overloading' design space).
>
> What I have currently is a macro based emulation [1] that allows this:
>
> auto tuple = tup($(foo) = 10, $(bar) = 20);
> assert(tuple.foo == 10);
> assert(tuple.bar == 20);
>
>
> A proper language implementation would use ' .<identifier>' instead of
> '$(identifier)'
>
> [1] https://github.com/gpderetta/libtask/blob/master/tests/q_test.cpp
>
Seems we have some work overlapped ;)
With my experimental language features + template arg deduction from ctor
(C++17), this is possible:
std::tuple tup(.foo = 10, .bar = 20); // deduced to std::tuple<int.foo,
int.bar>
assert(tuple.foo == 10);
assert(tuple.bar == 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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5eeef837-6e0f-4544-b610-0474c6aaa02a%40isocpp.org.
------=_Part_652_1618195170.1476352241185
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, October 13, 2016 at 5:32:02 PM UTC+8, Giovann=
i Piero Deretta 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">On Wednesday, October 12, 2016 at 12:48:24 PM UTC+1, Johannes Scha=
ub wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex">Hello all,
<br>
<br>Using type-tags to access tuple fields is a common technique to access
<br>fields by "name"
<br></blockquote><div><br>Two things first: I believe that the current Rang=
e proposal has something similar already. Second, I think you can declare, =
but not define, types in template arguments.<br><br>Finally, I have been (v=
ery slowly) working on a proposal about this (which ambitiously also covers=
the 'overload set', 'uniform calling convention', 'nam=
ed arguments', and 'operator dot overloading' design space).<br=
><br>What I have currently is a macro based emulation [1] that allows this:=
<br><br><span>=C2=A0=C2=A0 auto</span> tuple =3D <span>tup</span>($(foo) =
=3D <span>10</span>, $(bar) =3D <span>20</span>);<br><span>=C2=A0=C2=A0 ass=
ert</span>(tuple.<span>foo</span> =3D=3D <span>10</span>);
<br>=C2=A0=C2=A0 <span>assert</span>(tuple.<span>bar</span> =3D=3D <span>20=
</span>);<br><br><br>A proper language implementation would use ' .<=
identifier>' instead of '$(identifier)'<br><br>[1] <a href=
=3D"https://github.com/gpderetta/libtask/blob/master/tests/q_test.cpp" targ=
et=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://www.=
google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fgpderetta%2Flibtask%2Fblob%2=
Fmaster%2Ftests%2Fq_test.cpp\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFUo-ga=
9aWQUMlbpfLq0WQ1IdA1Mw';return true;" onclick=3D"this.href=3D'https=
://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fgpderetta%2Flibtask%2=
Fblob%2Fmaster%2Ftests%2Fq_test.cpp\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjC=
NFUo-ga9aWQUMlbpfLq0WQ1IdA1Mw';return true;">https://github.com/gpderet=
ta/<wbr>libtask/blob/master/tests/q_<wbr>test.cpp</a></div></div></blockquo=
te><div><br></div><div>Seems we have some work overlapped ;)=C2=A0</div><di=
v>With my experimental language features + template arg deduction from ctor=
(C++17), this is possible:</div><div><div class=3D"prettyprint" style=3D"b=
ackground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bord=
er-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"=
prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">tuple tup</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(.</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">foo </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #066;" class=3D"styled-by-prettify">10</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">bar </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">20=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">// deduced to std::tuple<=
;int.foo, int.bar></span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">assert</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">tuple</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">foo </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
66;" class=3D"styled-by-prettify">10</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">assert</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">t=
uple</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">bar </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #066;" class=3D"styled-by-prettify">20</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">);</span></div></code></div><br></div></di=
v>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5eeef837-6e0f-4544-b610-0474c6aaa02a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5eeef837-6e0f-4544-b610-0474c6aaa02a=
%40isocpp.org</a>.<br />
------=_Part_652_1618195170.1476352241185--
------=_Part_651_1580961813.1476352241184--
.
Author: Giovanni Piero Deretta <gpderetta@gmail.com>
Date: Thu, 13 Oct 2016 02:55:40 -0700 (PDT)
Raw View
------=_Part_196_1844721492.1476352540794
Content-Type: multipart/alternative;
boundary="----=_Part_197_1002307076.1476352540795"
------=_Part_197_1002307076.1476352540795
Content-Type: text/plain; charset=UTF-8
On Thursday, October 13, 2016 at 10:50:41 AM UTC+1, TONGARI J wrote:
>
> On Thursday, October 13, 2016 at 5:32:02 PM UTC+8, Giovanni Piero Deretta
> wrote:
>>
>> On Wednesday, October 12, 2016 at 12:48:24 PM UTC+1, Johannes Schaub
>> wrote:
>>>
>>> Hello all,
>>>
>>> Using type-tags to access tuple fields is a common technique to access
>>> fields by "name"
>>>
>>
>> Two things first: I believe that the current Range proposal has something
>> similar already. Second, I think you can declare, but not define, types in
>> template arguments.
>>
>> Finally, I have been (very slowly) working on a proposal about this
>> (which ambitiously also covers the 'overload set', 'uniform calling
>> convention', 'named arguments', and 'operator dot overloading' design
>> space).
>>
>> What I have currently is a macro based emulation [1] that allows this:
>>
>> auto tuple = tup($(foo) = 10, $(bar) = 20);
>> assert(tuple.foo == 10);
>> assert(tuple.bar == 20);
>>
>>
>> A proper language implementation would use ' .<identifier>' instead of
>> '$(identifier)'
>>
>> [1] https://github.com/gpderetta/libtask/blob/master/tests/q_test.cpp
>>
>
> Seems we have some work overlapped ;)
> With my experimental language features + template arg deduction from ctor
> (C++17), this is possible:
> std::tuple tup(.foo = 10, .bar = 20); // deduced to std::tuple<int.foo,
> int.bar>
> assert(tuple.foo == 10);
> assert(tuple.bar == 20);
>
>
So it seems! That's exactly my end game.
Do you already have some draft proposal? I have been focusing on the
emulation implementation.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/903009b9-8585-406d-9c12-d0e437e62f10%40isocpp.org.
------=_Part_197_1002307076.1476352540795
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, October 13, 2016 at 10:50:41 AM UTC+1, TONGAR=
I J 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">On =
Thursday, October 13, 2016 at 5:32:02 PM UTC+8, Giovanni Piero Deretta wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Wednesday, Oc=
tober 12, 2016 at 12:48:24 PM UTC+1, Johannes Schaub wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex">Hello all,
<br>
<br>Using type-tags to access tuple fields is a common technique to access
<br>fields by "name"
<br></blockquote><div><br>Two things first: I believe that the current Rang=
e proposal has something similar already. Second, I think you can declare, =
but not define, types in template arguments.<br><br>Finally, I have been (v=
ery slowly) working on a proposal about this (which ambitiously also covers=
the 'overload set', 'uniform calling convention', 'nam=
ed arguments', and 'operator dot overloading' design space).<br=
><br>What I have currently is a macro based emulation [1] that allows this:=
<br><br><span>=C2=A0=C2=A0 auto</span> tuple =3D <span>tup</span>($(foo) =
=3D <span>10</span>, $(bar) =3D <span>20</span>);<br><span>=C2=A0=C2=A0 ass=
ert</span>(tuple.<span>foo</span> =3D=3D <span>10</span>);
<br>=C2=A0=C2=A0 <span>assert</span>(tuple.<span>bar</span> =3D=3D <span>20=
</span>);<br><br><br>A proper language implementation would use ' .<=
identifier>' instead of '$(identifier)'<br><br>[1] <a href=
=3D"https://github.com/gpderetta/libtask/blob/master/tests/q_test.cpp" rel=
=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'https://www=
..google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fgpderetta%2Flibtask%2Fblob%=
2Fmaster%2Ftests%2Fq_test.cpp\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFUo-g=
a9aWQUMlbpfLq0WQ1IdA1Mw';return true;" onclick=3D"this.href=3D'http=
s://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fgpderetta%2Flibtask%=
2Fblob%2Fmaster%2Ftests%2Fq_test.cpp\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQj=
CNFUo-ga9aWQUMlbpfLq0WQ1IdA1Mw';return true;">https://github.com/gpdere=
tta/<wbr>libtask/blob/master/tests/q_<wbr>test.cpp</a></div></div></blockqu=
ote><div><br></div><div>Seems we have some work overlapped ;)=C2=A0</div><d=
iv>With my experimental language features + template arg deduction from cto=
r (C++17), this is possible:</div><div><div style=3D"background-color:rgb(2=
50,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1=
px;word-wrap:break-word"><code><div><span style=3D"color:#000">std</span><s=
pan style=3D"color:#660">::</span><span style=3D"color:#000">tuple tup</spa=
n><span style=3D"color:#660">(.</span><span style=3D"color:#000">foo </span=
><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#066">10</span><span style=3D"color:#660">,</span><span =
style=3D"color:#000"> </span><span style=3D"color:#660">.</span><span style=
=3D"color:#000">bar </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> </span><span style=3D"color:#066">20</span><span style=3D"=
color:#660">);</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#800">// deduced to std::tuple<int.foo, int.bar></span><span style=
=3D"color:#000"><br></span><span style=3D"color:#008">assert</span><span st=
yle=3D"color:#660">(</span><span style=3D"color:#000">tuple</span><span sty=
le=3D"color:#660">.</span><span style=3D"color:#000">foo </span><span style=
=3D"color:#660">=3D=3D</span><span style=3D"color:#000"> </span><span style=
=3D"color:#066">10</span><span style=3D"color:#660">);</span><span style=3D=
"color:#000"><br></span><span style=3D"color:#008">assert</span><span style=
=3D"color:#660">(</span><span style=3D"color:#000">tuple</span><span style=
=3D"color:#660">.</span><span style=3D"color:#000">bar </span><span style=
=3D"color:#660">=3D=3D</span><span style=3D"color:#000"> </span><span style=
=3D"color:#066">20</span><span style=3D"color:#660">);</span></div></code><=
/div><br></div></div></blockquote><div><br>So it seems! That's exactly =
my end game. <br>Do you already have some draft proposal? I have been focus=
ing on the emulation implementation.<br><br>=C2=A0</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/903009b9-8585-406d-9c12-d0e437e62f10%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/903009b9-8585-406d-9c12-d0e437e62f10=
%40isocpp.org</a>.<br />
------=_Part_197_1002307076.1476352540795--
------=_Part_196_1844721492.1476352540794--
.
Author: TONGARI J <tongari95@gmail.com>
Date: Thu, 13 Oct 2016 03:04:46 -0700 (PDT)
Raw View
------=_Part_576_2039720699.1476353086827
Content-Type: multipart/alternative;
boundary="----=_Part_577_1576027397.1476353086827"
------=_Part_577_1576027397.1476353086827
Content-Type: text/plain; charset=UTF-8
On Thursday, October 13, 2016 at 5:55:41 PM UTC+8, Giovanni Piero Deretta
wrote:
>
> On Thursday, October 13, 2016 at 10:50:41 AM UTC+1, TONGARI J wrote:
>>
>> On Thursday, October 13, 2016 at 5:32:02 PM UTC+8, Giovanni Piero Deretta
>> wrote:
>>>
>>> On Wednesday, October 12, 2016 at 12:48:24 PM UTC+1, Johannes Schaub
>>> wrote:
>>>>
>>>> Hello all,
>>>>
>>>> Using type-tags to access tuple fields is a common technique to access
>>>> fields by "name"
>>>>
>>>
>>> Two things first: I believe that the current Range proposal has
>>> something similar already. Second, I think you can declare, but not define,
>>> types in template arguments.
>>>
>>> Finally, I have been (very slowly) working on a proposal about this
>>> (which ambitiously also covers the 'overload set', 'uniform calling
>>> convention', 'named arguments', and 'operator dot overloading' design
>>> space).
>>>
>>> What I have currently is a macro based emulation [1] that allows this:
>>>
>>> auto tuple = tup($(foo) = 10, $(bar) = 20);
>>> assert(tuple.foo == 10);
>>> assert(tuple.bar == 20);
>>>
>>>
>>> A proper language implementation would use ' .<identifier>' instead of
>>> '$(identifier)'
>>>
>>> [1] https://github.com/gpderetta/libtask/blob/master/tests/q_test.cpp
>>>
>>
>> Seems we have some work overlapped ;)
>> With my experimental language features + template arg deduction from ctor
>> (C++17), this is possible:
>> std::tuple tup(.foo = 10, .bar = 20); // deduced to std::tuple<int.foo,
>> int.bar>
>> assert(tuple.foo == 10);
>> assert(tuple.bar == 20);
>>
>>
> So it seems! That's exactly my end game.
> Do you already have some draft proposal? I have been focusing on the
> emulation implementation.
>
They're some extensions to my last uniform designator idea that I posted
months ago.
So no draft proposal yet, I only have a working implementation based on
Clang (still some ABI issues to solve).
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4ff0672d-9cb5-41d9-a990-3ea95fee1014%40isocpp.org.
------=_Part_577_1576027397.1476353086827
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, October 13, 2016 at 5:55:41 PM UTC+8, Giovann=
i Piero Deretta 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">On Thursday, October 13, 2016 at 10:50:41 AM UTC+1, TONGARI J wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thursday, Oct=
ober 13, 2016 at 5:32:02 PM UTC+8, Giovanni Piero Deretta 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">On Wednesday, October 12, 201=
6 at 12:48:24 PM UTC+1, Johannes Schaub wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex">Hello all,
<br>
<br>Using type-tags to access tuple fields is a common technique to access
<br>fields by "name"
<br></blockquote><div><br>Two things first: I believe that the current Rang=
e proposal has something similar already. Second, I think you can declare, =
but not define, types in template arguments.<br><br>Finally, I have been (v=
ery slowly) working on a proposal about this (which ambitiously also covers=
the 'overload set', 'uniform calling convention', 'nam=
ed arguments', and 'operator dot overloading' design space).<br=
><br>What I have currently is a macro based emulation [1] that allows this:=
<br><br><span>=C2=A0=C2=A0 auto</span> tuple =3D <span>tup</span>($(foo) =
=3D <span>10</span>, $(bar) =3D <span>20</span>);<br><span>=C2=A0=C2=A0 ass=
ert</span>(tuple.<span>foo</span> =3D=3D <span>10</span>);
<br>=C2=A0=C2=A0 <span>assert</span>(tuple.<span>bar</span> =3D=3D <span>20=
</span>);<br><br><br>A proper language implementation would use ' .<=
identifier>' instead of '$(identifier)'<br><br>[1] <a href=
=3D"https://github.com/gpderetta/libtask/blob/master/tests/q_test.cpp" rel=
=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'https://www=
..google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fgpderetta%2Flibtask%2Fblob%=
2Fmaster%2Ftests%2Fq_test.cpp\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFUo-g=
a9aWQUMlbpfLq0WQ1IdA1Mw';return true;" onclick=3D"this.href=3D'http=
s://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fgpderetta%2Flibtask%=
2Fblob%2Fmaster%2Ftests%2Fq_test.cpp\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQj=
CNFUo-ga9aWQUMlbpfLq0WQ1IdA1Mw';return true;">https://github.com/gpdere=
tta/<wbr>libtask/blob/master/tests/q_<wbr>test.cpp</a></div></div></blockqu=
ote><div><br></div><div>Seems we have some work overlapped ;)=C2=A0</div><d=
iv>With my experimental language features + template arg deduction from cto=
r (C++17), this is possible:</div><div><div style=3D"background-color:rgb(2=
50,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1=
px;word-wrap:break-word"><code><div><span style=3D"color:#000">std</span><s=
pan style=3D"color:#660">::</span><span style=3D"color:#000">tuple tup</spa=
n><span style=3D"color:#660">(.</span><span style=3D"color:#000">foo </span=
><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#066">10</span><span style=3D"color:#660">,</span><span =
style=3D"color:#000"> </span><span style=3D"color:#660">.</span><span style=
=3D"color:#000">bar </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> </span><span style=3D"color:#066">20</span><span style=3D"=
color:#660">);</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#800">// deduced to std::tuple<int.foo, int.bar></span><span style=
=3D"color:#000"><br></span><span style=3D"color:#008">assert</span><span st=
yle=3D"color:#660">(</span><span style=3D"color:#000">tuple</span><span sty=
le=3D"color:#660">.</span><span style=3D"color:#000">foo </span><span style=
=3D"color:#660">=3D=3D</span><span style=3D"color:#000"> </span><span style=
=3D"color:#066">10</span><span style=3D"color:#660">);</span><span style=3D=
"color:#000"><br></span><span style=3D"color:#008">assert</span><span style=
=3D"color:#660">(</span><span style=3D"color:#000">tuple</span><span style=
=3D"color:#660">.</span><span style=3D"color:#000">bar </span><span style=
=3D"color:#660">=3D=3D</span><span style=3D"color:#000"> </span><span style=
=3D"color:#066">20</span><span style=3D"color:#660">);</span></div></code><=
/div><br></div></div></blockquote><div><br>So it seems! That's exactly =
my end game. <br>Do you already have some draft proposal? I have been focus=
ing on the emulation implementation.<br></div></div></blockquote><div><br><=
/div><div>They're some extensions to my last uniform designator idea th=
at I posted months ago.</div><div>So no draft proposal yet, I only have a w=
orking implementation based on Clang (still some ABI issues to solve).</div=
></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4ff0672d-9cb5-41d9-a990-3ea95fee1014%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4ff0672d-9cb5-41d9-a990-3ea95fee1014=
%40isocpp.org</a>.<br />
------=_Part_577_1576027397.1476353086827--
------=_Part_576_2039720699.1476353086827--
.
Author: Giovanni Piero Deretta <gpderetta@gmail.com>
Date: Thu, 13 Oct 2016 03:50:29 -0700 (PDT)
Raw View
------=_Part_230_877334070.1476355830020
Content-Type: multipart/alternative;
boundary="----=_Part_231_1073686864.1476355830020"
------=_Part_231_1073686864.1476355830020
Content-Type: text/plain; charset=UTF-8
On Thursday, October 13, 2016 at 11:04:47 AM UTC+1, TONGARI J wrote:
>
> On Thursday, October 13, 2016 at 5:55:41 PM UTC+8, Giovanni Piero Deretta
> wrote:
>>
>> On Thursday, October 13, 2016 at 10:50:41 AM UTC+1, TONGARI J wrote:
>>>
>>>
>>> With my experimental language features + template arg deduction from
>>> ctor (C++17), this is possible:
>>> std::tuple tup(.foo = 10, .bar = 20); // deduced to std::tuple<int.foo,
>>> int.bar>
>>> assert(tuple.foo == 10);
>>> assert(tuple.bar == 20);
>>>
>>>
>> So it seems! That's exactly my end game.
>> Do you already have some draft proposal? I have been focusing on the
>> emulation implementation.
>>
>
> They're some extensions to my last uniform designator idea that I posted
> months ago.
> So no draft proposal yet, I only have a working implementation based on
> Clang (still some ABI issues to solve).
>
I had completely forgotten about that proposal (even though I had commented
on it saying I liked it!). I ended up reinventing the idea, (even the .
based opt-in for named parameters); possibly I was influenced
subconsciously :).
In my design, an '.<identifier>' expression by itself is a literal for
some std::identifier<I> (where I is unspecified and there is 1:1 mapping
from I to 'identifier'). std::identifier would overload operator=(T) to
return an std::assignment_expression<I, T>.
std::as_field(std::assignment_expression<I,T>) returns an unspecified
structure with a single field named 'identifier; of type T. Similarly,
std::identifier<I>::operator(T x, Rest... rest) would return the result of
the first valid of these: x.<identifier>, x.<identifier>(rest...),
<identifier>(x, rest...), does_not_understand(std::identifier<I>, x, rest);
constexpr identifier<I>::name() would return a string_view over
"<identifier>".
These can all be implemented in C++14 (with the help of the preprocessor),
and by themselves already allow for a lot of functionality.
-- 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/330ab8be-0fce-4e55-8e34-925a81fc61be%40isocpp.org.
------=_Part_231_1073686864.1476355830020
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, October 13, 2016 at 11:04:47 AM UTC+1, TONGAR=
I J 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">On =
Thursday, October 13, 2016 at 5:55:41 PM UTC+8, Giovanni Piero Deretta wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thursday, Oct=
ober 13, 2016 at 10:50:41 AM UTC+1, TONGARI J wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><br><div>With my experimental language fe=
atures + template arg deduction from ctor (C++17), this is possible:</div><=
div><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,18=
7,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><div=
><span style=3D"color:#000">std</span><span style=3D"color:#660">::</span><=
span style=3D"color:#000">tuple tup</span><span style=3D"color:#660">(.</sp=
an><span style=3D"color:#000">foo </span><span style=3D"color:#660">=3D</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#066">10</span><=
span style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span =
style=3D"color:#660">.</span><span style=3D"color:#000">bar </span><span st=
yle=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=
=3D"color:#066">20</span><span style=3D"color:#660">);</span><span style=3D=
"color:#000"> </span><span style=3D"color:#800">// deduced to std::tuple<=
;int.foo, int.bar></span><span style=3D"color:#000"><br></span><span sty=
le=3D"color:#008">assert</span><span style=3D"color:#660">(</span><span sty=
le=3D"color:#000">tuple</span><span style=3D"color:#660">.</span><span styl=
e=3D"color:#000">foo </span><span style=3D"color:#660">=3D=3D</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#066">10</span><span style=
=3D"color:#660">);</span><span style=3D"color:#000"><br></span><span style=
=3D"color:#008">assert</span><span style=3D"color:#660">(</span><span style=
=3D"color:#000">tuple</span><span style=3D"color:#660">.</span><span style=
=3D"color:#000">bar </span><span style=3D"color:#660">=3D=3D</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#066">20</span><span style=
=3D"color:#660">);</span></div></code></div><br></div></div></blockquote><d=
iv><br>So it seems! That's exactly my end game. <br>Do you already have=
some draft proposal? I have been focusing on the emulation implementation.=
<br></div></div></blockquote><div><br></div><div>They're some extension=
s to my last uniform designator idea that I posted months ago.</div><div>So=
no draft proposal yet, I only have a working implementation based on Clang=
(still some ABI issues to solve).</div></div></blockquote><div><br>I had c=
ompletely forgotten about that proposal (even though I had commented on it =
saying I liked it!). I ended up reinventing the idea, (even the . based opt=
-in for named parameters); possibly I was influenced subconsciously :).<br>=
<br>In my design,=C2=A0 an '.<identifier>' expression by itse=
lf is a literal for some std::identifier<I> (where I is unspecified a=
nd there is 1:1 mapping from I to 'identifier'). std::identifier wo=
uld overload operator=3D(T) to return an std::assignment_expression<I, T=
>. std::as_field(std::assignment_expression<I,T>) returns an unspe=
cified structure with a single field named 'identifier; of type T. Simi=
larly, std::identifier<I>::operator(T x, Rest... rest) would return t=
he result of the first valid of these: x.<identifier>, x.<identifi=
er>(rest...), <identifier>(x, rest...), does_not_understand(std::i=
dentifier<I>, x, rest); constexpr identifier<I>::name() would r=
eturn a string_view over "<identifier>".<br><br>These can a=
ll be implemented in C++14 (with the help of the preprocessor), and by them=
selves already allow for a lot of functionality. <br><br>-- gpd<br><br><br>=
=C2=A0</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/330ab8be-0fce-4e55-8e34-925a81fc61be%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/330ab8be-0fce-4e55-8e34-925a81fc61be=
%40isocpp.org</a>.<br />
------=_Part_231_1073686864.1476355830020--
------=_Part_230_877334070.1476355830020--
.
Author: TONGARI J <tongari95@gmail.com>
Date: Thu, 13 Oct 2016 05:21:31 -0700 (PDT)
Raw View
------=_Part_735_24122487.1476361291234
Content-Type: multipart/alternative;
boundary="----=_Part_736_1115471485.1476361291234"
------=_Part_736_1115471485.1476361291234
Content-Type: text/plain; charset=UTF-8
On Thursday, October 13, 2016 at 6:50:30 PM UTC+8, Giovanni Piero Deretta
wrote:
>
> On Thursday, October 13, 2016 at 11:04:47 AM UTC+1, TONGARI J wrote:
>>
>> On Thursday, October 13, 2016 at 5:55:41 PM UTC+8, Giovanni Piero Deretta
>> wrote:
>>>
>>> On Thursday, October 13, 2016 at 10:50:41 AM UTC+1, TONGARI J wrote:
>>>>
>>>>
>>>> With my experimental language features + template arg deduction from
>>>> ctor (C++17), this is possible:
>>>> std::tuple tup(.foo = 10, .bar = 20); // deduced to
>>>> std::tuple<int.foo, int.bar>
>>>> assert(tuple.foo == 10);
>>>> assert(tuple.bar == 20);
>>>>
>>>>
>>> So it seems! That's exactly my end game.
>>> Do you already have some draft proposal? I have been focusing on the
>>> emulation implementation.
>>>
>>
>> They're some extensions to my last uniform designator idea that I posted
>> months ago.
>> So no draft proposal yet, I only have a working implementation based on
>> Clang (still some ABI issues to solve).
>>
>
> I had completely forgotten about that proposal (even though I had
> commented on it saying I liked it!). I ended up reinventing the idea, (even
> the . based opt-in for named parameters); possibly I was influenced
> subconsciously :).
>
> In my design, an '.<identifier>' expression by itself is a literal for
> some std::identifier<I> (where I is unspecified and there is 1:1 mapping
> from I to 'identifier'). std::identifier would overload operator=(T) to
> return an std::assignment_expression<I, T>.
> std::as_field(std::assignment_expression<I,T>) returns an unspecified
> structure with a single field named 'identifier; of type T. Similarly,
> std::identifier<I>::operator(T x, Rest... rest) would return the result of
> the first valid of these: x.<identifier>, x.<identifier>(rest...),
> <identifier>(x, rest...), does_not_understand(std::identifier<I>, x, rest);
> constexpr identifier<I>::name() would return a string_view over
> "<identifier>".
>
> These can all be implemented in C++14 (with the help of the preprocessor),
> and by themselves already allow for a lot of functionality.
>
It's quite cool as a macro approach.
The unspecified `I` in your idea maps directly to the "template declname
parameter" in my design.
In my design (so is in C99), '.<identifier> = <expr>' is not a real
expression, and '.<identifier>' itself does not form an expression as well.
While you can still implement the `identifier<I>` as you described, but I
think it becomes unnecessary.
The ability to retrieve the name string is worth considering, could be a
variable template that connects to some compiler intrinsic.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cb3a913d-7227-49fa-af5a-03b89690f822%40isocpp.org.
------=_Part_736_1115471485.1476361291234
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, October 13, 2016 at 6:50:30 PM UTC+8, Giovann=
i Piero Deretta 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">On Thursday, October 13, 2016 at 11:04:47 AM UTC+1, TONGARI J wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thursday, Oct=
ober 13, 2016 at 5:55:41 PM UTC+8, Giovanni Piero Deretta 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">On Thursday, October 13, 2016=
at 10:50:41 AM UTC+1, TONGARI J wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><br><div>With my experimental language features + temp=
late arg deduction from ctor (C++17), this is possible:</div><div><div styl=
e=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border=
-style:solid;border-width:1px;word-wrap:break-word"><code><div><span style=
=3D"color:#000">std</span><span style=3D"color:#660">::</span><span style=
=3D"color:#000">tuple tup</span><span style=3D"color:#660">(.</span><span s=
tyle=3D"color:#000">foo </span><span style=3D"color:#660">=3D</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#066">10</span><span style=
=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">.</span><span style=3D"color:#000">bar </span><span style=3D"col=
or:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:=
#066">20</span><span style=3D"color:#660">);</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#800">// deduced to std::tuple<int.foo, =
int.bar></span><span style=3D"color:#000"><br></span><span style=3D"colo=
r:#008">assert</span><span style=3D"color:#660">(</span><span style=3D"colo=
r:#000">tuple</span><span style=3D"color:#660">.</span><span style=3D"color=
:#000">foo </span><span style=3D"color:#660">=3D=3D</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#066">10</span><span style=3D"color:=
#660">);</span><span style=3D"color:#000"><br></span><span style=3D"color:#=
008">assert</span><span style=3D"color:#660">(</span><span style=3D"color:#=
000">tuple</span><span style=3D"color:#660">.</span><span style=3D"color:#0=
00">bar </span><span style=3D"color:#660">=3D=3D</span><span style=3D"color=
:#000"> </span><span style=3D"color:#066">20</span><span style=3D"color:#66=
0">);</span></div></code></div><br></div></div></blockquote><div><br>So it =
seems! That's exactly my end game. <br>Do you already have some draft p=
roposal? I have been focusing on the emulation implementation.<br></div></d=
iv></blockquote><div><br></div><div>They're some extensions to my last =
uniform designator idea that I posted months ago.</div><div>So no draft pro=
posal yet, I only have a working implementation based on Clang (still some =
ABI issues to solve).</div></div></blockquote><div><br>I had completely for=
gotten about that proposal (even though I had commented on it saying I like=
d it!). I ended up reinventing the idea, (even the . based opt-in for named=
parameters); possibly I was influenced subconsciously :).<br><br>In my des=
ign,=C2=A0 an '.<identifier>' expression by itself is a liter=
al for some std::identifier<I> (where I is unspecified and there is 1=
:1 mapping from I to 'identifier'). std::identifier would overload =
operator=3D(T) to return an std::assignment_expression<I, T>. std::as=
_field(std::assignment_<wbr>expression<I,T>) returns an unspecified s=
tructure with a single field named 'identifier; of type T. Similarly, s=
td::identifier<I>::operator(T x, Rest... rest) would return the resul=
t of the first valid of these: x.<identifier>, x.<identifier>(r=
est...), <identifier>(x, rest...), does_not_understand(std::<wbr>iden=
tifier<I>, x, rest); constexpr identifier<I>::name() would retu=
rn a string_view over "<identifier>".<br><br>These can all =
be implemented in C++14 (with the help of the preprocessor), and by themsel=
ves already allow for a lot of functionality.<br></div></div></blockquote><=
div><br></div><div>It's quite cool as a macro approach.</div><div><br><=
/div><div>The unspecified `I` in your idea maps directly to the "templ=
ate declname parameter" in my design.</div><div><br></div><div>In my d=
esign (so is in C99), '.<identifier> =3D <expr>' is not=
a real expression, and '.<identifier>' itself does not form =
an expression as well.</div><div>While you can still implement the `identif=
ier<I>` as you described, but I think it becomes unnecessary.</div><d=
iv><br></div><div>The ability to retrieve the name string is worth consider=
ing, could be a variable template that connects to some compiler intrinsic.=
</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cb3a913d-7227-49fa-af5a-03b89690f822%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cb3a913d-7227-49fa-af5a-03b89690f822=
%40isocpp.org</a>.<br />
------=_Part_736_1115471485.1476361291234--
------=_Part_735_24122487.1476361291234--
.
Author: Larry Evans <cppljevans@suddenlink.net>
Date: Thu, 13 Oct 2016 11:19:59 -0500
Raw View
On 10/13/2016 07:12 AM, John Yates wrote:
> |
>
> std::tuple<double.position,QColor.color>getStop();
> autom =3DgetStop();
> doublepos =3Dm.position;
> QColorc =3Dm.color;
> |
>
>
> =E2=80=8BJust a wild stab off the top of my head:
>
> enum class MoreReadableTags { dimension, label, success };
> std::tuple [
> MoreReadableTags
> ] <unsigned, std::string, bool> =E2=80=8B
>
I like this idea; however, that's probably because I tried
something like it here:
https://github.com/cppljevans/variadic_templates/blob/master/boost/composit=
e_storage/pack/container_all_of_aligned.hpp#L25
The Index template argument corresponds to your
MoreReadableTags argument.
However, what would really be nice is some map from
enum->type. Then, such a map could be used both for
tagged tuples as well as tagged variants. IOW,
tuple<enum2type> a_tuple;
variant<enum2type> a_variant;
Thoughts?
-regards,
Larry
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ntoc79%24v0m%241%40blaine.gmane.org.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 13 Oct 2016 22:54:56 +0200
Raw View
This is a multi-part message in MIME format.
--------------62EC603B642D27C905A1CD86
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 12/10/2016 =C3=A0 13:48, 'Johannes Schaub' via ISO C++ Standard - Future=
=20
Proposals a =C3=A9crit :
> Hello all,
>
> Using type-tags to access tuple fields is a common technique to access
> fields by "name"
>
> struct position_tag : type<double> { };
> struct color_tag : type<QColor> { };
>
> my_tuple<field<position_tag, color_tag> m;
>
> QColor c1 =3D std::get<color_tag>(m);
> QColor c2 =3D std::get<QColor>(m);
> QColor c3 =3D std::get<1>(m);
>
> I was thinking about extending std::tuple with support for tags. This
> can be done (i believe) most straight forward with string template
> arguments, if we would have support for them in the future
>
> std::tuple<field<double, "position">, field<QColor, "color">> getSto=
p();
>
> auto m =3D getStop();
> double pos =3D std::get<"position">(m);
>
> An alternative (but uglier) implementation would abuse unnamed struct
> definitions in template-arguments with the "type" baseclass of above
> to communicate the type
>
> std::tuple<struct : typed<double> { type position; },
> struct : typed<QColor> { type color; }> getStop();
>
> Here, "type" is declared in base-class "typed" as a type-alias for its
> template-parameter. When tuple sees a parameter has "typed<T>" as a
> base class, it inherits from it. Therefore you could write
>
> auto m =3D getStop();
> QColor c =3D m.color;
>
> std::get<N> would cast the unnamed-struct to "struct_type::type",
> requiring a standard-layout struct (can be tested-for with a
> type-trait). So the unnamed-struct cannot "escape" to the users of the
> tuple.
>
> What do you think about the two approaches? Are there existing papers
> about perhaps other techniques?
>
Range TS has a tagged tuple.
Vicente
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9869e601-a42c-9f63-41e1-e3e7bf131a4a%40wanadoo.f=
r.
--------------62EC603B642D27C905A1CD86
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 12/10/2016 =C3=A0 13:48, 'Johannes
Schaub' via ISO C++ Standard - Future Proposals a =C3=A9crit=C2=A0:<b=
r>
</div>
<blockquote
cite=3D"mid:CANu6V4VcQQxjb0LvEVjAeNkZ892Gn32cirgVwfjYuAJkkR5EPA@mail.gmail.=
com"
type=3D"cite">
<pre wrap=3D"">Hello all,
Using type-tags to access tuple fields is a common technique to access
fields by "name"
struct position_tag : type<double> { };
struct color_tag : type<QColor> { };
my_tuple<field<position_tag, color_tag> m;
QColor c1 =3D std::get<color_tag>(m);
QColor c2 =3D std::get<QColor>(m);
QColor c3 =3D std::get<1>(m);
I was thinking about extending std::tuple with support for tags. This
can be done (i believe) most straight forward with string template
arguments, if we would have support for them in the future
std::tuple<field<double, "position">, field<QColor, "color"=
>> getStop();
auto m =3D getStop();
double pos =3D std::get<"position">(m);
An alternative (but uglier) implementation would abuse unnamed struct
definitions in template-arguments with the "type" baseclass of above
to communicate the type
std::tuple<struct : typed<double> { type position; },
struct : typed<QColor> { type color; }> getSt=
op();
Here, "type" is declared in base-class "typed" as a type-alias for its
template-parameter. When tuple sees a parameter has "typed<T>" as a
base class, it inherits from it. Therefore you could write
auto m =3D getStop();
QColor c =3D m.color;
std::get<N> would cast the unnamed-struct to "struct_type::type",
requiring a standard-layout struct (can be tested-for with a
type-trait). So the unnamed-struct cannot "escape" to the users of the
tuple.
What do you think about the two approaches? Are there existing papers
about perhaps other techniques?
</pre>
</blockquote>
<p><font size=3D"+1">Range TS has a tagged tuple</font>.</p>
<p><br>
</p>
<p>Vicente<br>
</p>
</body>
</html>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9869e601-a42c-9f63-41e1-e3e7bf131a4a%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9869e601-a42c-9f63-41e1-e3e7bf131a4a=
%40wanadoo.fr</a>.<br />
--------------62EC603B642D27C905A1CD86--
.