220 28531 article Path: news.gmane.org!.POSTED!not-for-mail From: "'Herb Sutter' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: RE: A plea to reconsider adding Structured Bindings to language Date: Wed, 5 Oct 2016 14:13:32 +0000 Lines: 213 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: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1475676872 28409 195.159.176.226 (5 Oct 2016 14:14:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 5 Oct 2016 14:14:32 +0000 (UTC) Cc: "std-proposals@isocpp.org" To: Marc Mutz , "bjarne@stroustrup.com" , Gabriel Dos Reis Original-X-From: std-proposals+bncBDVZBNE36MNRBLEV2S7QKGQEQ2YPVGA@isocpp.org Wed Oct 05 16:14:25 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f197.google.com ([209.85.220.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1brmxP-0004H7-6V for gclcip-std-proposals@m.gmane.org; Wed, 05 Oct 2016 16:14:03 +0200 Original-Received: by mail-qk0-f197.google.com with SMTP id o68sf49813198qkf.3 for ; Wed, 05 Oct 2016 07:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:deferred-delivery :message-id:references:in-reply-to:accept-language:content-language :spamdiagnosticoutput:spamdiagnosticmetadata :content-transfer-encoding:mime-version: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=AfncOFi1FDw7Ww9L6UzaduJilFKiDywGB1bgEYPo2WA=; b=Z8qEB18FXiJiJmMbe6mSuHy8carwhAk+Z33R1pRYK3hEBz3/BQF16B08pdUl1CXPZJ Htg95hyZ9xxZDSUpy8ha95cGMxEFrgstlJb58iIBHya8RczZ4MXcwrC7ge9CZk1WYhDq 5N/gqa5Tgc+WrRRbiN9aC5DOw1eZDt8EFKmu0aB3YXPUC5/N7fGdZMhOG50llByvHKCf 71+xXpcnR2IowyqxU6h X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:deferred-delivery:message-id:references:in-reply-to :accept-language:content-language:spamdiagnosticoutput :spamdiagnosticmetadata:content-transfer-encoding:mime-version :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=AfncOFi1FDw7Ww9L6UzaduJilFKiDywGB1bgEYPo2WA=; b=mXuW9AXmXfr1WiGAQSFiibXKVuXnwueznnNxImzn5plCzXoW9tLzZelvAKtpDMg2bu AmQ1RWmR2AsUDkiYx7YonQqYzqAWiLvoQruSrS4htj/xnrmUqtBdYDOkfmYAqxOk3kda hztNw+/HAq48X5D66C6If3IAl1S87SKvPZvWrnOGY+PLUe0/9yaJvbMhiMA82zCZ4ZiT BUf8c0AVR7NCGQM X-Gm-Message-State: AA6/9Rky7gYsb1b2InXYJzFR1sFuWNWO6qYK/mD4RMvkmfcm2G7p7MF9ZLJgwCeEd5mStA== X-Received: by 10.129.125.133 with SMTP id y127mr2321748ywc.69.1475676844994; Wed, 05 Oct 2016 07:14:04 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.33.198 with SMTP id s64ls730457otb.15.gmail; Wed, 05 Oct 2016 07:14:04 -0700 (PDT) X-Received: by 10.31.97.67 with SMTP id v64mr6598427vkb.119.1475676844182; Wed, 05 Oct 2016 07:14:04 -0700 (PDT) Original-Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0092.outbound.protection.outlook.com. [104.47.32.92]) by mx.google.com with ESMTPS id 107si11688642uaj.77.2016.10.05.07.14.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 05 Oct 2016 07:14:04 -0700 (PDT) Received-SPF: pass (google.com: domain of hsutter@microsoft.com designates 104.47.32.92 as permitted sender) client-ip=104.47.32.92; Original-Received: from BY2PR0301MB2070.namprd03.prod.outlook.com (10.163.197.12) by MWHPR03MB2814.namprd03.prod.outlook.com (10.175.135.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Wed, 5 Oct 2016 14:13:56 +0000 Original-Received: from BY2PR0301MB2070.namprd03.prod.outlook.com ([10.163.197.12]) by BY2PR0301MB2070.namprd03.prod.outlook.com ([10.163.197.12]) with mapi id 15.01.0649.024; Wed, 5 Oct 2016 14:13:56 +0000 Thread-Topic: A plea to reconsider adding Structured Bindings to language Thread-Index: AQHSHvRXAszFt5h1XkGkpjZ9t/vd56CZ360w Deferred-Delivery: Wed, 5 Oct 2016 14:13:12 +0000 In-Reply-To: <201610051238.17863.marc.mutz@kdab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [208.53.108.19] x-ms-office365-filtering-correlation-id: 2bb782ca-2005-4d78-9da3-08d3ed29d7ef x-microsoft-exchange-diagnostics: 1;MWHPR03MB2814;7:EGmTkEopViXzXa9lU47ynrmG0pQ9KjNMBFH3nZZecSKDewQc9ZY5Mv0NYSqXAaB8uVRfQSp0n19YLDlIu+4n5wiA7BavKs/uTJYhCImgom3iRrVebBEtR610BzLussd5sFZ9fRLWKBav4fwoWNSFMexVisAEtSwgd8k3BZQz0ui+avE87eP0P9aCxmZc6R4KGJOSJlCQ6x/YzRKilEz0aJzy7OUOe80Ql8nuzeaaPJEiEBnQSLh4izzVlXOS2cgBjJAjLRJq9oH3xpKcsSxL7zywLWRm8j/MFZiobKf6gOpUWxGcKozYIPyOBhgan6I9eTwP+uyPTm5q4He+c2vhMA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR03MB2814; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038);SRVR:MWHPR03MB2814;BCL:0;PCL:0;RULEID:;SRVR:MWHPR03MB2814; x-forefront-prvs: 008663486A x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(7916002)(199003)(377454003)(13464003)(189002)(10090500001)(2950100002)(561944003)(15975445007)(77096005)(189998001)(8936002)(5001770100001)(97736004)(102836003)(76176999)(122556002)(50986999)(54356999)(2421001)(2900100001)(6116002)(4326007)(11100500001)(2906002)(2501003)(5002640100001)(8990500004)(92566002)(87936001)(19580395003)(19580405001)(10290500002)(5005710100001)(10400500002)(6666003)(6636002)(68736007)(8676002)(9686002)(31430400001)(7846002)(7736002)(81166006)(86612001)(2561002)(66066001)(1511001)(7696004)(3846002)(5660300001)(106116001)(86362001)(99286002)(101416001)(6862003)(74316002)(105586002)(3660700001)(305945005)(81156014)(76576001)(106356001)(3280700002)(33656002)(586003);DIR:OUT;SFP:1102;SCL:1;SRVR:MWHPR03MB2814 ;H:BY2PR0301MB2070.namprd03.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2016 14:13:55.8886 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR03MB2814 X-Original-Sender: hsutter@microsoft.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@microsoft.com; spf=pass (google.com: domain of hsutter@microsoft.com designates 104.47.32.92 as permitted sender) smtp.mailfrom=hsutter@microsoft.com; dmarc=pass (p=QUARANTINE dis=NONE) header.from=microsoft.com X-Original-From: Herb Sutter 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:28531 Archived-At: > I heard about Structured Bindings for the first time at CppCon this year,= and I'd > like to raise my concerns, esp. since half of the panel was crazy about t= hem. Thanks for your interest! Did you read the design paper? It answers many of= these questions. > The reaons it's horrible,=20 Note that you're making a strong value judgment about something you heard a= bout two weeks ago. You're coming into a design discussion that has been di= scussed in depth at multiple meetings for nearly a year, and while new info= rmation is welcome it's always good to enter a discussion-in-progress by tr= eading lightly (e.g., start by asking whether something has been considered= ). Especially when "half a panel" of people who have been in the deep desig= n discussions and understand the feature like it a lot. :) > is because it reverses the C++ principle that the > implementor of a library should have to do the work, not the user. >=20 > It reverses the principle by requiring the *caller* to choose the names o= f the > values returned,=20 The caller always chooses the name of a returned value in their scope: auto my_name =3D f(); SB is just giving them a way to gives names to the individual components if= they want to work with them directly, instead of a name to the whole compo= site entity: auto [my_name_1, my_name_2] =3D f(); > when it should be the implementor of the function who > chooses the names. You can have your cake and eat it too, because SB works with structs: > IMHO, the correct solution to the multiple return value problem is to ret= urn a > struct with properly named fields, not a pair and not a tuple. (Actually IMO the correct solution is multiple return values. Returning a s= truct is our current workaround, the closest approximation in today's langu= age.) That's fine, you can do that, and it works fine with SB. . Here's an exampl= e from my own recent gcpp library, https://github.com/hsutter/gcpp: struct contains_info_ret { gpage_find_result found; std::size_t location; std::size_t start_location; }; contains_info_ret contains_info(gsl::not_null p) const noexcept; The only thing that C++ doesn't currently let you do is to omit the "; cont= ains_info_ret" in the middle, to declare a struct in the position of a retu= rn value. From time to time people suggest allowing that; I wouldn't be sur= prised to see it proposed in the future. (I would like to see that proposal= .. I would even more like to see a multiple return values proposal.) But SB works fine with this, because it allows the caller to write both thi= s: auto info =3D page.contains_info(ptr); if (info.found =3D=3D /*...*/) { use(info.location, info.start_location); } and this: auto [found, offset, start] info =3D page.contains_info(ptr); if (found =3D=3D /*...*/) { use(offset, start); } Returning a struct should be thought of as the callee returning "default" n= ames for the caller to use. With SB, the caller has a choice and can either= use the default names or else provide more meaningful names if they want t= o; it doesn't hurt your preference for returning a struct at all, in fact i= t cooperates very well with that -- and that's not an accident, it's by des= ign since the very first design paper. Herb > -----Original Message----- > From: marc@kdab.com [mailto:marc@kdab.com] On Behalf Of Marc Mutz > Sent: Wednesday, October 5, 2016 3:38 AM > To: Herb Sutter ; bjarne@stroustrup.com; Gabriel > Dos Reis > Cc: std-proposals@isocpp.org > Subject: A plea to reconsider adding Structured Bindings to language >=20 > Hi Herb, Bjarne, Gabriel, >=20 > I heard about Structured Bindings for the first time at CppCon this year,= and I'd > like to raise my concerns, esp. since half of the panel was crazy about t= hem. >=20 > I strongly believe that the premise that returning std::tuple from functi= ons to > solve the multiple-return-types problem is good practice, is fundamentall= y > wrong. >=20 > It is not good in any sense of the word. It is horrible. Indeed, it is so= horrible that > you felt inclined to add a new language feature just to make it bearable. >=20 > The reaons it's horrible, is because it reverses the C++ principle that t= he > implementor of a library should have to do the work, not the user. >=20 > It reverses the principle by requiring the *caller* to choose the names o= f the > values returned, when it should be the implementor of the function who > chooses the names. >=20 > In conjunction with auto deduction, the caller choosing the names means t= hat > the code becomes brittle in the face of changes to the return type, e.g. = when > reordering fields to fill padding holes. >=20 > Structured Bindings would be acceptable if, like scripting languages, we = didn't > have anything else to work with. >=20 > But we do: We can return a struct. >=20 > IMHO, the correct solution to the multiple return value problem is to ret= urn a > struct with properly named fields, not a pair and not a tuple. >=20 > I fear Structured Bindings will lead to an explosion of *really* bad API = that > returns std::pair or std::tuple when it should return a small struct with= well- > named data members instead, because a) the implementor couldn't be bother= ed > to pick good names for a return struct, and b) tuples can be defined on t= he fly, in > the function declaration, whereas structs can not. >=20 > I believe there's a proposal for allowing to define structs in function d= eclarations > already, but I failed to find it. >=20 > Consider: >=20 > std::map::insert(...) -> std::pair >=20 > or the other way around, I can never remember, which is a problem that > structured bindings don't solve for me. Yes, in this case using the itera= tor as a > boolean will fail, but what about algorithms that return multiple iterato= rs? If you > get the order wrong, then you have a bug. >=20 > No, map::insert() should have returned a >=20 > struct { iterator iterator; bool inserted; }; >=20 > so one could say: >=20 > if (map.insert(...).inserted) >=20 > or >=20 > auto result =3D map.insert(...) > if (result.inserted) >=20 > To summarise: I feel that Structured Bindings are too easy to use incorre= ctly, > because they put the burden of choosing a name for the fields of a return= value > on the caller, instead of the implementor, of the function. I'd like to s= ee the > pattern to return structs from functions strengthened, not the anti- patt= ern of > returning pairs and tuples. >=20 > I therefore hope that I can persuade you to reconsider adding Structured > Bindings to C++17. >=20 > Thanks, > Marc >=20 > -- > Marc Mutz | Senior Software Engineer KDAB > (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - Qt, C++ and OpenGL Experts --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/BY2PR0301MB207067A62039FBA165EB7AEFB8C40%40BY2PR= 0301MB2070.namprd03.prod.outlook.com. .