220 28814 <9869e601-a42c-9f63-41e1-e3e7bf131a4a@wanadoo.fr> article Path: news.gmane.org!.POSTED!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Ideas for extending std::tuple with field-name based access Date: Thu, 13 Oct 2016 22:54:56 +0200 Lines: 162 Approved: news@gmane.org Message-ID: <9869e601-a42c-9f63-41e1-e3e7bf131a4a@wanadoo.fr> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------62EC603B642D27C905A1CD86" X-Trace: blaine.gmane.org 1476392122 32621 195.159.176.226 (13 Oct 2016 20:55:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 13 Oct 2016 20:55:22 +0000 (UTC) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBBIXJ767QKGQEE5TOQKI@isocpp.org Thu Oct 13 22:55:18 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f71.google.com ([209.85.215.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bun1k-0005M1-Pm for gclcip-std-proposals@m.gmane.org; Thu, 13 Oct 2016 22:54:56 +0200 Original-Received: by mail-lf0-f71.google.com with SMTP id b75sf56522791lfg.3 for ; Thu, 13 Oct 2016 13:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=s0QlnG5hZW84iaM6YPZ+2ZnfGiiS0v3Tss3sdA+C45o=; b=Nkr3grUC2TesI9+R1XXw+PdLc5ku79xNauqmeu0MWpJBjRqDwdCZ8Q3saw9VHawv8V wNUx01Yw1XNG0GZI6Nxa3hBdEwqSFQ85GuFLey8Cj6cu0M2F851aNvKvbfdgffb5+my5 Y+w7s9AKqc/5y1RshfJF08v1xVPfM01/pTqyzO6uLcwUCYtmjcChUTbRVk3KHZBRqPpk Sy6gZmDPwLH2alh3OzHYKjJanLHe+zpZ/y3Qz2rhkUrZXuUF40JDF6GuqkYHOyj53mtG ZFoxBZVsk2A0zfBLYMOfiwb2OB2kwJa7giI5XmUVEtQRf1wfgp3wNry2B4tJWCByBZ92 7L2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=s0QlnG5hZW84iaM6YPZ+2ZnfGiiS0v3Tss3sdA+C45o=; b=l+e8sqK64DsgdpoO/b897JCxSxsimTLZdKCR8rwdcvk4lI0dnU9gSHzhc86afJ+rz1 cR317r3a2mhNSn61Otrw7ART9gQUB3CNihoOQN3cJIFfenZYmZ2XDYMc0Nt4+k/0eDA7 cED7QcUC1S/dQe43rQL2FMp5KJYbmR6DrrsxU9vHzn0WoX3wFYrSnNhpx3vF5vyg+jpr BttlDPlvxHeInD/yW22IK6wTnXTy4ZxHo9lC87t37x//LADNFw0M0J5IQVIa9NjY2jJ0 SINaoWfCg109ULyG1wGDAX32z5HUywH3fEJ7IhhusHeqbunKK7spbES0XiHZwokHFcFB mZLw== X-Gm-Message-State: AA6/9Rm6dyLpmllNcmqhtuFn/77BJlR5PbBKhvX2s2jnl2nhlrmYMJOwq5/u6ekF00Xr+Q== X-Received: by 10.28.152.137 with SMTP id a131mr326149wme.16.1476392099155; Thu, 13 Oct 2016 13:54:59 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.21.75 with SMTP id l72ls1130241lfi.31.gmail; Thu, 13 Oct 2016 13:54:58 -0700 (PDT) X-Received: by 10.28.54.97 with SMTP id d94mr3359233wma.36.1476392098018; Thu, 13 Oct 2016 13:54:58 -0700 (PDT) Original-Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr. [80.12.242.126]) by mx.google.com with ESMTPS id wx6si3942237wjb.37.2016.10.13.13.54.57 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 13 Oct 2016 13:54:57 -0700 (PDT) Received-SPF: neutral (google.com: 80.12.242.126 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.126; Original-Received: from pc29.home ([2.11.66.154]) by mwinf5d51 with ME id v8ux1t00L3KhaHe038uxo9; Thu, 13 Oct 2016 22:54:57 +0200 X-ME-Helo: pc29.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Thu, 13 Oct 2016 22:54:57 +0200 X-ME-IP: 2.11.66.154 In-Reply-To: X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.126 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr 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:28814 Archived-At: 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 { }; > struct color_tag : type { }; > > my_tuple m; > > QColor c1 =3D std::get(m); > QColor c2 =3D std::get(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> 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 { 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 =3D getStop(); > QColor c =3D 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? > 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
Le 12/10/2016 =C3=A0 13:48, 'Johannes Schaub' via ISO C++ Standard - Future Proposals a =C3=A9crit=C2=A0: 
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?

Range TS has a tagged tuple.


Vicente

--
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/9869e601-a42c-9f63-41e1-e3e7bf131a4a= %40wanadoo.fr.
--------------62EC603B642D27C905A1CD86-- .