220 34167 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Idea: Extension of structured bindings to definition of structs Date: Sun, 27 Aug 2017 07:11:03 -0700 (PDT) Lines: 192 Approved: news@gmane.org Message-ID: References: <59dcbbbc-c536-4b7b-9c88-0638fb0cd58a@technion.ac.il> <7b9bf263-d3ca-42bf-aed6-4c7606782a28@isocpp.org> <1762295.OciJaA9sdk@tjmaciei-mobl1> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5391_811571578.1503843063950" X-Trace: blaine.gmane.org 1503843082 30841 195.159.176.226 (27 Aug 2017 14:11:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 27 Aug 2017 14:11:22 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB6NFRPGQKGQEVI4V6ZA@isocpp.org Sun Aug 27 16:11:16 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f71.google.com ([74.125.83.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dlyHE-0006sY-EF for gclcip-std-proposals@m.gmane.org; Sun, 27 Aug 2017 16:11:00 +0200 Original-Received: by mail-pg0-f71.google.com with SMTP id q16sf31715706pgc.7 for ; Sun, 27 Aug 2017 07:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=temrFl0g15Mh7gaXJT5lARid6I3gOJEEK2kuMTHX2S8=; b=x9boozHF//JjHzTOg7fZQT3/qv9P6RcM5WRAQpqqaiogBrL5+MCoHhrrJcSmui+Q67 FaJL8OJQqy1DR4sDiGabPfm3lCnYs8CAJ3uyWOHqdlY8f/iD450+Yp2nzwFw4zNKfqeM wSUvWhhJKzpHOdknWSnQ+fPKVfoQCrcxwW0+5FjmhTnWXD0vrqg25h0Umdbvxb3tzawJ 3o5bBDTLcUxF2TCNDLY6jlr2m0t6mwyObJNu5/pJiTa4W/ekXiWvPU3juic3d2KAwoTb LoT95DXnX9FljD9D2Oh9TJnEKgnRoZAxk2qsei/CEQR1UDuq6yqUZdoApeopscsybtMo /UfA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=temrFl0g15Mh7gaXJT5lARid6I3gOJEEK2kuMTHX2S8=; b=aaVDPcQLor3c8Xw60q6OaY5X03WsJOtNi8tU2lfBNGjQuJl5gzBLYkj+ZHX35SyYX8 ++6XbQvoUF5yaTnzfggsBaoMJFzmDQ4USk1kBsYt77eovoiZ6iakHlJ2Z7LBxIP9oVDa GhuLIxP2xg0Mnw9gf18CGBciAgFuFcVj2XVWID8OhswFvGkycVd5bBgp7jyTnPZP1cuo G8r3Jm8ARgyBV4kvfJIvMTqzsszDLZpgYt5RW/AaWwxfjCUtwX4WrQv2rw6vjdnfN4C2 ESqwNO3K0/R15+86WshrV8U1FSRWF+9MBfgqUV9W4nltukbiass0RMTBIEcq4ZgFTIKt QZsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to: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=temrFl0g15Mh7gaXJT5lARid6I3gOJEEK2kuMTHX2S8=; b=Yz4ZINwtx5+eEQdKiF+6ujmSjvWb1TUcrUbXgwYx2qPxjACx8+iagrGQSe5zB5YVvT fwLPPy8HoDECk+boa9tHbECyx/Q/02eDMT+M3gwe7rjcEGW5woM+5yjT+cQVA0rDG7ko ssnfNUEQhBoAE/EA20FXpMO2tvbs4vEz7MwRwrHgaNRwO5LV/Tw854f6i5ZHUi/Y4wSa KV4+QeHPIOJL7uUKCCSf5iZDajeaej4Rog/92cwc1Mio3dufzgddrlG5uxWe+2px7iA5 p3uK1vGPgYOV5Qf8pSI0SlWuWe00zP4J3cbNrsF+pswGFWl3MccOPeQAG026nrt9fn5j NsbQ== X-Gm-Message-State: AHYfb5jVdPzDFBxo2rZzcSU6/bi9e2AKOGXIN50HeL0QpwhLlquZtTa4 57obb+fk8m5Eirgl X-Received: by 10.98.252.205 with SMTP id e196mr833496pfh.2.1503843066399; Sun, 27 Aug 2017 07:11:06 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.39.193 with SMTP id n184ls7750393ion.24.gmail; Sun, 27 Aug 2017 07:11:04 -0700 (PDT) X-Received: by 10.31.227.3 with SMTP id a3mr64135vkh.2.1503843064478; Sun, 27 Aug 2017 07:11:04 -0700 (PDT) In-Reply-To: <1762295.OciJaA9sdk@tjmaciei-mobl1> 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:34167 Archived-At: ------=_Part_5391_811571578.1503843063950 Content-Type: multipart/alternative; boundary="----=_Part_5392_626713149.1503843063950" ------=_Part_5392_626713149.1503843063950 Content-Type: text/plain; charset="UTF-8" On Sunday, August 27, 2017 at 12:11:13 AM UTC-4, Thiago Macieira wrote: > > On Saturday, 26 August 2017 18:08:11 PDT Nicol Bolas wrote: > > I have a tuple. Why would I not just *use the tuple*? > > Because tuples are horrible. From > https://www.kdab.com/tuple-pair-cpp-apis/ > > "Quick: When you design C++ APIs, when and how should you use pair and > tuple? > The answer is as simple as it is surprising: Never. Ever." > > And yet some people will. So when interacting with those API, you need to > "correct" it with proper names. > OK, the problem with tuples in APIs, as outlined in that post, is that they lack any semantic information. They have no meaningful variable names, and they have no meaningful type names. If I'm using an API that uses tuples to the extent that it becomes difficult to understand the code when actually using a tuple, why would I be using an *unnamed* struct to solve this? Would it not make more sense to do this: struct RealName { RealName(const std::tuple &); int a_member; double other_member; }; And then in the actual function: RealName s = std::make_tuple(1, 2.3); This improves code reuse, since `RealName` can be used in multiple places. It improves readability, since `RealName` would convey semantic information about the collection of values that `decltype(s)` cannot. And so forth. The trivial repetition of typing the type names in two (or even three) places in `RealName` will be meaningless next to how often `RealName` is used. Presumably, the reason I'm *not* using structured binding is because I want to pass the collection `s` around to other people, yes? Otherwise, you would just use structured binding to provide the semantic info. Given that this is the case, we need a proper name so that we understand what this aggregate actually means. If this is a one-off case, where you're only calling one function that has a `tuple` API in one place... why are you creating an object for the values at all? If it's a one-off, use structured binding, or just tough-through the `get<>` interface for that one function. What circumstances would I be in where I would be writing an *inline struct* to convert this object? If it happens frequently enough to obfuscate my code, the best solution is a named struct. If it's not that frequent, just use structured binding or the actual return value. -- 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/ff2ceb41-caca-4659-9a7d-4da9c2046810%40isocpp.org. ------=_Part_5392_626713149.1503843063950 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sunday, August 27, 2017 at 12:11:13 AM UTC-4, Thiago Ma= cieira wrote:
On Saturday, 26 A= ugust 2017 18:08:11 PDT Nicol Bolas wrote:
> I have a tuple. Why would I not just *use the tuple*?

