220 11897 <14c69772-862c-47c9-b97a-7743cd873147@isocpp.org> article Path: news.gmane.org!not-for-mail From: tomaszkam@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: N4078: Rvalue reference overloads for value() method returns object by value Date: Sat, 12 Jul 2014 10:23:24 -0700 (PDT) Lines: 134 Approved: news@gmane.org Message-ID: <14c69772-862c-47c9-b97a-7743cd873147@isocpp.org> References: <4DA018C3-2327-4F55-B7F8-7988EC7B789A@gmail.com> <1a858a77-310b-4591-aaf5-960c40d9f5fc@isocpp.org> <66AF41C1-CB37-4311-98EA-D47DBC6068DC@gmail.com> <66c38b61-7a95-4ace-b34f-2346bb334fb9@isocpp.org> <6F4B3C72-9962-48DC-8527-0C89EA1B9710@gmail.com> <35873CE5-ED8C-4C03-A6A1-E4132DECD91F@gmail.com> <335948E6-8140-4673-B958-930356A52070@gmail.com> <76ACA175-5A44-4BE8-B49F-BAC6DA65E6B1@gmail.com> <4D3852AD-1AEB-44BA-941C-D645BAD19405@gmail.com> <6a4b6425-1167-40c1-acd8-3945c8cd4c74@isocpp.org> <13DD0D7A-A146-4667-9F30-6FB3739CDBE0@gmail.com> <6B925FF7-2940-44C7-BF1D-13209A703BA2@gmail.com> <944C9C01-865B-4215-8C91-95F01AEA256E@gmail.com> <8DC3E474-3957-40B2-B492-D4AF2FDDD451@gmail.com> <0ACAE525-4FB2-4932-BBD2-F0623C4EBBFB@gmail.com> <52187852-ff8e-4e59-a8cf-7a29fd0a405b@isocpp.org> <8209A2E9-D947-4C00-A1F3-38F5676A4E52@gmail.com> <4c42f7c9-0588-4ab9-9af5-b2e692513993@isocpp.org> <225BBAAC-B3FA-4014-9FB6-64C48DF4208E@gmail.com> <1b70888c-eb6a-49e5-b254-a475ef015570@isocpp.org> <6CFC366C-D196-4A2E-B4EE-D1E6B26AE6C0@gmail.com> <3baba983-4d62-4887-a969-020ecf027a45@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_136_28872460.1405185804717" X-Trace: ger.gmane.org 1405185816 4303 80.91.229.3 (12 Jul 2014 17:23:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Jul 2014 17:23:36 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDNPVXXG6IGBBDO6QWPAKGQEY3RFAKY@isocpp.org Sat Jul 12 19:23:28 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yh0-f72.google.com ([209.85.213.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X611D-0001kK-U5 for gclcip-std-proposals@m.gmane.org; Sat, 12 Jul 2014 19:23:28 +0200 Original-Received: by mail-yh0-f72.google.com with SMTP id f73sf9497082yha.3 for ; Sat, 12 Jul 2014 10:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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 :content-type; bh=EW2vrFEK6p4WMe23LcwAXso9SAreqCDq8WDse/U/1xE=; b=EVJy8zxy72UgrP9MAJgxgCKKGSBO5y+tvbFqaF8JdIzNQIo1CzOqCwUfThCCXHAxjk T3WIKQRzqboPh/q6IVT1TdxSshagpRbG1Bi5UutK6ZWOs5aad+91r3ijlFshA8s3lmTc P8JvwiXLcsSk1/dLIJwnTaOt0P07eqktdkZd9Vg1XSeRAau8gdXe+WmStyrpU9QCI/uH 9Ln3Wh1z9N8hvq452iPSGAeGtHx5B5I27+QqszpE5EaRd+wxrVbSA3fQF+0ndQuFNf+F CA3cFJ2VUf5+a3jNZ6+xNuu4FZRn+t/5JKchN60bXnqSRvX5I8+nBbKPiV1olg4OsVL+ +U8g== 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: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:content-type; bh=EW2vrFEK6p4WMe23LcwAXso9SAreqCDq8WDse/U/1xE=; b=azWaEI+mPBwp58zuIvosEI4dS88rJuCJnX9Ww+x7HNM1QMmEbD1KC87p51gEWMVnW/ HieyBkHtLlnKala0cx6F6goJaFMp0HLrIoJXV7uTejUxt914vhMMda4jrl69nLjpOQom s/AZ0cGvRF0MqenSfQi8F5em6QV1IZNppXbR21tu26OwszTWj4g8ATPhUBBNlLJNGCFU /TZZoAG0R2CevyK5o5xAXuCFZDOWBz0zjaCZqMjiwO3miroHovuoGz91AzHAen/nJpiZ tFLj6p6JbFwgp29lCmd0o63JTPuF816sC3eKff3EK5UoNKmz2iXLM5F5AIdzyP7AVDur uWZg== X-Gm-Message-State: ALoCoQlscv5nvnEbED8OSd1fQ5o7nu5/zm9lO/vBg+gWJ6Z4+CF635EcNDEj3hIr3QCgFJCPgKI+ X-Received: by 10.58.1.133 with SMTP id 5mr2787412vem.32.1405185806701; Sat, 12 Jul 2014 10:23:26 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.55.98 with SMTP id r2ls740759obp.77.gmail; Sat, 12 Jul 2014 10:23:25 -0700 (PDT) X-Received: by 10.182.3.2 with SMTP id 2mr40442oby.10.1405185805665; Sat, 12 Jul 2014 10:23:25 -0700 (PDT) In-Reply-To: X-Original-Sender: tomaszkam@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:11897 Archived-At: ------=_Part_136_28872460.1405185804717 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable W dniu sobota, 12 lipca 2014 17:24:03 UTC+2 u=C5=BCytkownik David Krauss na= pisa=C5=82: > > > On 2014=E2=80=9307=E2=80=9312, at 8:57 PM, toma...@gmail.com wrote: > > This will introduce a lot of temporaries in the code.=20 > > > Most code tends to have a lot of temporaries anyway. Temporaries are a=20 > product of value semantics, as opposed to reference semantics. Since rval= ue=20 > references introduce concerns of aliasing and referent lifetime, I think= =20 > the language should have the programmer mention std::move or std::forward= =20 > when they are in effect, and specifically for the thing being referenced,= =20 > not only its container. > While having temporaries introduced for classes designed to be used as=20 values (int, boost::gregorian::dates) is perfectly fine, but doing the=20 same for heavyweight classes is an issue. But in the generic code we aim to= =20 handle both, so to appropriate handle heavyweight classes we must avoid=20 temporaries, even for value ones. This is actually reason for which in=20 optional we define:=20 T& value(); T const& value() const; Instead of simply: T value() const; And if the second design was present then introduction of: T value() &&; Would be a mere optimization. > No proposal from me will necessitate more temporaries :) . I like=20 > performance as much as anyone, but only within the limits of safety. > > As for the rest, I think you=E2=80=99re reading too much into the differe= nces. The=20 > dilemma is between two different, equally expressive, conventions favorin= g=20 > references or values. Performance and safety are both possible with eithe= r. > > In my opinion the reference favoring convertion can work without issues= =20 with classes that are designed to have value semantics but not otherway and= =20 that is the reason I prefer to use it in generic context. --=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/. ------=_Part_136_28872460.1405185804717 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
W dniu sobota, 12 lipca 2014 17:24:03 UTC+2 u=C5=BCytkowni= k David Krauss napisa=C5=82:

