220 23729 article Path: news.gmane.org!not-for-mail From: Matthew Woehlke Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Default tuple-like access Date: Thu, 14 Jan 2016 17:11:04 -0500 Lines: 60 Approved: news@gmane.org Message-ID: References: <569583AD.9050208@wanadoo.fr> <5697E783.2020509@wanadoo.fr> <5698067B.3010706@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 X-Trace: ger.gmane.org 1452809504 29448 80.91.229.3 (14 Jan 2016 22:11:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Jan 2016 22:11:44 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC37LBFWUIFBBC524C2AKGQEZFSGKOY@isocpp.org Thu Jan 14 23:11:35 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f69.google.com ([74.125.82.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aJq7A-00061l-3N for gclcip-std-proposals@m.gmane.org; Thu, 14 Jan 2016 23:11:32 +0100 Original-Received: by mail-wm0-f69.google.com with SMTP id u188sf107735457wmu.3 for ; Thu, 14 Jan 2016 14:11:26 -0800 (PST) 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 :content-type: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=R0T1qR4IAKUhsdG4TP7itbuiCFi+ebESYvPih4TDD1w=; b=c7AtSNcwamVpihA/gC8/yhh9LrqC8HfVVk+h/fvqXe33/VhV8D8S1XQ+E+M3E3j3LD NUH0Gua+V4I1CWN06Ubsko8brjy1aQ6TTuanuriEKYuDNbWSCf9ObKfdf3rtF/E4NHHk wVnOSiHeo6E4CGxeWeOv9fA97o3+5elRIWl4wnNfl4hmtmeMM3P4CrOrhUsRct+QN1xq K0Hdz3AgnbfZo+97Bs2WdkgsurINM6jysgh6zYsrKaz0I+1vExxepWCYDcMHPTfAhSXg yhR5a94EBxqDp7fFL3iqpPANxBxgLBdseKs+qXnw/MD+QIzwBjPIeZOh9FDvAqVZCiFu tr8 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:content-type: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=R0T1qR4IAKUhsdG4TP7itbuiCFi+ebESYvPih4TDD1w=; b=ddtVV3/B+GjS63/BcYm5zcU6vYIE3zKO8YNReEYqtGOKypIfvpc4k6llSrPuWjJL8L 8zkyLI4g+mrOuO2Gp5eprDTdG/8ej2qI+v14kavxa5xy2wZthybuPrDGgFONpTMXql2g Jbyz6Ds9pQTkN4G5S8GAdDmWSHiwDYOqzO04EaUjBBYE0FfnsHrelIQ5PyuaV9k8QIqE RhJJXcoVHuiJZalxPxFjwkHEv8qdYVZmI4BuBi+25GGYysj+E0uONUt2cBRDfXniRsMJ KMDctipzitx1PQdfWqFcn/4Yp8sr9xGaQRsOTlXS+N1Nh1ZHKY3m7NQU4uFhKQELRz1Z X-Gm-Message-State: ALoCoQmiQUqfe6/uaTDLlzg9xRDgJ3redKJCFREJWt7/Vq132s/ey9mmnjpu1YU79r9raNcfRsOK+DaKObv+mtLsocSeXeQjfQ== X-Received: by 10.25.131.150 with SMTP id f144mr756535lfd.6.1452809486436; Thu, 14 Jan 2016 14:11:26 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.79.77 with SMTP id d74ls107244lfb.24.gmail; Thu, 14 Jan 2016 14:11:22 -0800 (PST) X-Received: by 10.25.20.218 with SMTP id 87mr1856452lfu.148.1452809482690; Thu, 14 Jan 2016 14:11:22 -0800 (PST) Original-Received: from plane.gmane.org (plane.gmane.org. [80.91.229.3]) by mx.google.com with ESMTPS id k141si4143703lfb.200.2016.01.14.14.11.22 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 14 Jan 2016 14:11:22 -0800 (PST) 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 1aJq6s-0005sM-IE for std-proposals@isocpp.org; Thu, 14 Jan 2016 23:11:14 +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 ; Thu, 14 Jan 2016 23:11:14 +0100 Original-Received: from mwoehlke.floss by tripoint.kitware.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Jan 2016 23:11:14 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 51 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: 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:23729 Archived-At: On 2016-01-14 16:40, Nevin Liber wrote: > On 14 January 2016 at 15:04, Matthew Woehlke wrote: >>> I don't see how implement the tuple_size you are suggesting efficiently. >>> How will you find the N? trying with get<0>, get<1>, get<2>, ... get, >>> up to a failing get? >> >> Yes, exactly. I don't see a serious efficiency problem here; I expect >> that in most cases, the number will be small, > > Please don't make that assumption. It reminds me of life before variadic > templates. I'm really struggling to think of why you would have a (non-array) tuple-like that has more than a few dozen members. That's a *very* complicated complex type. (Array-like types don't count; you'll almost certainly specialize tuple_size for those.) > One use case for knowing N is when you want to get things in reverse > order. Users shouldn't have to go through hoops just to figure out how to > do that, nor write code that requires O(N) template instantiations to > calculate it, because when they get it wrong, they'll still get horrible > error messages. ....but it *doesn't* "require O(N) template instantiations". That's just the case *if you don't provide a specialization*. If you have a type for which N is large, then provide your own tuple_size. Nothing about what I'm suggesting prevents you from doing that. This is why I don't understand the objection; either I am not adequately communicating my suggestion (maybe), or you are concerned that having the *option* to be lazy will have disastrous consequences (which I don't understand / agree with). Let me restate that for clarity: code that will work under your proposal as-is will work *exactly the same* with my modification. The only case that is different is if tuple_size is not user provided; without my modification, such code won't have a tuple_size *at all*. With my modification, it will have a (possibly inefficient) implicit implementation. That said... back up a moment and remind me when tuple_size is actually needed? Does unpacking need it, for example? Or is it only used in user code? If I can do most of what I want to do with a tuple-like by providing only get, then I care less. What I really want to avoid is being required to define tuple_size *in addition to get* for a 2- or 3-tuple before I can do anything useful with it. To me that's just pointless extra work that the compiler can and should be doing for me. -- 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. Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/. .