220 28530 <38e94531-5370-450f-f33d-331c81d8f91f@Stroustrup.com> article Path: news.gmane.org!.POSTED!not-for-mail From: Bjarne Stroustrup Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: A plea to reconsider adding Structured Bindings to language Date: Wed, 5 Oct 2016 10:11:30 -0400 Lines: 104 Approved: news@gmane.org Message-ID: <38e94531-5370-450f-f33d-331c81d8f91f@Stroustrup.com> 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; format=flowed X-Trace: blaine.gmane.org 1475676758 10834 195.159.176.226 (5 Oct 2016 14:12:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 5 Oct 2016 14:12:38 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 Cc: "std-proposals@isocpp.org" To: Marc Mutz , hsutter@microsoft.com, gdr@microsoft.com Original-X-From: std-proposals+bncBDDP5YUK74KBBE4U2S7QKGQENPU6UHI@isocpp.org Wed Oct 05 16:12:33 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f72.google.com ([209.85.214.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1brmvQ-0006sM-QY for gclcip-std-proposals@m.gmane.org; Wed, 05 Oct 2016 16:12:00 +0200 Original-Received: by mail-it0-f72.google.com with SMTP id j69sf10204736itb.2 for ; Wed, 05 Oct 2016 07:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=from:subject:to:references:cc:message-id:date:user-agent :mime-version: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=mATwxIk8b9j+MlY4V3EQvjQw9z4o0y0JGX41w12Qkz4=; b=x6Ngzq0tMdP6cgixHSqC6i61PlLvhA70zg31jB8FUt9WlZYhASe6fkMRPV9pobjMnH 10FVSqMF4eSR7Y5fouJB1qg/gqrdO2ChpXlr2olCmSf8BxFRmU0ZhjfoEVeMgVJhFYKq YMsj5oHZdxN/RTr5WrqP4/2MrAWUgxRQvy9XpKM3XtRcd5FEEZmT1oc3IISlg4cKY7R0 hc5z0BNC1PvXbydiFQyHy3GSycP9WtHtw5o8ztNAlhYR9adcfO7MBQxysKu9dfyUB5ZM KPV79CF9nrHHhqU2O2nKsW1PL1eG6hQo+FlyKVeyE7iHmKwE0zHoxrozz5shHOkG/qQN lSRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:cc:message-id:date :user-agent:mime-version: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=mATwxIk8b9j+MlY4V3EQvjQw9z4o0y0JGX41w12Qkz4=; b=cccfU3X8sDmKkCIRuZFloXMqAbhB1NjQybnEwFfVt2A845EWLwLhCmoV4m5M5HX/I9 vnRtVWW0tspAGVxLpGT4+HOuIh5KfzoLN2Pj95StTXsPtBfKIWTmKvPfa9XZCqvUzzfP 9X6z6Viaqanl8MeVrJWd5LdB+9B8x3RSbpbXabOZ7eSDvtVEN2SKHp71SZZ5kYNTB/XX Lg1p9mHpTNYCtzbpPB8MbasMtTgfRm/UAUDQToAzsOA2qItiaMZNTcC/RQSHaxvlc1zk kTlu7q2Rym/0mCGrGrhzRoQ7Y0Ya1ZgVPksMSDvm7UsqPtSSs0RMb8IULAx7oJwqe+BG LMYQ== X-Gm-Message-State: AA6/9RlVpVURsVq4CWBDs2E01aDr6dB2/sgQNP1WtHI/5hXodkbWygkAyFpZhWlJtDjzvg== X-Received: by 10.36.50.66 with SMTP id j63mr7928189ita.13.1475676691855; Wed, 05 Oct 2016 07:11:31 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.18.201 with SMTP id g67ls903675otg.26.gmail; Wed, 05 Oct 2016 07:11:31 -0700 (PDT) X-Received: by 10.129.101.132 with SMTP id z126mr6895407ywb.241.1475676691014; Wed, 05 Oct 2016 07:11:31 -0700 (PDT) Original-Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com. [2607:f8b0:400d:c09::236]) by mx.google.com with ESMTPS id 49si10009835uaq.43.2016.10.05.07.11.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Oct 2016 07:11:30 -0700 (PDT) Received-SPF: neutral (google.com: 2607:f8b0:400d:c09::236 is neither permitted nor denied by best guess record for domain of bjarne@stroustrup.com) client-ip=2607:f8b0:400d:c09::236; Original-Received: by mail-qk0-x236.google.com with SMTP id j129so211762002qkd.1 for ; Wed, 05 Oct 2016 07:11:30 -0700 (PDT) X-Received: by 10.55.139.196 with SMTP id n187mr8695446qkd.300.1475676690580; Wed, 05 Oct 2016 07:11:30 -0700 (PDT) Original-Received: from [192.168.10.32] ([138.20.184.130]) by smtp.googlemail.com with ESMTPSA id y55sm4320433qty.23.2016.10.05.07.11.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Oct 2016 07:11:30 -0700 (PDT) In-Reply-To: <201610051238.17863.marc.mutz@kdab.com> X-Original-Sender: bjarne@stroustrup.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@stroustrup-com.20150623.gappssmtp.com; spf=neutral (google.com: 2607:f8b0:400d:c09::236 is neither permitted nor denied by best guess record for domain of bjarne@stroustrup.com) smtp.mailfrom=bjarne@stroustrup.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:28530 Archived-At: I think you overestimate the likelihood for problems and underestimate the convenience offered. The technical points you made were (of course) considered, repeatedly and seriously. Yes, you can accidentally reverse the order of naming, just as you can for function arguments. If the members/arguments are of the same type, the consequences can be very bad. That's why I don't recommend interfaces with multiple consecutive arguments of the same type. You already have the equivalent problems with return types that are pairs and tuples, and if you don't like structured binding, don't use it. That's easier done than the equivalent advice for pairs and tuples. I don't see the problems you outline becoming a major problem, but I do see the convenience as significant. There is always a balance to be struck between safety and convenience. Note that languages with a heavy emphasis on safety tend not to be used for general programming (most programmers don't like them). On 10/5/2016 6:38 AM, Marc Mutz wrote: > Hi Herb, Bjarne, Gabriel, > > 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 > them. > > I strongly believe that the premise that returning std::tuple from functions > to solve the multiple-return-types problem is good practice, is fundamentally > wrong. > > 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. > > 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. > > 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. > > 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. > > Structured Bindings would be acceptable if, like scripting languages, we > didn't have anything else to work with. > > But we do: We can return a struct. > > IMHO, the correct solution to the multiple return value problem is to return a > struct with properly named fields, not a pair and not a tuple. > > 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 > bothered to pick good names for a return struct, and b) tuples can be defined > on the fly, in the function declaration, whereas structs can not. > > I believe there's a proposal for allowing to define structs in function > declarations already, but I failed to find it. > > Consider: > > std::map::insert(...) -> std::pair > > 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 iterator > as a boolean will fail, but what about algorithms that return multiple > iterators? If you get the order wrong, then you have a bug. > > No, map::insert() should have returned a > > struct { iterator iterator; bool inserted; }; > > so one could say: > > if (map.insert(...).inserted) > > or > > auto result = map.insert(...) > if (result.inserted) > > To summarise: I feel that Structured Bindings are too easy to use incorrectly, > 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 > see the pattern to return structs from functions strengthened, not the anti- > pattern of returning pairs and tuples. > > I therefore hope that I can persuade you to reconsider adding Structured > Bindings to C++17. > > Thanks, > Marc > -- 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/38e94531-5370-450f-f33d-331c81d8f91f%40Stroustrup.com. .