220 28538 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: A plea to reconsider adding Structured Bindings to language Date: Wed, 5 Oct 2016 09:14:44 -0700 (PDT) Lines: 269 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/mixed; boundary="----=_Part_457_1638641246.1475684084162" X-Trace: blaine.gmane.org 1475684118 6577 195.159.176.226 (5 Oct 2016 16:15:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 5 Oct 2016 16:15:18 +0000 (UTC) Cc: hsutter@microsoft.com, bjarne@stroustrup.com, gdr@microsoft.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB6GN2S7QKGQEIA3OMXA@isocpp.org Wed Oct 05 18:15:10 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f198.google.com ([209.85.192.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1broqK-00072o-3E for gclcip-std-proposals@m.gmane.org; Wed, 05 Oct 2016 18:14:52 +0200 Original-Received: by mail-pf0-f198.google.com with SMTP id 7sf349503535pfa.2 for ; Wed, 05 Oct 2016 09:14:54 -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=SllbPMrdztwCsqzTl0Ri18fkBkrf2huOk/lj1nsDWlM=; b=gb0tBUi8mR+H+i17JjCpsjXQzJh7Qi24NHjjDO3AaZw2jYa07wdrGSvzlgXFOiNwTG HiyUo5i3w62/1Ju7L1R1YMpm1nv4yEvzt8WTLeXZb9WsuCVpt7y3HXzM2dvqkmfVdUpX HKvJhObYxXBnHJQ8Kx2/lfEbrRce+a35kbBuVCfPUM7d4eIaTR+2iN+wmgulodMjaqd6 0XrY0nTPCe6dRQCvMpLqhDQvc0kZV4in6VMysU2au9S8K/n9iRpb98DSzqrBadvOij3X 8jSPDRj2fUJiLKN2AAQsOOn9q1JATpZLVAuuXCE2gsaJH8Zh3KztTrZrse7DG/GNBAV7 AoJg== 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=SllbPMrdztwCsqzTl0Ri18fkBkrf2huOk/lj1nsDWlM=; b=TvwHoijEa1ceiXBGeVetFZ03PHdZLdBlyarsNQqUE5W8CRVlvkTK1sMmDWXY31+ml4 KMnOSFYDVeWM+xcyor4PN9mlli0XLP8ereyVbmnpNFNFAHKrlivdHrX0apVUVl47aRcY OofQe78YsVyHCWii12UNKcQ9Op4jUPwOFa4R16Z//66rit30DAf5mGZQCwgZgyCv+t+K gfn/OzWmO7PHmufN5k2niiJd7L7Eq287gDRQwrplbKNDK/i4P+MS/864RTeH2LpmEPKF 9ThTo1LW29vgx8SF+QcCc7xljWy82STRXSdGiEOUS75wMiUz3cVBb9R3Wj8gMNIiw+Jo 92Cg== 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=SllbPMrdztwCsqzTl0Ri18fkBkrf2huOk/lj1nsDWlM=; b=h24xRThYeKe1WpaHdfiDcs5b1yIdFrXncMP2Q0pOtLh7bNMO1QXe6AqVv7bUNT5941 YhpFGejcs910m4rjVMr2SlB9pGyitTxVurP3GjghCSgkBdxXpns4GbnjLQw0bN6tZ7fI BkDJLVmJl2xiLevsqJLLvDsBnd0oIkYF4Usl/vWIX7Mf1/yOS1ICmGvzLT8IgQCRQJr/ 6XaR8fNmtqJthAVm2M2UYYrU7lkim0Recfs14O6oQ8eFP69Z8oJzSi9mSZTyGwzvT1J/ lhdLGgf43Swbm7oZbkjlFREoyy9ZFQSNQ0h5IkDXnGSTz01HTDR4yUfUer9m8scy3Md8 9wMg== X-Gm-Message-State: AA6/9RlkAJ1TIfq1TfQeNPHoVqaadCOYhleanVJo4W9t4Fd9HXOD/a70FajqeQG5TowLmQ== X-Received: by 10.107.150.133 with SMTP id y127mr2748457iod.7.1475684093528; Wed, 05 Oct 2016 09:14:53 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.205.13 with SMTP id d13ls384576iog.8.gmail; Wed, 05 Oct 2016 09:14:45 -0700 (PDT) X-Received: by 10.36.124.195 with SMTP id a186mr381636itd.7.1475684085333; Wed, 05 Oct 2016 09:14:45 -0700 (PDT) In-Reply-To: <201610051238.17863.marc.mutz@kdab.com> 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:28538 Archived-At: ------=_Part_457_1638641246.1475684084162 Content-Type: multipart/alternative; boundary="----=_Part_458_187217477.1475684084163" ------=_Part_458_187217477.1475684084163 Content-Type: text/plain; charset=UTF-8 On Wednesday, October 5, 2016 at 6:36:35 AM UTC-4, 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 binding is hardly the first C++ feature that makes struct field ordering important. Aggregate initialization did that long before. If you "reorder fields to fill padding holes" on an interface structure, then you've broken any code that used aggregate initialization on that type. Now yes, you can fix that by giving that type constructors that mimic the previous ordering. But then again, you can fix similar changes with structured binding by giving that type `tuple_size`/etc functions that mimic the previous ordering as well. So in both cases, we have the tools to make such changes backwards compatibly. Structs are *ordered* collections of named objects. Ordering is a fundamental part of a struct, and structured binding is not the only C++ feature that relies on the order of a struct's members. 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. > Then let us consider the question of "properly named fields". "Properly named" *for whom*, exactly? The function returns values that have some meaning. But the caller gives those values added meaning as well. Consider your `map::insert` code, where you return a struct of two values. One is called "inserted" and the other is called "iterator". Well... what does "iterator" *mean*? To `map::insert`, it merely means the iterator where the item is inserted. But that item that was inserted has a semantic meaning to the caller of `map::insert`. Therefore, the iterator where that item was inserted also has a semantic meaning: the position of that item. A meaning which is not reflected in the generic "result.iterator" name you give it. This means that the person reading the calling code has to remember what `map::insert` returns, as well as the semantic meaning of what was passed to `map::insert`. Structured binding allows the calling code to impose semantic meaning to such things. Meaning that the function returning those values cannot possibly know about. At its core, this is no different from the ability of functions to give names to parameters. The caller passes some object that often has a name. But to the context of the function being called, that object has a semantic meaning which is different from the one the caller gave it. So the function gets to give it a meaning which expresses the intent of the code being called, rather than the intent of the caller. Why should function return values be any different? The called function gives these return values one meaning, and the caller can alter that meaning based on its needs. 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. > It's P0222 . If you read that proposal however, one of its primary motivations is to work *in tandem with* structured bindings. It was not designed to work against it, but alongside it. The idea being that the member names which the anonymous struct uses would be self-documenting as to their meaning. But the caller can still impose their own semantic meaning via structured binding, as they see fit. And that proposal sees as perfectly legitimate. So returning anonymous structs is not a replacement for structured binding. We'd still want structured binding even if we could return anonymous structs. -- 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/adffa9c0-2c7a-4d98-8fc3-2e787109b858%40isocpp.org. ------=_Part_458_187217477.1475684084163 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wednesday, October 5, 2016 at 6:36:35 AM UTC-4, Marc Mu= tz wrote:
Hi Herb, Bjarne, Gabr= iel,

I heard about Structured Bindings for the first time at CppCon this yea= r, and=20
I'd like to raise my concerns, esp. since half of the panel was cra= zy about=20
them.

I strongly believe that the premise that returning std::tuple from func= tions=20
to solve the multiple-return-types problem is good practice, is fundame= ntally=20
wrong.

It is not good in any sense of the word. It is horrible. Indeed, it is = so=20
horrible that you felt inclined to add a new language feature just to m= ake it=20
bearable.

The reaons it's horrible, is because it reverses the C++ principle = that the=20
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=20
values returned, when it should be the implementor of the function who = chooses=20
the names.

In conjunction with auto deduction, the caller choosing the names means= that=20
the code becomes brittle in the face of changes to the return type, e.g= .. when=20
reordering fields to fill padding holes.

Struc= tured binding is hardly the first C++ feature that makes struct field order= ing important. Aggregate initialization did that long before. If you "= reorder fields to fill padding holes" on an interface structure, then = you've broken any code that used aggregate initialization on that type.=

Now yes, you can fix that by giving that type constructors that mim= ic the previous ordering. But then again, you can fix similar changes with = structured binding by giving that type `tuple_size`/etc functions that mimi= c the previous ordering as well. So in both cases, we have the tools to mak= e such changes backwards compatibly.

Structs are ordered coll= ections of named objects. Ordering is a fundamental part of a struct, and s= tructured binding is not the only C++ feature that relies on the order of a= struct's members.

Structured Bindings would be acceptable if, like scripting languages, we=20
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 r= eturn a=20
struct with properly named fields, not a pair and not a tuple.

Then let us consider the question of "properly named = fields". "Properly named" for whom, exactly?

T= he function returns values that have some meaning. But the caller gives tho= se values added meaning as well. Consider your `map::insert` code, where yo= u return a struct of two values. One is called "inserted" and the= other is called "iterator".

Well... what does "itera= tor" mean? To `map::insert`, it merely means the iterator where= the item is inserted. But that item that was inserted has a semantic meani= ng to the caller of `map::insert`. Therefore, the iterator where that item = was inserted also has a semantic meaning: the position of that item.
A meaning which is not reflected in the generic "result.iterator"= ; name you give it. This means that the person reading the calling code has= to remember what `map::insert` returns, as well as the semantic meaning of= what was passed to `map::insert`.

Structured binding allows the cal= ling code to impose semantic meaning to such things. Meaning that the funct= ion returning those values cannot possibly know about.

At its core, = this is no different from the ability of functions to give names to paramet= ers. The caller passes some object that often has a name. But to the contex= t of the function being called, that object has a semantic meaning which is= different from the one the caller gave it. So the function gets to give it= a meaning which expresses the intent of the code being called, rather than= the intent of the caller.

Why should function return values be any = different? The called function gives these return values one meaning, and t= he caller can alter that meaning based on its needs.

I fear Structured Bindings will lead to an explosion of *really* bad API th= at=20
returns std::pair or std::tuple when it should return a small struct wi= th=20
well-named data members instead, because a) the implementor couldn'= t be=20
bothered to pick good names for a return struct, and b) tuples can be d= efined=20
on the fly, in the function declaration, whereas structs can not.

I believe there's a proposal for allowing to define structs in func= tion=20
declarations already, but I failed to find it.
It's P0222. If you read that pr= oposal however, one of its primary motivations is to work in tandem with= structured bindings. It was not designed to work against it, but along= side it.

The idea being that the member names which the anonymous st= ruct uses would be self-documenting as to their meaning. But the caller can= still impose their own semantic meaning via structured binding, as they se= e fit. And that proposal sees as perfectly legitimate.

So returning = anonymous structs is not a replacement for structured binding. We'd sti= ll want structured binding even if we could return anonymous structs.
=

--
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/adffa9c0-2c7a-4d98-8fc3-2e787109b858= %40isocpp.org.
------=_Part_458_187217477.1475684084163-- ------=_Part_457_1638641246.1475684084162-- .