220 25323 <56F063B9.4080201@wanadoo.fr> article Path: news.gmane.org!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: [RFC] Call for considering "the big picture" re: tuples and parameter packs Date: Mon, 21 Mar 2016 22:12:25 +0100 Lines: 80 Approved: news@gmane.org Message-ID: <56F063B9.4080201@wanadoo.fr> References: <1FCE896E-001A-4F56-8866-FB201ABF3391@gmx.de> <6605C1A6-7DB7-4CDF-9B36-BEE95D90CAED@gmx.de> <56EF33D4.5070509@wanadoo.fr> <20160321032111.4898897.41547.8488@gmail.com> <5544dac2-1449-4039-89b9-e72e98a3db36@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1458594763 6719 80.91.229.3 (21 Mar 2016 21:12:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Mar 2016 21:12:43 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBBOWHYG3QKGQE5LD5LTY@isocpp.org Mon Mar 21 22:12:34 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f70.google.com ([74.125.82.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ai77j-0005zy-PM for gclcip-std-proposals@m.gmane.org; Mon, 21 Mar 2016 22:12:27 +0100 Original-Received: by mail-wm0-f70.google.com with SMTP id p65sf37291994wmp.3 for ; Mon, 21 Mar 2016 14:12:27 -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:content-transfer-encoding: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=QoPNk5zAd/vQm9UL9GL+2/Z9Ml0ovdWaQnnUjR/UQmk=; b=yWvJ3c6O1u2kFJ3+FavDuB6PuCUr+aBeUs2l6LFyM70L40dlPr08dHAx776GLVMTjv O9HtX+Cz+hH9hXwpOo8QG2Thfvvzs4ilhQNg5uP/VskbZF3sERF6lNPdYvtlt75zKIDv ddUFQZ95yEBe+1ihhnRWb+T9H/5FQwrNF825qTICflW370aw5wSaoFIYu7V6HeCEldqw 4hGSV6ktvB8/sVBqFMOjFXjYiOHUcWF8xON2rz0uGTRdOKV8RFSLh3lUdmA9cT7vVGog 1lrJ0dT0q3XfKIYPbGZd8joo9ZDAOEMzlmF6ofQ2sjiEA/K3SafD3tdgGirArfFKlGcn 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:content-transfer-encoding :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=QoPNk5zAd/vQm9UL9GL+2/Z9Ml0ovdWaQnnUjR/UQmk=; b=BMKDT3xAiC/KSUZpesLPyDK3upKh6ae5sl2DObgQrEMqZIf+j1OmGws+L5mWAMBdGi H8WRoC+dLZAImae4nOkoBVlnIHSkbE0zHcpGtoMouhNRPrUMt6bBPNd0tntnAU+4vVgG Z6E32uRgA8g240L1jJ8tyuvFNU8u6/F5rqK1jXKq6pD5dOIeeVetrWbQOkn8Y98hhIS/ LGdwD5pcHrFM+3zHbz0IKqb8xuuZ88WM4AQqVUhtQnkS2gVfyL6Sp+TntBsUXk/H+pXv 2FiFMAq8oj88Is15UP8NsafXkxTVAxE4snXe+sr9fHF6J9oFGMZvRX3OyRp/kRR3lfwH X-Gm-Message-State: AD7BkJKF/oKOettl6SPOSb2v/JVE2X6CnjwlDrWlBpOo+PJ38MsiIzBFS8gGgRO+GS3+gQ== X-Received: by 10.194.24.233 with SMTP id x9mr4022022wjf.0.1458594746965; Mon, 21 Mar 2016 14:12:26 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.23.212 with SMTP id 203ls260305wmx.54.gmail; Mon, 21 Mar 2016 14:12:25 -0700 (PDT) X-Received: by 10.194.203.5 with SMTP id km5mr36059148wjc.172.1458594745687; Mon, 21 Mar 2016 14:12:25 -0700 (PDT) Original-Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr. [80.12.242.131]) by mx.google.com with ESMTPS id y7si10939514wjq.51.2016.03.21.14.12.25 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 21 Mar 2016 14:12:25 -0700 (PDT) Received-SPF: neutral (google.com: 80.12.242.131 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.131; Original-Received: from new-host.home ([92.139.140.101]) by mwinf5d32 with ME id YlCR1s0082BTYes03lCRqS; Mon, 21 Mar 2016 22:12:25 +0100 X-ME-Helo: new-host.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Mon, 21 Mar 2016 22:12:25 +0100 X-ME-IP: 92.139.140.101 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 In-Reply-To: X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.131 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-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:25323 Archived-At: Le 21/03/2016 19:46, Daniel Frey a =C3=A9crit : >> On 21.03.2016, at 19:27, Matthew Woehlke wrot= e: >> >> On 2016-03-21 14:10, barry.revzin@gmail.com wrote: >>>> Given a hypothetical (*RTI*) `std::any std::tuple::operator[]`: >>>> >>>> [...] >>> That [...] sounds >>> like a really good argument for not having RTI for tuple. >> No; not having something because it would be confusing *because we >> insisted on shoehorning two different features into the same syntax* >> sounds like a terrible argument. It sounds like a case of "what were you >> thinking when you made that design decision?". >> >>> It doesn't address why not CTI operator[] for tuple though. >> I really, honestly, genuinely don't understand why people want to abuse >> RTI syntax for something that *is not RTI*. >> >> CTI !=3D RTI. Quit trying to pretend otherwise. It's not worth it. > ... > >> (I also don't understand why people seem to think that prefix [] is the >> end of the world...) >> >> I want to access the N'th element of 'foo' >> -> Use []'s >> -> Do you want the access to happen at compile time or run time? >> -> Compile time -> [N]foo >> -> Run time -> foo[N] >> >> Why is this so hard? > Because some people feel the exact opposite. What is so hard about using = t[N]? I don't see *anything* wrong with it, the context makes it completely= obvious and straight-forward to me. Should I add phrases like: Open your m= ind and quit pretending there's a problem. Why is this so hard? It's not wo= rth it. :) > > Also, it makes the whole discussion really hard as I feel that you are no= t even considering "the other side". You are convinced that your way is the= right way and your wording does not show any openness towards other people= 's opinions. At least myself, I find prefix indexing an abomination, I have= never seen any language that has anything similar (e.g. on http://rigaux.o= rg/language-study/syntax-across-languages/). > > In fact, I think that your prefix operator[] is as inconsistent as choosi= ng/mixing CTI/RTI on postfix operator[], just in a different dimension. You= say it's prefix if it's CTI, postfix if RTI. Consistent in this dimension,= but considering that you are using it for both packs and non-packs, you ar= e inconsistent in that. For what I am proposing, you have CTI operator[] fo= r non-packs and ...[] for packs (implicitly CTI only). Your suggestion is n= ot purely better, it is trading one advantage with one disadvantage (syntax= -wise). > > I don't like [N]t neither. I would like also t[N], but reusing the=20 operator[](unsigned) will need some additional changes in the languages=20 that we don't have yet (that is Dependent types as Larry Evans pointed=20 out). This is a quite complex subject and I will prefer to stay on=20 something that is already available, like=20 operator[](integral_constant). It is not as elegant but=20 using User defined literals it could be acceptable. auto x =3D t[1_c]; Maybe we could consider different syntax for the customization point and=20 the user interface, I don't know. 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/56F063B9.4080201%40wanadoo.fr. .