220 23710 article Path: news.gmane.org!not-for-mail From: Matthew Woehlke Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: invoke and unpacking tuple-like type instances Date: Thu, 14 Jan 2016 12:00:27 -0500 Lines: 64 Approved: news@gmane.org Message-ID: References: <56914870.3020407@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 1452790857 6205 80.91.229.3 (14 Jan 2016 17:00:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Jan 2016 17:00:57 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC37LBFWUIFBBOFI362AKGQEFYQ7H4Y@isocpp.org Thu Jan 14 18:00:44 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f71.google.com ([209.85.215.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aJlGM-0003GP-Pu for gclcip-std-proposals@m.gmane.org; Thu, 14 Jan 2016 18:00:42 +0100 Original-Received: by mail-lf0-f71.google.com with SMTP id b134sf165247430lfe.2 for ; Thu, 14 Jan 2016 09:00:42 -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=moIpJPcKNBwmnIR2AeMPkxrIaHeMqER+QD/QIHoq9gQ=; b=LYd1N4Zj6fsc3aBwmKB7S/HFKJBJDVQeOS+frScdhId07IMSojuZzXowzlHRuoECpJ mkSq2VZ7JApQN3NdpqoCwFOZEucRXi9RCSSGlcXjXucurXamULyrf6fG8YKlapH+QfFB ImFgASTvSvkotl5nuTxID8IDBnMIc5CiNxcloREFvwXWyQt8sOhGEfNGVhSvRhFIeOeX bDB/kXyopOs1NRlA7kfJeAben4/8S0YBVSOvcy6AQ3QKSRFLV2FHDldotCZV5XxYtlNN sb83G6gyc1UNMQHqJlnAlANZ/jL3Ts26ihv1a9PiskamRnvnt+fDN/x6EoKNUlzGiT0A F2e 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=moIpJPcKNBwmnIR2AeMPkxrIaHeMqER+QD/QIHoq9gQ=; b=bRZnbmnOi9kRc4kO5j2m7YkZX/SCPAljZu4mrQsAewjWR+5SnGAnVp/qAF8i/kKgD3 0DGwjjU0Wc2x0XqGscxhwa2ZumdTDR6kyiSEDlChaLKyKDX3YZ+8I5v8L5SX/PxEdvTo J5rbFfkQRGRHcmpqgReQJu+cP7Gt8xM4MTiGWMBis38to1KIgVTPkG7OLGtIyki5Gyxz enUMAoq3acVk5noVwzJt8y7Uvsys5nTYSpmoNgzNTMmInlq1RvcpGTQC9IqglrY8tM2m ru6nXaEqNl2Rcu3OaOIyChLKa0ec8m7EZxwwcM5EfrT/LWweaOHgH9wKdC+VZg43eYbG X-Gm-Message-State: ALoCoQn1plDVbJM9GsAG3dqns7mkwYaR/vELiRd1oUmCM7KCouMpzmR4YL7HAQsA125eVYwkO6o+FMw9z8xUstMP9ps8R5TMsg== X-Received: by 10.112.198.163 with SMTP id jd3mr465212lbc.24.1452790842098; Thu, 14 Jan 2016 09:00:42 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.170.140 with SMTP id t134ls84735lfe.20.gmail; Thu, 14 Jan 2016 09:00:39 -0800 (PST) X-Received: by 10.25.31.136 with SMTP id f130mr1372820lff.5.1452790839917; Thu, 14 Jan 2016 09:00:39 -0800 (PST) Original-Received: from plane.gmane.org (plane.gmane.org. [80.91.229.3]) by mx.google.com with ESMTPS id n126si3562777lfn.66.2016.01.14.09.00.39 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 14 Jan 2016 09:00:39 -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 1aJlGF-0003BO-Ai for std-proposals@isocpp.org; Thu, 14 Jan 2016 18:00:35 +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 18:00:35 +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 18:00:35 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 55 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: <56914870.3020407@wanadoo.fr> 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:23710 Archived-At: On 2016-01-09 12:50, Vicente J. Botet Escriba wrote: > I would like to have some feedback on a function that acts as unpacking > tuple-like classes in the context of the invoke function. This was > presented already with the name args(t) as an alternative library > solution to unpack tuple in the thread "[std-discussion] Distinction > between Argument packs and tuples" [1] where an operator... on tuple was > proposed. The proposed operator... introduced breaking changes and so > another operator would be needed. > > [...bunches of examples...] Ugh, is the benefit of not adding a language feature *really* worth all the ugliness, difficulties, and limitations entailed in using the suggested library feature? Not to mention that there is now a magic type that behaves differently in certain functions? In a post-unpacking world, the compiler already knows how to transform a tuple-like into a value sequence. Surely, then, it is not so terrible to add the ability to do this in place: make_tuple([*]t); == t, if 't' is a std::tuple f(a, b, [*]t1, d, [*]t2); I fail to see why it is difficult for the compiler to transform these into: auto&& __t0 = t; // if 't' is an expression rather than a variable make_tuple(get<0>(__t0), get<1>(__t0), ...); auto&& __t1 = t1; // let's say t1 is a 3-tuple auto&& __t2 = t2; // ...and t2 is a 2-tuple f(a, b, get<0>(__t1), get<1>(__t1), get<2>(__t1), d, get<0>(__t2), get<1>(__t2); This way, there is no magic unpacking type, and unpacking can be used in any context where a value sequence is permitted; not just contexts that have been special cased for the magic unpacking type. Just as one offhand example, why shouldn't I be able to unpack a tuple-like into an initializer list? Or ctor arguments? (This neatly solves the issue previously discussed of converting between types with similar layouts that don't otherwise have any knowledge of each other.) > Waiting for a language-based proposal, is there an interest in a library > proposal providing a partial solution (unpack needs invoke to be expanded)? Per above, I think a library solution is inferior, and I don't like adding one when we "know that we need" a language-based solution, as we end up with multiple ways to do the same thing, one of which is superfluous. I also think the library solution is actually *harder* to specify. Do I need to (co?)write a proposal for a language feature? -- 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/. .