220 25315 article Path: news.gmane.org!not-for-mail From: Matthew Woehlke 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 14:44:56 -0400 Lines: 61 Approved: news@gmane.org Message-ID: 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> <18A7F6A4-7A7F-47A6-A7FE-401C9CC5306B@gmx.de> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1458585921 23306 80.91.229.3 (21 Mar 2016 18:45:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Mar 2016 18:45:21 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC37LBFWUIFBBNMCYG3QKGQEFWKHTUY@isocpp.org Mon Mar 21 19:45:12 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f72.google.com ([74.125.82.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ai4pD-0006DE-3c for gclcip-std-proposals@m.gmane.org; Mon, 21 Mar 2016 19:45:11 +0100 Original-Received: by mail-wm0-f72.google.com with SMTP id p65sf35730833wmp.3 for ; Mon, 21 Mar 2016 11:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=to:from:subject:date:lines:message-id:references:mime-version :user-agent: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=olbhEvKtJ8mSgtYcNhtIReQcPl+z1TIPfOuX402K0uk=; b=SUXrnyikqK7Nxb/LDdrFqMLUPAqik4RZg75y4bp6Fqryd7rbSIjJSEH1my8ftdNUIL CKshd75azsk/dXnYIlArFy705BKAG4Z/xXImMRLB0PsRvTjZRwnQTC6f7fK7c7Zr71Ip mntx/E4BCsvuuzAY/iL6FGPFRMa0rauGaVkjnfrUOjPCt1eK5w0bwHgSXhcHVwFhq7ih +b/hMNIDvcGlo5mAI6TRlFT74fwM9sDKRIwSdskgUAR/jgb57AckrohvqGJGj1ZeEDGA 1ef4b0vmxJMI/JtGvz3i0eDsObWtqK1P4YghZ3jVpmv9OFvQLxBoAQZOOgnl7IcHAgoq nRkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:date:lines:message-id:references :mime-version:user-agent: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=olbhEvKtJ8mSgtYcNhtIReQcPl+z1TIPfOuX402K0uk=; b=Zx+EPaujuIwy5SWvhiRfhO858ZrFYmv/vBY2rFCsi1t0OtV4s2mYTRucmgW8r4XrWT nOwLk9RxKHgQpye0X0IwgIwi4W6TmkXCRVfI8tybEZsDk4loz2FM2J+/12l9ec6RmfKK Y+0BHo6MyMywZDrj+I3/3YClVqofFaVW7M8pCiyR/bWkw0jCGpOCpkg3HE9Emvsb5JgE bXax2czffWGXt9uPmvzeUkICUcPAMxVv7Osx8tbxKSBn4DFFQFHg90qG/SEbhLv/qfQ/ 5gWcXEb+IhFoGx05StL7mlV/hLooUn/nHBb9aPjazBVWV1hw3x0sf7LSbcnVvaU6bNl+ GmVQ== X-Gm-Message-State: AD7BkJIipu545IZ6dQxGToUmZm38a5zsY4T6lTgqgWewe4sMW8cIzm3RIoNc6aN8HQtcaA== X-Received: by 10.112.40.200 with SMTP id z8mr3964355lbk.16.1458585910476; Mon, 21 Mar 2016 11:45:10 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.144.77 with SMTP id s74ls852098lfd.91.gmail; Mon, 21 Mar 2016 11:45:09 -0700 (PDT) X-Received: by 10.25.170.85 with SMTP id t82mr9320660lfe.57.1458585909129; Mon, 21 Mar 2016 11:45:09 -0700 (PDT) Original-Received: from plane.gmane.org (plane.gmane.org. [80.91.229.3]) by mx.google.com with ESMTPS id d198si13892167lfb.221.2016.03.21.11.45.08 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 21 Mar 2016 11:45:08 -0700 (PDT) Received-SPF: pass (google.com: domain of gclcip-std-proposals@m.gmane.org designates 80.91.229.3 as permitted sender) client-ip=80.91.229.3; Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ai4p9-0006B5-IR for std-proposals@isocpp.org; Mon, 21 Mar 2016 19:45:07 +0100 Original-Received: from tripoint.kitware.com ([66.194.253.20]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Mar 2016 19:45:07 +0100 Original-Received: from mwoehlke.floss by tripoint.kitware.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Mar 2016 19:45:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 54 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: tripoint.kitware.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: <18A7F6A4-7A7F-47A6-A7FE-401C9CC5306B@gmx.de> X-Original-Sender: mwoehlke.floss@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of gclcip-std-proposals@m.gmane.org designates 80.91.229.3 as permitted sender) smtp.mailfrom=gclcip-std-proposals@m.gmane.org; dmarc=fail (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:25315 Archived-At: On 2016-03-21 14:20, Daniel Frey wrote: > On 21.03.2016, at 18:56, Matthew Woehlke wrote: >> Given a hypothetical (*RTI*) `std::any std::tuple::operator[]`: > > Are you misreading what I said? tuple::operator[] is CTI only, there > is no confusion with RTI because tuple::operator[] is not a use-case for > overloading both. I'm not misreading; *you* are *ignoring* what I am trying to say, which is that this is a pointless, unnecessary, and potentially undesirable *artifically* limitation that is imposed by your design choice. > Only if a use-case has "obvious", non-confusing semantics, one would overload both. Even here, the code intent becomes less clear. For example: auto fifth(Vector& array) { return array[5]; } Let `Vector` be a Concept that requires array-like semantics. In particular, let's say that both std::array and std::vector satisfy the Concept. Can `fifth` throw? Is the array access run-time or compile-time? You're mixing two non-trivially different options in a way that potentially makes it unclear which one is being used. >> auto t = std::tuple{}; >> auto x = tuple[foo()]; > > I assume the second line is "auto x = t[foo()];". Ack, yes :-). > Anyways, if t is a tuple, foo() *must* return a constexpr. Again, that's an artificial limitation that *you* have imposed. > Again, tuple should not have RTI operator[]. Why not? Give me a good reason that has nothing to do with your desire to hijack the syntax (because that's a poor reason, and also a circular argument). This isn't irrelevant. Your proposal will have reprecussions, namely, limiting expressiveness by making it impossible, or at least very, very ugly, to provide both CTI and RTI for heterogeneous product types. If you're going to do that, the onus should be on you to show why having both would always be a bad thing, and therefore is an acceptable cost of your proposal (without simply arguing in circles). -- Matthew -- 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/ncpff9%24m26%241%40ger.gmane.org. .