220 25302 <20160321032111.4898897.41547.8488@gmail.com> article Path: news.gmane.org!not-for-mail From: Tony V E Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: [RFC] Call for considering "the big picture" re: tuples and parameter packs Date: Sun, 20 Mar 2016 23:21:11 -0400 Lines: 129 Approved: news@gmane.org Message-ID: <20160321032111.4898897.41547.8488@gmail.com> References: <1FCE896E-001A-4F56-8866-FB201ABF3391@gmx.de> <6605C1A6-7DB7-4CDF-9B36-BEE95D90CAED@gmx.de> <56EF33D4.5070509@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1458530487 29503 80.91.229.3 (21 Mar 2016 03:21:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Mar 2016 03:21:27 +0000 (UTC) To: "Vicente J. Botet Escriba" , std-proposals@isocpp.org Original-X-From: std-proposals+bncBCUZ5QWKNQIKTUN5W4CRUBAX6DUQK@isocpp.org Mon Mar 21 04:21:20 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f197.google.com ([209.85.161.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ahqP6-0003IO-Lb for gclcip-std-proposals@m.gmane.org; Mon, 21 Mar 2016 04:21:16 +0100 Original-Received: by mail-yw0-f197.google.com with SMTP id i3sf120393288ywd.3 for ; Sun, 20 Mar 2016 20:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:content-transfer-encoding:message-id:date:subject:from :in-reply-to:references: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=uGsr1xFxdCg64UCuI9/8Htayg6n5+qFXxgSc8/+xN3c=; b=lg2MEZwoiHVna0SbgzVhYcw3yp11sqCeb6NETw9vaEUb2QOgjs7fcK8gVKoUqsuNLB yXudZ6gxLuMZY6RSQJwaQIAqJkNrPcZcJG+yA1k6VHFmumJvV8LZpWl2nS7b89zLx3w4 /49vEy412X3UCH/pdNOYdIIR+px/XOpMQYZJE3gXjdhOCEQeq+vmsaRcgpJGcrE9IrWf ixiLdgEUD7qhSTwi1qI3cvrSZLqJLYX0gUZ/HWfZqPRAilaXgPEWlt9rCCv9JRe9WGH/ c/dgJtrhjZ9xHX5SFwfl1kmimQqB6aup4rnR/gAKbsuzwRskfJzeqrvL7kygomd8swcE mloQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:content-transfer-encoding :message-id:date:subject:from:in-reply-to:references: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=uGsr1xFxdCg64UCuI9/8Htayg6n5+qFXxgSc8/+xN3c=; b=Mwr1NmcaQlwuaSVIM5FNur86o6F1b2r8N6Q1cpB/Uyr9/XBxC7inmFB8mOnCeS0r+/ R40YFp9663yocoJHzJqO7brxV8Jx+HxPDfnd9hleMu1f8f9BuHv8FGty0LtYfbv3uXdE j+o+P6LTJVcQfakMRM93sxqbERJYd5vJR4dG0uYNTpOLQiNP6FjLh9ngT/ZOQJZ8mgT1 069nnFPEtlZbXnZg9j/hFTdlIuP0nm0lHotmpjnuQ7qv1ypXBWxCpYPeY9jAmxla9cNm JciwBX5vMWRuWGHlCLAF9Gvqxnl/hxTZ8xtt0ZABPuTDauyHMcCFk0l4GZ8r7sQ3tF5L i6x X-Gm-Message-State: AD7BkJLYQxz2saVdTw+r65jTP9FmIATGlGzve4t9NduX/bHYiIXnVLxPh6vPcY67yt8BgA== X-Received: by 10.159.36.8 with SMTP id 8mr1109671uaq.13.1458530475454; Sun, 20 Mar 2016 20:21:15 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.122.66 with SMTP id lq2ls904926igb.26.canary; Sun, 20 Mar 2016 20:21:13 -0700 (PDT) X-Received: by 10.50.141.202 with SMTP id rq10mr9994556igb.59.1458530473796; Sun, 20 Mar 2016 20:21:13 -0700 (PDT) Original-Received: from mail-io0-x241.google.com (mail-io0-x241.google.com. [2607:f8b0:4001:c06::241]) by mx.google.com with ESMTPS id v42si15051872iov.152.2016.03.20.20.21.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Mar 2016 20:21:13 -0700 (PDT) Received-SPF: pass (google.com: domain of tvaneerd@gmail.com designates 2607:f8b0:4001:c06::241 as permitted sender) client-ip=2607:f8b0:4001:c06::241; Original-Received: by mail-io0-x241.google.com with SMTP id m184so16816792iof.3 for ; Sun, 20 Mar 2016 20:21:13 -0700 (PDT) X-Received: by 10.107.8.232 with SMTP id h101mr26626084ioi.93.1458530473543; Sun, 20 Mar 2016 20:21:13 -0700 (PDT) Original-Received: from [127.0.0.1] ([142.114.188.113]) by smtp.gmail.com with ESMTPSA id hu8sm4576255igb.21.2016.03.20.20.21.11 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 20 Mar 2016 20:21:12 -0700 (PDT) X-Mailer: BlackBerry Email (10.3.2.2876) In-Reply-To: <56EF33D4.5070509@wanadoo.fr> X-Original-Sender: tvaneerd@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of tvaneerd@gmail.com designates 2607:f8b0:4001:c06::241 as permitted sender) smtp.mailfrom=tvaneerd@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:25302 Archived-At: Could the member access syntax actually be s[N] for some struct or class s? ie just extend operator[] to allow the return type to be different for diff= erent constexpr inputs.=C2=A0 Then arrays (and vectors, etc) 'just work'. This assumes you never want to = access the actual members of vector (ie v._ptr and v._size or whatever the = vector implementation uses). I think it is safe to assume that any class th= at overrides operator[] wants to be array-like and doesn't want its members= exposed as a tuple.=C2=A0 ? Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi= ce =C2=A0 Original Message =C2=A0 From: Vicente J. Botet Escriba Sent: Sunday, March 20, 2016 7:35 PM To: std-proposals@isocpp.org Reply To: std-proposals@isocpp.org Subject: Re: [std-proposals] Re: [RFC] Call for considering "the big pictur= e" re: tuples and parameter packs Le 20/03/2016 18:44, Matthew Woehlke a =C3=A9crit : > On 2016-03-20 04:21, Daniel Frey wrote: >> On 19.03.2016, at 20:15, Matthew Woehlke wrote: >>> On 2016-03-19 06:53, Daniel Frey wrote: >>>> On 18.03.2016, at 16:51, Matthew Woehlke wrote: >>>>> [paper] >>> I'm going to try to keep this brief as it is turning into a discussion >>> on your proposal vs. mine, which really isn't the topic. (Parameter pac= k >>> stuff in general is really only partly on topic; the main topic should >>> be P0197.) >> In a way, it is the topic. We are both trying to solve problem in a >> similar domain, coming from different directions and with different >> ideas about how to solve those problems. > Well... okay, yes :-). I do go into this direction, and it is a topic > that I think needs to be resolved. Eventually. The reason I urgently > wanted the paper in the next mailing however is for the sake of P0197, > P0144 and their respective interactions. I agree that P0144 and P0197 are related and that considering the big=20 picture will help. However I don't think P0197 is ready to be adopted. Tony has raised on another thread that making a core language feature=20 depend on a library is something that must be avoided. P0144 doesn't=20 depends on a library until we decide to use tuple_size to check the size=20 of the tuples match. P0197 depend completely on the library and this=20 could be a showstopper to his adoption. The adoption of P0144 should be independent of P0197 in particular, but=20 we should consider the path to the big picture with pattern matching. I=20 believe that the authors of P0144 know already how this should be done. Davis Sankel has been working on a pattern matching feature for sum=20 types and product types [1] . This is not a concrete proposal yet but=20 give an idea of how to integrate both kind of types in the language.=20 David proposes to add some builtin operators that are used while doing=20 pattern matching. I believe that we need to define the concept of product/sum type in the=20 language because we want to provide features at the language level for=20 those types. * structured binding * pattern matching * direct access to the parts So, I'm planning to provide a revision of P0197 (or an additional paper)=20 that will take in account the possibility that the product type access=20 interface is not determined by the know get function and the trait=20 tuple_size trait, but from some specific operators. David proposes a single operator extract to extract the elements of a=20 product type. This is good when we want to extract all the members, but=20 not when we want one member., so I believe that we need 2 operators: one=20 to get the size and one to get the nth element. The=20 name/syntax of these operators needs to be defined, however, until that=20 I will name them `operator product_type_size` and `operator=20 product_type_nth_element`. I know that finding good names for them would=20 be difficult. Structured Binding ([P0144R1]) and pattern matching [1] should be based=20 on the same operators. The user should be able to define those operators for his own types and=20 the language should provide convenient default for them. To be compatible with the existing tuple-like types, I would propose to=20 update the definition of `tuple_size`, `tuple_element` and=20 `get/get` for product-types, and add the customization for those=20 operators for the standard tuple-like types `std::tuple`, `std::pair`=20 and `std::array`. In addition a c-array must be seen as a product-type, but we are unable=20 to define the get function on them. However if `operator=20 product_type_size` and `operator product_type_nth_element` are operators=20 we could define its meaning on the language for this builtin product type. If we had the good names/syntax for those operators, P0144 could be=20 adapted to them and be included in C++17. We could add PM and default=20 product-type access for aggregates and so later on. What do you think of this path? Vicente [1]http://davidsankel.com/uncategorized/c-language-support-for-pattern-matc= hing-and-variants/ P.S. Sorry I'm not considering at all the other part of P0301=20 (unpacking) and I consider that those are orthogonal features. --=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/56EF33D4.5070509%40wanadoo.fr. --=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/20160321032111.4898897.41547.8488%40gmail.com. .