220 28527 article Path: news.gmane.org!.POSTED!not-for-mail From: Viacheslav Usov Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: A plea to reconsider adding Structured Bindings to language Date: Wed, 5 Oct 2016 15:11:26 +0200 Lines: 91 Approved: news@gmane.org Message-ID: References: <201610051238.17863.marc.mutz@kdab.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114129222997cb053e1dea69 X-Trace: blaine.gmane.org 1475674917 10990 195.159.176.226 (5 Oct 2016 13:41:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 5 Oct 2016 13:41:57 +0000 (UTC) Cc: hsutter@microsoft.com, bjarne@stroustrup.com, gdr@microsoft.com To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBDU6VRPKW4BBBAHY2O7QKGQEDHMKC6Q@isocpp.org Wed Oct 05 15:41:52 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f69.google.com ([74.125.82.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1brmSD-000223-3U for gclcip-std-proposals@m.gmane.org; Wed, 05 Oct 2016 15:41:49 +0200 Original-Received: by mail-wm0-f69.google.com with SMTP id f193sf125296973wmg.0 for ; Wed, 05 Oct 2016 06:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc: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=7+1HsfiNBM0BzyQZFc1F3awcVHHBYcP8ltrZXBhmBKU=; b=QgzI9x8tgtWVP+htymFvlZigFBz6ePWCg47dwTGxQqqcD9iZxj7srygsNKpRJ00oMn oE1jwGbtHHDYiW6cBvJAdsVsYeSvWPlvULiHdTN2JrrpjOs0iG04pMF/xYy3EZZpaKFz pByj2eMa+m9coyk2Nnq/7NoJifo38Y2AC74mjYttMdYtPDcWBz4LVkVWrhCriJzcMGXD EnJ2Fo7QgwpuBEzVsoqnMVUZ0znLTldjPNkxo2XfgOxRNqddIFbwSZ16XZ5jtOFQmut8 6G2OMcb1j+1wczbzJN8hYaaECPlO+Jt2RcjsZ7FFvKA09tfn0/NP/b0+0O+aQJsDGgjs nmBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc: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=7+1HsfiNBM0BzyQZFc1F3awcVHHBYcP8ltrZXBhmBKU=; b=c8epEM1qukEKsgYsvrG6qhgIslyKZaewNGMhDXRTUXxmjfNxYXtijWOvvtQ2uVNWcP ptbPhmTEtXbamOQU7FT0Z5rGWlfNnMkF/8mvDwBZbWxCP5TY/aI/fUo3xVswHTDsOc8W vI9jVB8k+sIyUkdR9tLXjUyfbP5d6c90EJHgrA1sOM1IGi1DyuWKPClR22dZJVHBlvdh GVAo45fGDj8Jk92ANw5r9D/nJpPdw0GACTJCAt7uExXd2JbXqBT7vSB6+P5k92QruO84 aaswhoJctNhgD+QuZKVKweLbbLngDN8t6sCIhyX4gf9XVq2+gOr3tN3Ps7heEyQE7hrR rKwg== X-Gm-Message-State: AA6/9RlcIoteyq15RsuIeaMwQ0caJdQy/bWkQ99MUmTRuGop4zf7+v/28fBxtRszoTzSKw== X-Received: by 10.28.165.138 with SMTP id o132mr1285245wme.23.1475673089448; Wed, 05 Oct 2016 06:11:29 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.46.5.196 with SMTP id 187ls83316ljf.2.gmail; Wed, 05 Oct 2016 06:11:27 -0700 (PDT) X-Received: by 10.25.127.151 with SMTP id a145mr3308061lfd.53.1475673087625; Wed, 05 Oct 2016 06:11:27 -0700 (PDT) Original-Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com. [2a00:1450:4010:c07::22f]) by mx.google.com with ESMTPS id d80si5078126lfg.375.2016.10.05.06.11.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Oct 2016 06:11:27 -0700 (PDT) Received-SPF: pass (google.com: domain of via.usov@gmail.com designates 2a00:1450:4010:c07::22f as permitted sender) client-ip=2a00:1450:4010:c07::22f; Original-Received: by mail-lf0-x22f.google.com with SMTP id x79so16632741lff.0 for ; Wed, 05 Oct 2016 06:11:27 -0700 (PDT) X-Received: by 10.25.212.5 with SMTP id l5mr4328664lfg.73.1475673087119; Wed, 05 Oct 2016 06:11:27 -0700 (PDT) Original-Received: by 10.25.196.205 with HTTP; Wed, 5 Oct 2016 06:11:26 -0700 (PDT) In-Reply-To: <201610051238.17863.marc.mutz@kdab.com> X-Original-Sender: via.usov@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of via.usov@gmail.com designates 2a00:1450:4010:c07::22f as permitted sender) smtp.mailfrom=via.usov@gmail.com; dmarc=pass (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-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:28527 Archived-At: --001a114129222997cb053e1dea69 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 5, 2016 at 12:38 PM, Marc Mutz wrote: > The reaons it's horrible, is because it reverses the C++ principle that the implementor of a library should have to do the work, not the user. There is no such principle. Because what you say is impossible. A user of a library always has to do some work to use the library. What you probably wanted to say is that the library should do something that reduces the amount of work done by the prospective user of the library compared to the amount of work required without the library. But then this statement is trivial, because no one will use a library the use of which requires more work than its non-use. > It reverses the principle by requiring the *caller* to choose the names of the values returned, when it should be the implementor of the function who chooses the names. If there is a "horrible" library that makes coming up with good names, and typing them, an effort outweighing the utility of the library, it will have to evolve or die. > In conjunction with auto deduction, the caller choosing the names means that the code becomes brittle in the face of changes to the return type, e.g. when reordering fields to fill padding holes. That is a valid point, but a very similar problem exists with functions accepting multiple arguments. One can easily come up with horrible (contrived) examples, but, practically, I do not think this is a major issue. Cheers, V. -- 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/CAA7YVg3ByaVnodRBz06ez4CBH3CzC6r3OJJbh3oyUp5r%3DwNRig%40mail.gmail.com. --001a114129222997cb053e1dea69 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Oct 5, 2016 at 12:38 PM, Marc Mutz <marc.mutz@kdab.com>= wrote:

> The reaons it's horrible, is becaus= e it reverses the C++ principle that the implementor of a library should ha= ve to do the work, not the user.

There is no such = principle. Because what you say is impossible. A user of a library always h= as to do some work to use the library.

What you pr= obably wanted to say is that the library should do something that reduces t= he amount of work done by the prospective user of the library compared to t= he amount of work required without the library. But then this statement is = trivial, because no one will use a library the use of which requires more w= ork than its non-use.

> It reverses the princip= le by requiring the *caller* to choose the names of the values returned, wh= en it should be the implementor of the function who chooses the names.
<= /div>

If there is a "horrible" library that ma= kes coming up with good names, and typing them, an effort outweighing the u= tility of the library, it will have to evolve or die.

<= div>> In conjunction with auto deduction, the caller choosing the names = means that the code becomes brittle in the face of changes to the return ty= pe, e.g. when reordering fields to fill padding holes.

=
That is a valid point, but a very similar problem exists with function= s accepting multiple arguments. One can easily come up with horrible (contr= ived) examples, but, practically, I do not think this is a major issue.

Cheers,
V.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3ByaVnod= RBz06ez4CBH3CzC6r3OJJbh3oyUp5r%3DwNRig%40mail.gmail.com.
--001a114129222997cb053e1dea69-- .