220 28542 article Path: news.gmane.org!.POSTED!not-for-mail From: Matt Calabrese Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: A plea to reconsider adding Structured Bindings to language Date: Wed, 5 Oct 2016 16:35:07 -0700 Lines: 93 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=001a1144f170a0f3ec053e26a0b1 X-Trace: blaine.gmane.org 1475710514 26296 195.159.176.226 (5 Oct 2016 23:35:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 5 Oct 2016 23:35:14 +0000 (UTC) Cc: hsutter@microsoft.com, bjarne@stroustrup.com, gdr@microsoft.com To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBCGNLO5F34OBBLE4227QKGQEVCZOXVI@isocpp.org Thu Oct 06 01:35:09 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qt0-f198.google.com ([209.85.216.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1brviN-00064L-F1 for gclcip-std-proposals@m.gmane.org; Thu, 06 Oct 2016 01:35:07 +0200 Original-Received: by mail-qt0-f198.google.com with SMTP id z54sf5109592qtz.0 for ; Wed, 05 Oct 2016 16:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:x-original-sender:x-original-authentication-results :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=nEbkeEMN+OORCrTSVFoIhn6OxX/rq/rfsxdMGWTP7Nk=; b=heiinsV4unxzIf0CdSPLTj7FB9e96R6AwFf+yMyniu7aff0vPsKdRV3LOBTkZEWdmO akClV19PP4+3XgraZLJLEr3i7NXw8PTXj/X8LDhHKnO4vLWyJBy4x/i3BjcprcrfpqXL XSxb5LoQtSzcovoWt08V3CPMHqSV6Y5IA7P0JCnQ939ETysfiuX5C6KQARqq+zmAsF6S IdehGvS4rDdqOWyK0PDPaGTJ+dy7M3iLMBpBaMDZoUJ+jIU0FvJZ0UkpdTQ8TgljlKa1 q4vq2n/BhOfRPMvVG5cKxJmoEkLeXWGt6cO4ya0F/ypZNfiLVhEP+UQo7WcPLtSVIr/N VuxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:x-original-sender :x-original-authentication-results:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=nEbkeEMN+OORCrTSVFoIhn6OxX/rq/rfsxdMGWTP7Nk=; b=kSc+AOOTBGOqVyjNoDNgVzYKjXMH3CRw+NKvGQRiyepkT5EkVHOkO26ee7A9TZzDY9 GqkYDE0+DK+wGLiyUv5BIPlab7YhvjHFTeY4OPZHlm11eBbX3vclD+Wsw8yGvr5/c5k+ Qj+jHxPf/zZLABC5t7geEjB1jcB7yJOpPG/W6SafFCwCgqfgeL60nHecisHlpDo9c+6v THiZyNOI30JK3FbO0sV8EYJUEruxQXlwhSed9B1iwD/yvaOEoX5BNwPLjjXp31Qkcls0 rB4zPwBLHOGeYc3+GNVUYbtpJK/oBThuUolGPxCmHS1fB3+rcIwuhz6jm/Pal2X0OuQD aefg== X-Gm-Message-State: AA6/9Rn3c/fNcOKXGc5xJe9OdukHLzHyVugqh3DUcU4iXA2Zu6V+nShFEm1oHsvgZj4wFg== X-Received: by 10.200.53.22 with SMTP id y22mr522153qtb.58.1475710509226; Wed, 05 Oct 2016 16:35:09 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.39.163 with SMTP id c32ls1836338otb.20.gmail; Wed, 05 Oct 2016 16:35:08 -0700 (PDT) X-Received: by 10.176.2.166 with SMTP id 35mr3355748uah.73.1475710508461; Wed, 05 Oct 2016 16:35:08 -0700 (PDT) Original-Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com. [2607:f8b0:400c:c05::230]) by mx.google.com with ESMTPS id 41si13316035uas.61.2016.10.05.16.35.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Oct 2016 16:35:08 -0700 (PDT) Received-SPF: pass (google.com: domain of calabrese@google.com designates 2607:f8b0:400c:c05::230 as permitted sender) client-ip=2607:f8b0:400c:c05::230; Original-Received: by mail-vk0-x230.google.com with SMTP id y190so2841354vkd.3 for ; Wed, 05 Oct 2016 16:35:08 -0700 (PDT) X-Received: by 10.31.14.136 with SMTP id 130mr3937996vko.77.1475710508116; Wed, 05 Oct 2016 16:35:08 -0700 (PDT) Original-Received: by 10.103.120.149 with HTTP; Wed, 5 Oct 2016 16:35:07 -0700 (PDT) In-Reply-To: <201610051238.17863.marc.mutz@kdab.com> X-Original-Sender: calabrese@x.team X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@x.team; spf=pass (google.com: domain of calabrese@google.com designates 2607:f8b0:400c:c05::230 as permitted sender) smtp.mailfrom=calabrese@google.com; dmarc=pass (p=NONE dis=NONE) header.from=x.team 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:28542 Archived-At: --001a1144f170a0f3ec053e26a0b1 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 5, 2016 at 3:38 AM, Marc Mutz wrote: > > 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. > Hi Marc, People have already addressed your concerns, but you seem to also be missing one of the key, important reasons why tuples are useful to library developers -- specifically, they are necessary when the amount and types of the tuple fields are dependent on template parameters used by a library. In these cases, a library implementor simply *cannot* "create a struct with named members". You are mostly arguing that pairs and tuples are often misused by developers and even by the standard, which is actually a statement that I agree with, however, tuples are still very necessary in generic libraries, and users of those libraries can get a lot of benefit from structured bindings. Structured bindings are also useful not just for tuples, but also for structs, so your argument based on tuple is a bit misguided. For an example of a library that cannot simply create a struct with named members, consider Boost.Spirit, which is not at all unique in this respect. -- 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/CANh8DEnDB0AGhvCCBTpFg1365HxM_6oA2BxDYWb8t6qG4XMDbg%40mail.gmail.com. --001a1144f170a0f3ec053e26a0b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Oct 5, 2016 at 3:38 AM, Marc Mutz <marc.mutz@kdab.com> = wrote:
To summarise: I feel that Structured Bindings are too easy to use incorrect= ly,
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 l= ike to
see the pattern to return structs from functions strengthened, not the anti= -
pattern of returning pairs and tuples.

Hi Ma= rc,

Pe= ople have already addressed your concerns, but you seem to also be missing = one of the key, important reasons why tuples are useful to library develope= rs -- specifically, they are necessary when the amount and types of the tup= le fields are dependent on template parameters used by a library. In these = cases, a library implementor simply *cannot* "create a struct with nam= ed members". You are mostly arguing that pairs and tuples are often mi= sused by developers and even by the standard, which is actually a statement= that I agree with, however, tuples are still very necessary in generic lib= raries, and users of those libraries can get a lot of benefit from structur= ed bindings. Structured bindings are also useful not just for tuples, but a= lso for structs, so your argument based on tuple is a bit misguided.
<= div class=3D"gmail_extra">
For an examp= le of a library that cannot simply create a struct with named members, cons= ider Boost.Spirit, which is not at all unique in this respect.

--
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 htt= ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEnDB0AGhvCC= BTpFg1365HxM_6oA2BxDYWb8t6qG4XMDbg%40mail.gmail.com.
--001a1144f170a0f3ec053e26a0b1-- .