220 23731 <56981E8C.1000703@wanadoo.fr> article Path: news.gmane.org!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: invoke and unpacking tuple-like type instances Date: Thu, 14 Jan 2016 23:17:48 +0100 Lines: 76 Approved: news@gmane.org Message-ID: <56981E8C.1000703@wanadoo.fr> 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; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1452809887 4213 80.91.229.3 (14 Jan 2016 22:18:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Jan 2016 22:18:07 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBBDN54C2AKGQE2BGKPJQ@isocpp.org Thu Jan 14 23:17:53 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f70.google.com ([209.85.215.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aJqDG-0002ih-Pp for gclcip-std-proposals@m.gmane.org; Thu, 14 Jan 2016 23:17:50 +0100 Original-Received: by mail-lf0-f70.google.com with SMTP id k69sf57200191lfg.3 for ; Thu, 14 Jan 2016 14:17:50 -0800 (PST) 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-type: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=Ks/HNbboj3RhNgloGwjJUw35AKclx9ANORDrICGEqrI=; b=JOURodNI+IGjnvF1Py08M9+n6sGj0LlbelFmCvTXANs8wSOg+DI8zOPFKQ/SiLN/EB L5LPqI2YioWvcHoQ22t5Q8HzZExBmWLUFg69D+sTaonhnAyg1XgVjdE7beQ7t0xTkQx3 K2hiXZYapdBFs6AkU7s3ORRR4slBbFR+QUmEybLZhIW7sUrgpmMDhXN1IWKL02n7C9vF lSVO75nXy2W+QOvcEtdvDA+BAaLKqF+ZqgH15uWHl718TjXlwNQckyKKVpEjdunnXy/P /7LMWkG0+zFxcwcrEz65XgOgtwkEBthSNC0s9aLtW1IOzUF5gWAvNfvQiJ/Mb 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-type :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=Ks/HNbboj3RhNgloGwjJUw35AKclx9ANORDrICGEqrI=; b=gkmwFoJJaysmqcSbfVGI9n98I9oeFglu8d5BY92qJzqCgbFv4Z7ukcxd6lfCeQf9Xl yb+6OPgQ1bY0s5dKd0c/OgP8sTcEo3sm2C24AgeEqfKap2zt9OAeAY8kH2IQ58UJ5Bpw Dir5zcfV270gHJZjDJXH/dz/jYlEIMU8un1pzUKeQYIXqCHW/4+dPN3A2+8scxTM7TZA HUSEkYqF0vBbttCdeM3e681Y3x3jkSanp+fuQb8LKl4CmgJWc7mofVQXAFkF2+fqFriv sg8Cpj/+FosJEcWwMprX94BMN1OD7PcbMJkf9BFXS+iWUfr X-Gm-Message-State: ALoCoQkpq5XRGfP8S510ZQ7PwNFUvIYjB/8zCRWNUD5rXnNQqWmZ6LJvws/5qUrNz4axLqUNyYUfQDn2t6OeTrUkYJ06T2/T/g== X-Received: by 10.112.138.98 with SMTP id qp2mr780964lbb.4.1452809870403; Thu, 14 Jan 2016 14:17:50 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.131.134 with SMTP id f128ls1190204wmd.45.canary; Thu, 14 Jan 2016 14:17:49 -0800 (PST) X-Received: by 10.194.110.106 with SMTP id hz10mr6467663wjb.135.1452809869380; Thu, 14 Jan 2016 14:17:49 -0800 (PST) Original-Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr. [80.12.242.128]) by mx.google.com with ESMTPS id di9si12694009wjc.18.2016.01.14.14.17.49 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 14 Jan 2016 14:17:49 -0800 (PST) Received-SPF: neutral (google.com: 80.12.242.128 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.128; Original-Received: from new-host.home ([92.139.160.222]) by mwinf5d64 with ME id 5yHo1s00J4oBxcU03yHp3n; Thu, 14 Jan 2016 23:17:49 +0100 X-ME-Helo: new-host.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Thu, 14 Jan 2016 23:17:49 +0100 X-ME-IP: 92.139.160.222 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.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.128 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:23731 Archived-At: Le 14/01/2016 18:00, Matthew Woehlke a =C3=A9crit : > 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? I will be happy to review a concrete proposal ;-) > Not to mention that there is now a magic type > that behaves differently in certain functions? Which type? > > 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); =3D=3D 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 int= o: > > auto&& __t0 =3D t; // if 't' is an expression rather than a variable > make_tuple(get<0>(__t0), get<1>(__t0), ...); > > auto&& __t1 =3D t1; // let's say t1 is a 3-tuple > auto&& __t2 =3D 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.) See my proposal as an incentive for you to write the language-like based=20 unpack proposal. > >> Waiting for a language-based proposal, is there an interest in a library >> proposal providing a partial solution (unpack needs invoke to be expande= d)? > 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? > For the time being, it is you that have raised this possibility, so yes,=20 I believe the answer is yes, you should. Vicente --=20 ---=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. Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos= als/. .