Because tuples are horrible. From
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.kdab.com/tuple-pair-cpp-apis/

"Quick: When you design C++ APIs, when and how should you use pair= and tuple?
The answer is as simple as it is surprising: Never. Ever."

And yet some people will. So when interacting with those API, you need = to=20
"correct" it with proper names.

OK, the problem with tuples in APIs, as outlined = in that post, is that they lack any semantic information. They have no mean= ingful variable names, and they have no meaningful type names.

If I&= #39;m using an API that uses tuples to the extent that it becomes difficult= to understand the code when actually using a tuple, why would I be using a= n unnamed struct to solve this? Would it not make more sense to do t= his:

struct= RealName<= /span>
= {
=C2=A0 RealName(const std::tuple<int, double> &);

=C2=A0 int a_member;
=C2=A0 double other_member;
};

And then in the actual function= :

RealName s =3D std::make_tuple(1, 2.3);

This improves code reuse, since `RealN= ame` can be used in multiple places. It improves readability, since `RealNa= me` would convey semantic information about the collection of values that `= decltype(s)` cannot. And so forth. The trivial repetition of typing the typ= e names in two (or even three) places in `RealName` will be meaningless nex= t to how often `RealName` is used.

Presumably, the reason I'm not using structured binding is because I want to pass the collection = `s` around to other people, yes? Otherwise, you would just use structured b= inding to provide the semantic info. Given that this is the case, we need a= proper name so that we understand what this aggregate actually means.
<= br>If this is a one-off case, where you're only calling one function th= at has a `tuple` API in one place... why are you creating an object for the= values at all? If it's a one-off, use structured binding, or just toug= h-through the `get<>` interface for that one function.

What ci= rcumstances would I be in where I would be writing an inline struct = to convert this object? If it happens frequently enough to obfuscate my cod= e, the best solution is a named struct. If it's not that frequent, just= use structured binding or the actual return value.

--
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/ff2ceb41-caca-4659-9a7d-4da9c2046810= %40isocpp.org.
------=_Part_5392_626713149.1503843063950-- ------=_Part_5391_811571578.1503843063950-- .