220 11741 article Path: news.gmane.org!not-for-mail From: Ville Voutilainen Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: N4078: Rvalue reference overloads for value() method returns object by value Date: Wed, 9 Jul 2014 20:51:10 +0300 Lines: 134 Approved: news@gmane.org Message-ID: References: <764569c3-b26b-4938-970e-44a4681de132@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1404928285 19068 80.91.229.3 (9 Jul 2014 17:51:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Jul 2014 17:51:25 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC5JHI7A7ALRBDUC62OQKGQEA7B7AVY@isocpp.org Wed Jul 09 19:51:19 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f198.google.com ([209.85.192.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X4w1Q-0007TJ-Os for gclcip-std-proposals@m.gmane.org; Wed, 09 Jul 2014 19:51:13 +0200 Original-Received: by mail-pd0-f198.google.com with SMTP id y10sf48573219pdj.1 for ; Wed, 09 Jul 2014 10:51:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type:content-transfer-encoding; bh=IaA7STIjBlm0TiCPpAhGwPmVU+0ZWs2f87AMNhe2wx4=; b=k+9W45iaUXn6mKUXiGL17zZGAVD4QY1ZlcUzR8vprLwqivEbI0T3ySROzqXgrgKrUy DoZnojZFVYDwxLfDW7+WlL3BcPCYuR7wxFC4F9FOsy+yy6fgZVIZXnqZg5JjwYbErwwu +NleBijtTGUoz5YpKc1XdtfaV/lvJqZnIo6gOL3L3bPtLdS+iqvRJWpgtJ6T13aFnEDK RmfankyfeWNrsLFCI30lBLDwQciPKawroMPETYJ4tW9W5wo0ZohqcqrNLtLVgiaK/9Fb xDY5ljx7D/9Pee1Pe4ykirKrELowUoZ6CkxFMcHqLZvXe6vPeyTytRL7+iCc21rfh1r+ sk2g== X-Gm-Message-State: ALoCoQlfhNZjX6zLNpLURmEUxuS+AP46Y0FC7bwLULzGm1QtkH61M5ivFhbsy4fJtD6Bb/DzI9C2 X-Received: by 10.66.102.9 with SMTP id fk9mr19163463pab.2.1404928271633; Wed, 09 Jul 2014 10:51:11 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.109.162 with SMTP id l31ls184693qgf.83.gmail; Wed, 09 Jul 2014 10:51:10 -0700 (PDT) X-Received: by 10.229.13.134 with SMTP id c6mr69723075qca.13.1404928270816; Wed, 09 Jul 2014 10:51:10 -0700 (PDT) Original-Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [2607:f8b0:400d:c00::22e]) by mx.google.com with ESMTPS id y35si7702383qgd.28.2014.07.09.10.51.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Jul 2014 10:51:10 -0700 (PDT) Received-SPF: pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400d:c00::22e as permitted sender) client-ip=2607:f8b0:400d:c00::22e; Original-Received: by mail-qa0-f46.google.com with SMTP id v10so1752429qac.5 for ; Wed, 09 Jul 2014 10:51:10 -0700 (PDT) X-Received: by 10.229.252.130 with SMTP id mw2mr69804721qcb.12.1404928270505; Wed, 09 Jul 2014 10:51:10 -0700 (PDT) Original-Received: by 10.224.31.137 with HTTP; Wed, 9 Jul 2014 10:51:10 -0700 (PDT) In-Reply-To: <764569c3-b26b-4938-970e-44a4681de132@isocpp.org> X-Original-Sender: ville.voutilainen@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400d:c00::22e as permitted sender) smtp.mail=ville.voutilainen@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:11741 Archived-At: On 9 July 2014 14:21, Andrzej Krzemie=C5=84ski wrote: > > > W dniu sobota, 5 lipca 2014 22:52:06 UTC+2 u=C5=BCytkownik anna.s...@gmai= l.com > napisa=C5=82: >> >> In the paper N4078 two Rvalue reference overloads was added to the >> optional class: >> constexpr T value() &&; >> constexpr T value() const&& >> I think this overloads should return by r-value reference instead. >> constexpr T&& value() &&; >> >> I am not aware of any other motivation for this change, please post if >> other one exists. >> Lets begin with the motivation for current desing. As far as I know this >> was introduced to make >> following code well-behaved: >> optional f(); >> auto&& s =3D f().value(); //this code creates a dangling reference if = we >> would return by reference >> I don think making this well-behaved makes more harm that good. It adds >> single exceptional class >> int the langugage for which such code is well behaved. For example if we >> write very similiar code >> with a vector or std::tuple, this code wil still create a dangling >> reference. >> std::vector f(); >> auto&& s =3D f.front(); //dangling reference >> std::tuple g(); >> auto&& s =3D get<0>(g()); //this is emulation of expected or >> optional with tuple >> So the standard library is not consistent with the behaviour, and even i= f >> we fix every getter method >> in the standard by adding rvalue overload, the problem still won't be >> fixed without changing language >> in case of the members: >> std::pair g(); >> auto&& s =3D g().first; //will create a dangling reference >> >> So to summarize: >> Now we have single class in the standard that provides the rvalue >> reference overload for getter method >> and make the auto&& s =3D f().value() well defined. But this is not and >> cannot be uniformly applied to >> the rest of the language (because of member access). This in my opinion >> makes language more complicated >> and leave the programmer with two options: >> - remember this special case and apply them when possible >> - ignore existence of this overloads >> >> In addition the current desings introduces preformance impact on the cod= e. >> Let assume following: >> optional f(); >> void g(const T&);o >> >> vector vt; vt.emplace_back(f.value()); >> g(f().value()); >> This following two lines will now introduce additional >> move-construction o value of type T. >> Someone may argue that this cost is not large becase move are cheap >> (for example std::string). But in the working codebase that >> is a lot of legacy classes that are not move-constructible and this >> will introduce additional unecessary cost. Of course this >> problem does not exists for tuple or pairs. >> >> In my opinion it would be better to delcaret this functions as returning >> reference because it will make it consistent with rest of the language >> and by doing it will make it easier to use and understand. > > > The only motivation for returning by value -- to the best of my knowledge= -- > is the avoidance of dangling references in certain cases. My understandin= g > is that LEWG preferred these to return by value, even at the expense of > incurring run-time overhead. My personal motivation was to minimize the > controversy with LEWG and increasing the chances of getting the proposal > through. (Rvalue ref overloads returning by value are better than no rval= ue > ref overloads.) > > I hope LEWG members are reading this list and can shed some more light on > this question. The understanding of both of you is correct; I personally pointed out the potential problem with dangling references in rvalue cases, and LEWG portrayed (not very strong) preference to having these functions return by value. I think it would be fair to consider a wider-scope fix. I doubt such a change would get accepted to the standard library at large. Adding it to the issues-to-consider for a next-gen standard library would be a good idea. I also think it would be sane to consider some sort of a language feature to return a reference for an lvalue object and a value for an rvalue object, semi-automatically. I suppose it would be a possible idea to extend the language to know more precisely whether the context of the returned object is something that can lead into a dangling case or not. I think the point about emplace for a legacy type moving twice, and that move actually being a copy, is a decent thing to consider. Thus far we're in a Technical Specification going out for its first ballot round, so there's time to fix things, if the committee so chooses. I personally have no quantification about whether optional rvalues are common enough to justify the inconsistency with the other parts of the library, or whether accessing subobjects of such rvalues by references happen often or at all. The change was a judgment call rather than a change backed by strong data, I must admit. --=20 ---=20 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 e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. .