220 28716 <19048c95-770c-4413-b5ff-aa405c389621@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: TONGARI J Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Ideas for extending std::tuple with field-name based access Date: Wed, 12 Oct 2016 06:09:19 -0700 (PDT) Lines: 193 Approved: news@gmane.org Message-ID: <19048c95-770c-4413-b5ff-aa405c389621@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_8590_506358446.1476277760037" X-Trace: blaine.gmane.org 1476277799 10850 195.159.176.226 (12 Oct 2016 13:09:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 12 Oct 2016 13:09:59 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCC3NA775MLBBAHM7C7QKGQEKDZKSPQ@isocpp.org Wed Oct 12 15:09:45 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f197.google.com ([209.85.161.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buJHh-0007xw-Gw for gclcip-std-proposals@m.gmane.org; Wed, 12 Oct 2016 15:09:25 +0200 Original-Received: by mail-yw0-f197.google.com with SMTP id u124sf85577315ywg.3 for ; Wed, 12 Oct 2016 06:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=Hi00WHlNyewsJ4MxDf+FpnmjAXV/GMdEbDvd+dBtHlU=; b=gcXuLl/IRbZq1804f8CE+Q1hJTSIr3GOeYE6JKueyhY6sIbJWv+WHy918X6LH8zhlt bkEdRiRUncptcy5PR4FsHFTT8bC24gtt5cOLyqUb4k+qafFtlN1ycemqVwv63hN7kBXX AHszgWN4fPtsRA7kl/TVGyU6lG8BxJSrIpzCu0AQC0kDIE2DW5MIW1v47ejhqxOfUwER Wxq3dO22IGjydatPaVaVUMR9ed1lKM1y6GHePxe2vP/ms1n4Mb6c/1o6Ta2ezhsZtAtz 7/iV4UByaCDFLYtrR0Pc8HJ3IXH3o7kz4ZwmRzFAgWKsdr6Bem8gxmfhKlR76PruAanB H1Og== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=Hi00WHlNyewsJ4MxDf+FpnmjAXV/GMdEbDvd+dBtHlU=; b=shZ/m5upOxEbmaxqe4Xi86MFGqJAnNjhbyJ50ro9rXADcRcvEFZnZjOd0MM6q9KjP6 3FjdJY8hAvQDH+8tmY9BuwXpqPiMYIkMoOUAe0i5ZhrXPiwnZB7eHb3ffYcfxJCfrV/W P7Y5xiyAkro3iZIVak8XEnMjlB70FOC39/O2lKYmcrqArjUWBDCm2JdfTWUiwuKBkGZd 0ElsMterd8ZItK1Bi2ugBIdBRRxFYv0VcozZn7OxS/1hvJTBNLUMAPZ/TIMKyXRj027i cPMBEo/STisQ1L7Fk8KTlATGHFcx5jGwKnt9mE4b3vbX7Rkjy9LwWc0aBSyZ6f7DtuIx VbhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=Hi00WHlNyewsJ4MxDf+FpnmjAXV/GMdEbDvd+dBtHlU=; b=AXtcIfOtaKgO4V+wmwVtCDghrrjAR2FBwu2/SWFkPs2LfVSH/QVEkhVnclTl4SzMhi xzjTLYZnNmj7WCWJVFoDSxCs+C1Lx+MIjT+1qrzvwEOrHlSevjqdFPlfCauYwwS3aqYf 7da8LvPOccUXi/Utg7WLtGGHAB1g17ZqmzhisGHjYvm/ImazGBk+jEVydDzh7EltLWxo +T13ZBQ2DotNJ4RehDgh+F5Z0uHGO0RyOpPz0c6zfxcc5VCRpoQGPzYyAk/HO8f/a3EA 0CLoDV+jnlYwLpThLjf9wm0z3bB3W2Q0og0MYrL2XO+ptbYMDXGweSY+9HYiSkt8xCnI /saw== X-Gm-Message-State: AA6/9RnQjrMZVawuoEzrrv/ZnrfeBsJ0W2ERUyCDFIAaPOXCLXrF+/pNvbOaETUvdElVDQ== X-Received: by 10.129.110.137 with SMTP id j131mr231247ywc.171.1476277767420; Wed, 12 Oct 2016 06:09:27 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.227.79 with SMTP id d76ls2552204ith.4.canary; Wed, 12 Oct 2016 06:09:20 -0700 (PDT) X-Received: by 10.36.137.67 with SMTP id s64mr124808itd.1.1476277760702; Wed, 12 Oct 2016 06:09:20 -0700 (PDT) In-Reply-To: X-Original-Sender: tongari95@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:28716 Archived-At: ------=_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 { }; > struct color_tag : type { }; > > my_tuple m; > > QColor c1 = std::get(m); > QColor c2 = std::get(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> > 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 { type position; }, > struct : typed { 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" as a > base class, it inherits from it. Therefore you could write > > auto m = getStop(); > QColor c = m.color; > > std::get 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 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
On Wednesday, October 12, 2016 at 7:48:24 PM UTC+8, Johann= es Schaub wrote:
Hello all,

Using type-tags to access tuple fields is a common technique to access
fields by "name"

=C2=A0 =C2=A0 struct position_tag : type<double> { };
=C2=A0 =C2=A0 struct color_tag : type<QColor> { };

=C2=A0 =C2=A0 my_tuple<field<position_tag, color_tag> m;

=C2=A0 =C2=A0 QColor c1 =3D std::get<color_tag>(m);
=C2=A0 =C2=A0 QColor c2 =3D std::get<QColor>(m);
=C2=A0 =C2=A0 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

=C2=A0 =C2=A0 std::tuple<field<double, "position">, = field<QColor, "color">> getStop();

=C2=A0 =C2=A0 auto m =3D getStop();
=C2=A0 =C2=A0 double pos =3D std::get<"position">(m);

An alternative (but uglier) implementation would abuse unnamed struct
definitions in template-arguments with the "type" baseclass o= f above
to communicate the type

=C2=A0 =C2=A0 std::tuple<struct : typed<double> { type positio= n; },
=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();

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

=C2=A0 =C2=A0 auto m =3D getStop();
=C2=A0 =C2=A0 QColor c =3D m.color;

std::get<N> would cast the unnamed-struct to "struct_type::t= ype",
requiring a standard-layout struct (can be tested-for with a
type-trait). So the unnamed-struct cannot "escape" to the use= rs 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 prop= osal, but some experimental language features I'm developing will allow= you to do this:

std::tuple<d= ouble.position, QColor.color> getStop();
auto m =3D getStop();
double = pos =3D m.position;
QColor c =3D m.= color;
=

Let me know if you need more detail.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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-- ------=_Part_8590_506358446.1476277760037-- .