220 28561 <19e2e672-80cf-4f89-8c0c-1515dac7a217@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: RE: A plea to reconsider adding Structured Bindings to language Date: Thu, 6 Oct 2016 10:57:26 -0700 (PDT) Lines: 108 Approved: news@gmane.org Message-ID: <19e2e672-80cf-4f89-8c0c-1515dac7a217@isocpp.org> References: <201610051238.17863.marc.mutz@kdab.com> <201610051908.38951.marc.mutz@kdab.com> <4d4b17a4-270b-4833-b8b8-d0f942e2198b@isocpp.org> <201610061142.06409.marc.mutz@kdab.com> <628a808f-d40c-4912-8e55-0058aeb26e06@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_760_1246758082.1475776646348" X-Trace: blaine.gmane.org 1475776661 13194 195.159.176.226 (6 Oct 2016 17:57:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 6 Oct 2016 17:57:41 +0000 (UTC) Cc: jmckesson@gmail.com, bjarne@stroustrup.com, gdr@microsoft.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBB5B3K7QKGQEQSCKGSI@isocpp.org Thu Oct 06 19:57:36 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f197.google.com ([209.85.223.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bsCvA-0001pL-M2 for gclcip-std-proposals@m.gmane.org; Thu, 06 Oct 2016 19:57:28 +0200 Original-Received: by mail-io0-f197.google.com with SMTP id i4sf5106724ioi.4 for ; Thu, 06 Oct 2016 10:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=J7e4B+v6bjC1Oartpcx5D+DuhA6PDH62nCH5mJvzAek=; b=AoSGBy/phOEUYm98gKjgQeYWwvG14FVZKmx/Kl77dZfa58qevCwP8bCSJtCENVsdh6 ryEqw0qZ6rRza5CFDOFjs9oYfxieNEFNaHzkenUKmF+W2W0jWbqTHXbQhasw/0dQS9Y4 W95x0/GGN6zvwBKjvfGpnt9ttR06MTriTj/OjhkpFFbGLbZK1enWbVGBf3bKYTkyT2xQ nSo7k0WiW9g7P6MReiD30IJRJdr7U/lYD76Wgilnq0ASotro0bENgJud3d0K9MmaUYYl 5UH1ttgRkCc2cn7eBUK03wXkwJJ7ZgRAhmy5A7dswqD965ZvvfieNqp+FlNP3ruPaHKL RiyA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=J7e4B+v6bjC1Oartpcx5D+DuhA6PDH62nCH5mJvzAek=; b=nKt4Q0RMSO9LhKvdrI5Yn6n6j4tbtqKoWIA1ayMRTw2QCrGTluTLLuk7mAluRllyA3 hwZ9/oTazh6AYOmbvmeytBcO2x74CIaJRCj9fOunW98Jy9XrqThdi8eGDub9QP4roTHp synzEgN13VQDBsPOag9OLIOjKD9LSvt87Zjvd2DhKQZ0gwWLbkB0fSeuOcfYSE/IIvUU XwiT46bjNdb7EatK3w0li/bcHYXfN416kaLvV4O633p76gRE8s7yLEu9oAihq2BL2FDP uCNVQberFfhvWPNBPjbEgLKx3fowvavocNfh6hUlC4kNQsVJsw4zeTixq4bo6JQAyhLF HQ0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=J7e4B+v6bjC1Oartpcx5D+DuhA6PDH62nCH5mJvzAek=; b=VJ/hNLnv3X0eHJbWU1v+ElloQON7GyTppsJxSNViLbXjjrik+EBcAyBbJgSjV2Do36 6Ak8e1T163j4OpHwA02qqjn3aV6mU2jFgso5mT9QYh3vyIUYXkqA8Z+l8NLEf464cHZz l6jWYeIA6UNJ5CbZhcL4YkLeKtXwmb8GFKHLFnDA7MJUJHXhFPumoSkewexpFsIwyXwt Sii/XpK4SnmmIAHHe5ak6ZnMd+7GFoAsuqvzHjHmRxWJgGVAAKK/M1iQQYTbJj0ASBb9 O8tE9TeuWZy4RlrULm+F7fIz9Koima1Ru2fKEJ4F/J23+qzpRv7yC7uN5NFgrF7ACJEF kWoA== X-Gm-Message-State: AA6/9RkCKhGCSbub3Wbsuti/bAni0as3fm8xaRj/7dLan8KdWJ9R+my0Y46EJZd2zz4LzQ== X-Received: by 10.36.36.10 with SMTP id f10mr4826942ita.27.1475776650450; Thu, 06 Oct 2016 10:57:30 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.48.1 with SMTP id w1ls1290163iow.4.gmail; Thu, 06 Oct 2016 10:57:27 -0700 (PDT) X-Received: by 10.36.121.78 with SMTP id z75mr217541itc.9.1475776647305; Thu, 06 Oct 2016 10:57:27 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@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:28561 Archived-At: ------=_Part_760_1246758082.1475776646348 Content-Type: multipart/alternative; boundary="----=_Part_761_934834994.1475776646348" ------=_Part_761_934834994.1475776646348 Content-Type: text/plain; charset=UTF-8 On Thursday, October 6, 2016 at 12:22:48 PM UTC-4, Farid Mehrabi wrote: > > My understanding is that from the OP's perspective, built-in tuple or some > similar feature would address broader range of solutions than SB and > involves less burden on the syntax. > The fundamental difference between a "tuple" and a "struct" is that elements of the former don't have names; they only have positions and types. If tuples were built-in, it would simply be a language feature rather than a library feature. So you might be able to access the elements with more natural syntax than `get<0>`, but you'd still be using `0` rather than `name`. The OP isn't talking about built-in tuples; he's talking about making it easier to define one-off structs for MRV returning. What the OP is essentially arguing is that returning objects with named members is always the correct solution to the MRV problem. And given that assumption, there's no point in using structured binding. I find neither of these positions to be particularly compelling. I agree that tuples and pairs can be (have been, and currently are) misused. But there are places where tuples are very appropriate and cannot reasonably be replaced by `structs` (at least, not in any way that is an improvement). Structured binding is extremely useful when used in tandem with tuples of that sort. And the fact that a tool can be misused cannot by itself override the good that this tool can do. Will structured binding make people use tuple types in places where a genuine struct would be more appropriate? Yes. But it encourages plenty of appropriate tuple use as well. And even if we do get unnamed struct returning, we *will still use* structured binding to catch those multiple return values. But at the same time, lack of multiple return is an obstacle against proper > use of ranges in 'for' loops. Am I correct? > -- 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/19e2e672-80cf-4f89-8c0c-1515dac7a217%40isocpp.org. ------=_Part_761_934834994.1475776646348 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thursday, October 6, 2016 at 12:22:48 PM UTC-4, Farid M= ehrabi wrote:
=
My understanding is that from the OP's perspective, built-in tuple = or some similar feature would address broader range of solutions than SB an= d involves less burden on the syntax.

