220 28791 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: Thu, 13 Oct 2016 05:21:31 -0700 (PDT) Lines: 169 Approved: news@gmane.org Message-ID: References: <1eec31c2-4e39-4318-861c-eb917b75cbe8@isocpp.org> <5eeef837-6e0f-4544-b610-0474c6aaa02a@isocpp.org> <903009b9-8585-406d-9c12-d0e437e62f10@isocpp.org> <4ff0672d-9cb5-41d9-a990-3ea95fee1014@isocpp.org> <330ab8be-0fce-4e55-8e34-925a81fc61be@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_735_24122487.1476361291234" X-Trace: blaine.gmane.org 1476361318 14293 195.159.176.226 (13 Oct 2016 12:21:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 13 Oct 2016 12:21:58 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCC3NA775MLBBTHY7W7QKGQE3V57ZOA@isocpp.org Thu Oct 13 14:21:53 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f70.google.com ([209.85.214.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buf0v-0000fd-EQ for gclcip-std-proposals@m.gmane.org; Thu, 13 Oct 2016 14:21:33 +0200 Original-Received: by mail-it0-f70.google.com with SMTP id q75sf107150932itc.6 for ; Thu, 13 Oct 2016 05:21:35 -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=ykRvjrmdOipBYLJr8O6fsQqnAiZzjT+RiIOHoEwXIi8=; b=tFcaTJHF9PvkPPJ6Hdvz/QRa03pqwSJnaBJko0tyOBiQPJQEoIW3kgoPHTK3Vpg2Gv ntWeqaIv7bve40MrfZ5pxhtLAlx1WARa9TLV9ja1cVeYSFdtWY5GA/ZyY91n7ho1C08X LhFvMs3IDymd19cKyfDwjIFpIeJDQWPzwtWdhoBWoTzJObQ+6IevWmexrg+weqWs95j2 KecZhUCi1BJLgdwp0I+sPTch+dZihjibeQAIKW4kmI6l6thTkBSNdi6V7ouz0rpq05mS Jyee9j8fRNP/noE110ybIvIKRI0NHrxOcNm0bKk//S6KRT9iE7j/2nVm6+457f35qd1U uQ4Q== 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=ykRvjrmdOipBYLJr8O6fsQqnAiZzjT+RiIOHoEwXIi8=; b=uOYJYoFSKPG25P0RO1Z6Ckjo5BSFJ25REBq1gHeVbv1GIBqpYYKI2dpHsvn0oIM9Nc InMcwXE09CXTKBmh62C3KeJ+5+jvX5VlUul3d1t/KG2BMjSuIwkQQDLQXTlrkEG10FAr HSeQlXofg5GNHpBxOwOrVBtKbaKZHM6Y+MMq7P+G5pShVum51QU6ZBo+NRrp7xr0f/63 o+SHa3siM2ZD3CH/0ulEfwHQZJn0zlsCT3Jz+2GQfjgfiVnukz4b9cEFuuSI2sxFCEgg j9kMvZhXGQPTpXOZjAozp5b/JFv/AM6ivssPbnPbpk5gyHCtivIFnJO6DNh4sN6Zavz8 Z/hw== 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=ykRvjrmdOipBYLJr8O6fsQqnAiZzjT+RiIOHoEwXIi8=; b=Ja8biF+XHqMLncr9UjpDsFzl119GkTQyc3ZDvtrwGQsrcPhJamW7CJcL+KKghk+3GV 4nrbOGDkXcLA7jp2KclYd63NUAKoQXS6LD1FuhNvWxPx+DcskDMNtcVi7r6qqkzZYOuA +JkrxGgqskHT+YNVfCoTWFPCW6fzCbeWa5fYANNbbYkYnnep/MvvbspZwLecAfVuabSD NQFlBDd3nQ1mo9fc5MzAAhHsd9GyH2WkNW6MXQH8nhcFu09eIn9TYv509XFTexiVoUqB SbvveCoSjIYooBVM9GWRIfx/4kRpdJbK9S0Lp57Mga9As4E81wNcdNafHLtvov29cvW/ u8kQ== X-Gm-Message-State: AA6/9RkWWXUOFnbAGG3iszYO/5lzoqQw59Stln5+CldWiv6fEo9UXcKK2eD3r4pfc/SgSw== X-Received: by 10.36.227.205 with SMTP id d196mr2125566ith.14.1476361295402; Thu, 13 Oct 2016 05:21:35 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.230.3 with SMTP id e3ls2413197ith.7.gmail; Thu, 13 Oct 2016 05:21:32 -0700 (PDT) X-Received: by 10.36.77.75 with SMTP id l72mr485537itb.1.1476361292580; Thu, 13 Oct 2016 05:21:32 -0700 (PDT) In-Reply-To: <330ab8be-0fce-4e55-8e34-925a81fc61be@isocpp.org> 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:28791 Archived-At: ------=_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 >>>> 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 '.' expression by itself is a literal for > some std::identifier (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. > std::as_field(std::assignment_expression) returns an unspecified > structure with a single field named 'identifier; of type T. Similarly, > std::identifier::operator(T x, Rest... rest) would return the result of > the first valid of these: x., x.(rest...), > (x, rest...), does_not_understand(std::identifier, x, rest); > constexpr identifier::name() would return a string_view over > "". > > 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), '. = ' is not a real expression, and '.' itself does not form an expression as well. While you can still implement the `identifier` 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
On Thursday, October 13, 2016 at 6:50:30 PM UTC+8, Giovann= i Piero Deretta wrote:
On Thursday, October 13, 2016 at 11:04:47 AM UTC+1, TONGARI J wrot= e:
On Thursday, Oct= ober 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 + temp= late arg deduction from ctor (C++17), this is possible:
std::tuple tup(.foo =3D 10, .bar =3D 20); // deduced to std::tuple<int.foo, = int.bar>
assert(tuple.foo =3D=3D 10);
assert(tuple.bar =3D=3D 20);


So it = seems! That's exactly my end game.
Do you already have some draft p= roposal? 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 pro= posal yet, I only have a working implementation based on Clang (still some = ABI issues to solve).

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 :).

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_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::iden= tifier<I>, x, rest); constexpr identifier<I>::name() would retu= rn a string_view over "<identifier>".

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.
<= div>
It's quite cool as a macro approach.

<= /div>
The unspecified `I` in your idea maps directly to the "templ= ate declname parameter" in my design.

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.
While you can still implement the `identif= ier<I>` as you described, but I think it becomes unnecessary.

The ability to retrieve the name string is worth consider= ing, could be a variable template that connects to some compiler intrinsic.=

--
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/cb3a913d-7227-49fa-af5a-03b89690f822= %40isocpp.org.
------=_Part_736_1115471485.1476361291234-- ------=_Part_735_24122487.1476361291234-- .