On 2014=E2=80=9307=E2=80=93= 12, at 8:57 PM, toma...@gmail.com = wrote:

Th= is will introduce a lot of temporaries in the code.

Most code tends to have a lot of temporaries anyway. = Temporaries are a product of value semantics, as opposed to reference seman= tics. Since rvalue references introduce concerns of aliasing and referent l= ifetime, I think the language should have the programmer mention std::move = or std::forward when they are in effect, and specifically for the thing bei= ng referenced, not only its container.
<= br>While having  temporaries introduced for classes designed to be use= d as=20 values (int, boost::gregorian::dates)  is perfectly fine, but  do= ing the same for heavyweight classes is an issue. But in the generic code we aim= =20 to handle both, so to appropriate handle heavyweight classes we must=20 avoid temporaries, even for value ones. This is actually reason for which in optional<T> we define:
  T& value();
  T con= st& value() const;
Instead of simply:
  T value() const;
= And if the second design was present then introduction of:
  T valu= e() &&;
 Would be a mere optimization.

<= div>

No proposal from me will necessitate more temporari= es :) . I like performance as much as anyone, but only within the limits of= safety.

As for the rest, I think you=E2=80=99re readin= g too much into the differences. The dilemma is between two different, equa= lly expressive, conventions favoring references or values. Performance and = safety are both possible with either.

In my opinion the reference favoring convertion can work without iss= ues with classes that are designed to have value semantics but not otherway= and that is the reason I prefer to use it in generic context.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_136_28872460.1405185804717-- .