220 28524 <201610051411.30312.marc.mutz@kdab.com> article Path: news.gmane.org!.POSTED!not-for-mail From: Marc Mutz Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: A plea to reconsider adding Structured Bindings to language Date: Wed, 5 Oct 2016 14:11:29 +0200 Organization: KDAB Lines: 80 Approved: news@gmane.org Message-ID: <201610051411.30312.marc.mutz@kdab.com> References: <201610051238.17863.marc.mutz@kdab.com> <201610051300.02280.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="iso-8859-15" Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1475669404 25980 195.159.176.226 (5 Oct 2016 12:10:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 5 Oct 2016 12:10:04 +0000 (UTC) Cc: Bjarne Stroustrup , Gabriel Dos Reis To: std-proposals@isocpp.org, Herb Sutter Original-X-From: std-proposals+bncBCRPXDOU7ECRBBW32O7QKGQEB5HZDXA@isocpp.org Wed Oct 05 14:09:57 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f71.google.com ([209.85.220.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1brl13-000418-9C for gclcip-std-proposals@m.gmane.org; Wed, 05 Oct 2016 14:09:41 +0200 Original-Received: by mail-pa0-f71.google.com with SMTP id bv10sf444914820pad.2 for ; Wed, 05 Oct 2016 05:09:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:organization:to:subject:date:cc :references:in-reply-to:mime-version:content-transfer-encoding :message-id: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=I1RtjIog1JHP755jBx/s4DcVUCZ5GqOUSOXd9zOqyQE=; b=WvXFcJwqJr9snGIQ5Fjy7IDiDp+9994pHY+ZRF5ky199j44WlXmWoiHlz7Gqc8TMJ1 g+qQ3s5uqc1duAF5VqY94W+43kXHVJeLlSpo7V0bMpi0QYAzd9qrgSXUtPeOybYLL2vk 81zhl4zWbgl4eXEL/V5W5DHJDFNH25otgVZwCeZzYfqWxC5bU+kjsrqZ9QQAOpUS4iF3 s/gx1HrYQgcYtQDt+F70AIKIUA8ZDFMtmrvJ5jraVSmVfj/C0Y3pfk58bgvv5q+Q92Rl /bxEI+ae1TXZRMg2BK2jsIGCTgcthamhCGLB9JCQQRxkGTzRdGWtHOIEht X-Gm-Message-State: AA6/9RnTtFstiUzf3H1z4cQNa/WPoohDWz0/B8P+aqt1xbDHk61FN/yDt/WkYtjVZq3T1w== X-Received: by 10.36.156.3 with SMTP id b3mr2388651ite.9.1475669382824; Wed, 05 Oct 2016 05:09:42 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.61.202 with SMTP id l68ls579163otc.1.gmail; Wed, 05 Oct 2016 05:09:42 -0700 (PDT) X-Received: by 10.37.31.196 with SMTP id f187mr6753279ybf.56.1475669382128; Wed, 05 Oct 2016 05:09:42 -0700 (PDT) Original-Received: from mail.kdab.com (mail.kdab.com. [176.9.126.58]) by mx.google.com with ESMTPS id h36si3239823ybi.93.2016.10.05.05.09.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Oct 2016 05:09:42 -0700 (PDT) Received-SPF: pass (google.com: domain of marc.mutz@kdab.com designates 176.9.126.58 as permitted sender) client-ip=176.9.126.58; X-Virus-Scanned: amavisd-new at kdab.com Original-Sender: marc@kdab.com In-Reply-To: X-Original-Sender: marc.mutz@kdab.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of marc.mutz@kdab.com designates 176.9.126.58 as permitted sender) smtp.mailfrom=marc.mutz@kdab.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:28524 Archived-At: On Wednesday 05 October 2016 13:40:20 Domen Vrankar wrote: > > > > 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. > > > > > > Structured bindings work with structs as well. If you think structured > > > bindings mean > > > you must return a tuple, you're mistaken. > > > > Yes, I know that. But if I return a struct with proper names, I don't > > need SB > > to handle it. Indeed, it would be counter-productive to have to find > > names for > > SB if can access the names the implementor chose with C-space in my IDE > > from > > the auto variable that stores the return type. > > So you're saying that returning a structure with error status and result or > multiple results of which you only need one or two (reason being for eg. > cheaper to return all at once - due to for e.g. web service call or complex > processing - than request one by one on need to basis) you would still > prefer dragging the entire structure around giving the feeling that your > code has more dependencies than it actually does? Pattern matching would > probably be better for some cases but it's sometimes nice to have a simpler > tool handy. One of us is not underatanding SB correctly, or I don't understand you. SB stores the whole struct, too, it just defines local aliases to the member of the struct (or tuple, or pair, or ...). > > > > 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 > > > > > > C++ programmers are not idiots. > > > > C++ programmers are humans, though. > > > > We all make mistakes. Even Alex Stepanov did. The art is to not repeat > > them. > > This sounds like an argument for not having templates, pointers, > exceptions, probably even references or any other feature for that matter. No, it sounds like and argument for checking a feature for how easy it is to use correctly (SB: very easy) and how hard it is to use incorrectly (SB: very easy, too), and how much new expressiveness it enables (SB: none(?)). I see references to pattern matching everywhere I look for SB, and maybe PM will add more expressiveness, but then let's wait for PM and not add SB, which does not add enough expressiveness to warrant the drawbacks. SB _is_ touted as a way to paper over APIs that trade in tuples and pairs. And for that, IMHO, it is too large a sword for too small a Gordian Knot. If there are other use- cases, they were notably absent from P0144r2. > I have ideas on where to use this feature but like with all other features > it'd be pretty odd to sprinkle it around the code just because I can and > make odd library apis. Good, poor and all in between designs are already > present so I doubt that this feature will change that too much but I might > be wrong :) And *that* sounds like a call to not pay attention to how a feature can be abused, because you can abuse any feature. :) Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts .