220 35947 <74fb3c11-770c-4cfa-8133-5dfdde334a60@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: auto return proposal Date: Sun, 17 Dec 2017 07:13:11 -0800 (PST) Lines: 74 Approved: news@gmane.org Message-ID: <74fb3c11-770c-4cfa-8133-5dfdde334a60@isocpp.org> References: <30242172-642a-4803-a7bd-bfeb95b2868a@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_12268_1019651839.1513523591632" X-Trace: blaine.gmane.org 1513523477 7375 195.159.176.226 (17 Dec 2017 15:11:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 17 Dec 2017 15:11:17 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBCMT3LIQKGQEWBI3VEA@isocpp.org Sun Dec 17 16:11:13 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f71.google.com ([209.85.213.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eQaau-0001cM-CT for gclcip-std-proposals@m.gmane.org; Sun, 17 Dec 2017 16:11:12 +0100 Original-Received: by mail-vk0-f71.google.com with SMTP id z85sf6765472vkd.22 for ; Sun, 17 Dec 2017 07:13:14 -0800 (PST) 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=qCEPb5CI71RZubrROVVjInHB2/+18Xbu7Mes0L86Z84=; b=pjBzja6jeGKElRerRiwWbLdwal7CZk9tzLAtr1KLl8cIgVm7k+S6hkVYJjfPWPTtIT MFsM5KZDjxIuKM5QeJeO8BDh0t8wy4dojGh98vYtffLpuCbz4WrlUZtbzJwaHrOmja1S UK0c7zWCkxw9BP3T5XL2xzknXX5svK9gf3EX2jXQl+Jc+Kn3nSJCHCkuDoQo5UcWn4R+ BhFj33E6W6WXhy4LB1zNfo6xNaxqPJ7Xv+tId04cSh5Gj+Xi0l1q0bMJzGjVYGBf23P4 tZGxLgxHfrz8IgvjJKSeqa3yU70+UpPwY2Afcls48YT8t7wzbs7+cblERvDLAdmw9GPr qhhQ== 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=qCEPb5CI71RZubrROVVjInHB2/+18Xbu7Mes0L86Z84=; b=H+TII85JrvzIc6BuwsnbJ9HzQSAkHvxs02Mtoj36eTJpY6g5MViY7YqyBT9GPvJyhH ad7WrCtUbpNw19PSEnsQXUdd8AIQO3l3omJnOEHOdgYNPGl9ngVaQ+E25OcXk4vtajbF tFH4DG3QRCa30q+KeTkktn7v0PvTqYRf0qnXZO9W52eDD7KF7KPYWgiK+awFmh3jyos/ UC+h2fDQYhSKAde/+jgO6+FC6i9EJ8bf65cXNMgQZphPY3xzHvkj6Kc8jruDeXPydYSD 2xy/5oqLgJxLs2ISmFRGBWFw40FeD73lJ4yWEIbQu1fDgasV9temxiCuPkGvxPM9HAdG 9t/w== 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=qCEPb5CI71RZubrROVVjInHB2/+18Xbu7Mes0L86Z84=; b=SAvm6MIAnt+Wo4L5Fx9trvf/zDtJUBBr6WTNzpOEf+51J4stlry5uumBHqP06mHktJ 1euBYPQvy1ScifJkPfu3lqBmbf4aglSByDZ9RYsVtHX1JT2yFDqv87bqabHKf/vVT/Zi n/xNSLsxeAIGIsPGFwDcLbnK01cZn2+k34maNj4abmx8N05kKaVMr0se7tyHbGv4WxcC HhHHvKp9BU0rnoRdBDDMoRJULDnZLSDreI1H58q8c3yYhz2N8nH9BmPKrZ7s7a8aN2As NroyqdByTVXBSXCJ6bKoSZwTKUxVLhanhChiGfT3plz34E/IR2C+YAKSAJ4L1M4M+lbS jGAw== X-Gm-Message-State: AKGB3mK+EZ3JpHIxJytl3JGRmmfnGzERzZ6MPGMc4ReJCEWNFH7ORveZ R1eOa8Vx9HT4lPD54B4KSnhX+A== X-Google-Smtp-Source: ACJfBovjrI1j+eLlWB2PYJBRudCQjXLZhUS4pjz/ObRloKNNXBiCNVfX0LOuQERBiTmpV65aRBjXkQ== X-Received: by 10.31.63.211 with SMTP id m202mr3746990vka.14.1513523594458; Sun, 17 Dec 2017 07:13:14 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.65.136 with SMTP id o130ls1780131vka.19.gmail; Sun, 17 Dec 2017 07:13:12 -0800 (PST) X-Received: by 10.31.2.144 with SMTP id 138mr1689663vkc.5.1513523592234; Sun, 17 Dec 2017 07:13:12 -0800 (PST) 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-Spam-Checked-In-Group: std-proposals@isocpp.org 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:35947 Archived-At: ------=_Part_12268_1019651839.1513523591632 Content-Type: multipart/alternative; boundary="----=_Part_12269_1182471584.1513523591632" ------=_Part_12269_1182471584.1513523591632 Content-Type: text/plain; charset="UTF-8" On Sunday, December 17, 2017 at 8:41:46 AM UTC-5, Sarfaraz Nawaz wrote: > > Since C++14, the return-type of a function can be inferred from the > return-expression (and that has few use cases). Now you want the opposite: > inferring the return-variable from the return-type? What is the advantage > in doing so, other than you can save few keystrokes? > In two words? Guaranteed elision. As it currently stands, a function that returns a stack variable in a return prvalue of the same type *may* elide the copy/move. But it is not required to do so. We can get guaranteed elision for `return Typename(...);`, but not for `return some_var;`. This proposal (though I *really* don't agree with the syntax) can achieve this. > -- 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/74fb3c11-770c-4cfa-8133-5dfdde334a60%40isocpp.org. ------=_Part_12269_1182471584.1513523591632 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sunday, December 17, 2017 at 8:41:46 AM UTC-5, Sarfaraz= Nawaz wrote:
= Since C++14, the return-type of a function can be inferred from the return-= expression (and that has few use cases). Now you want the opposite: inferri= ng the return-variable from the return-type? What is the advantage in doing= so, other than you can save few keystrokes?

In two words? Guaranteed elision.

As it cu= rrently stands, a function that returns a stack variable in a return prvalu= e of the same type may elide the copy/move. But it is not required t= o do so. We can get guaranteed elision for `return Typename(...);`, but not= for `return some_var;`.

This proposal (though I <= i>really don't agree with the syntax) can achieve this.

--
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/74fb3c11-770c-4cfa-8133-5dfdde334a60= %40isocpp.org.
------=_Part_12269_1182471584.1513523591632-- ------=_Part_12268_1019651839.1513523591632-- .