The = fundamental difference between a "tuple" and a "struct"= is that elements of the former don't have names; they only have positi= ons and types. If tuples were built-in, it would simply be a language featu= re rather than a library feature. So you might be able to access the elemen= ts with more natural syntax than `get<0>`, but you'd still be usi= ng `0` rather than `name`. The OP isn't talking about built-in tuples; = he's talking about making it easier to define one-off structs for MRV r= eturning.

What the OP is essentially arguing is that returning objec= ts with named members is always the correct solution to the MRV problem. An= d given that assumption, there's no point in using structured binding.<= br>
I find neither of these positions to be particularly compelling. I a= gree that tuples and pairs can be (have been, and currently are) misused. B= ut there are places where tuples are very appropriate and cannot reasonably= be replaced by `structs` (at least, not in any way that is an improvement)= .. Structured binding is extremely useful when used in tandem with tuples of= that sort. And the fact that a tool can be misused cannot by itself overri= de the good that this tool can do.

Will structured binding make peop= le use tuple types in places where a genuine struct would be more appropria= te? Yes. But it encourages plenty of appropriate tuple use as well. And eve= n if we do get unnamed struct returning, we will still use structure= d binding to catch those multiple return values.

But at the same time,= lack of multiple return is an obstacle against proper use of ranges in = 9;for' loops. Am I correct?

--
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 https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/19e2e672-80cf-4f89-8c0c-1515dac7a217= %40isocpp.org.
------=_Part_761_934834994.1475776646348-- ------=_Part_760_1246758082.1475776646348-- .