220 36338 article Path: news.gmane.org!.POSTED!not-for-mail From: mihailnajdenov@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Now that the std::forward alternative has been rejected Date: Mon, 25 Dec 2017 01:27:09 -0800 (PST) Lines: 538 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_14916_862137623.1514194029897" X-Trace: blaine.gmane.org 1514193917 24853 195.159.176.226 (25 Dec 2017 09:25:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 25 Dec 2017 09:25:17 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRB34IQPJAKGQEVI2EVFQ@isocpp.org Mon Dec 25 10:25: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 1eTP0Q-0005yh-1F for gclcip-std-proposals@m.gmane.org; Mon, 25 Dec 2017 10:25:10 +0100 Original-Received: by mail-vk0-f71.google.com with SMTP id i68sf17418883vkd.15 for ; Mon, 25 Dec 2017 01:27:12 -0800 (PST) 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:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=A4GFtdHwlf58Q6DVQ2nW/5/gka4GzehEay75HtKWjv8=; b=WJKqc4XVDmciLWldJdzbu96eghySStIxkdLLCRs/EKpMIaZdQ42J4hDMCnU9v0f/Fm 18APfilD9Jasi5w282CZFnB2cekDxo4kBirl6QH0ZH4dIF2KJjAuRNo7JvQHjA1yrM0J k5Zd9iyGo6J00jo07D4LcwvX2AjKB1V+0qsi90qxv+E30Hyo2zeF9GjEoZwcS8Jgbisi alCM+H1960A1raSCusLa4pYxZJUpQKY3yb8j5BdSK5M9KztedGLlHLTt286p362g+AS4 e4DFZOHMwDLHGJz8sh+8GpuIuuzsuhRatK2iYqn+pAkcIFFv+aotT75eGeli2CsQAZtH nKBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc: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=A4GFtdHwlf58Q6DVQ2nW/5/gka4GzehEay75HtKWjv8=; b=WyibkmMdwOlajEcoRkuTRHJuR8LKaOVCisrlISUOGMSr4L3VR+ICliNyf1EVo6Cml9 p2Jqzh6W0/4FckOUp5WwaEEaEG5paB9Eb8CbIwRabxTdtM91OqW3b6rN2K+1YGTFsuqO If5ocgAMoTnJX0LEoP5WTIPPOdMhIMkDeM80/XaTOi9AxQrcKBEz1qEnlMa/qYwWFx73 485OgLaaaQVsuV7kwg5mMJqOvg5CZYh+IrsfeI3kL67575H1gGha6MDIBO2qH8GthH+q D88JjatTVh4CmNmTtwjBtjkmkG/S6PNFJ412ieiM60XFer3sOaVN5LzMak1y5cAeGt2M k+ig== 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: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=A4GFtdHwlf58Q6DVQ2nW/5/gka4GzehEay75HtKWjv8=; b=ruF+v/NnBujnMPoRlgCBO/NpRUwfptkLjwAZZ9rd+mRo+yVrOTqZbqp0M6oyHOtcBH HYvWFR4h8hcdTSH8opKJT6DD6q/xKkmtbGVo6ePyF6QdvgyXNKljp6Zn4+v+VQWSbEbN bTsWq3NvFmIiKax//oXcuA5lUXN/X4lHaz/VpXTEsLOT9PAdwaEzapnge2EE1XqURfC4 /ckzF9AKcrqiy57+j0OnbOujhWFRvASwsaSohUjh4tdVWcqZKHfCwIMhRqcZFHlCUmNt SiaVZHl2sUsam0WV4X8YygrrLRDbipXXsryMlYZPc0o5DKa92CXo9OJuKOJi6ku3e5UO Lilg== X-Gm-Message-State: AKGB3mK3fbKMxp4S5HDcQfMhVhIxGEK1tDxUX88/ch+htpZmRM+CRWxT b9WRl0CDd84tvqBM7GVlMFZahw== X-Google-Smtp-Source: ACJfBouBZrkNuZ+jUaKCgq4ybMVSuUxPeyiZiR6bDUq52vR0QAWzlZ2szPXUUGI1eIU2xOiivM3/Iw== X-Received: by 10.31.80.199 with SMTP id e190mr9786039vkb.22.1514194032449; Mon, 25 Dec 2017 01:27:12 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.3.68 with SMTP id 65ls2149767vkd.8.gmail; Mon, 25 Dec 2017 01:27:10 -0800 (PST) X-Received: by 10.31.94.215 with SMTP id s206mr2017690vkb.1.1514194030554; Mon, 25 Dec 2017 01:27:10 -0800 (PST) In-Reply-To: X-Original-Sender: MihailNajdenov@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:36338 Archived-At: ------=_Part_14916_862137623.1514194029897 Content-Type: multipart/alternative; boundary="----=_Part_14917_1137661987.1514194029898" ------=_Part_14917_1137661987.1514194029898 Content-Type: text/plain; charset="UTF-8" > > >> >> template< class T = /*implementation defined*/> >> >> constexpr T&& forward( ... ) noexcept; >> >> There is no way to make this work and using C's var_args is the worst fix > imaginable. > Retrieving a value from a C va_list is not constexpr. > It requires a named argument. > They are really slow. > > O, boy, by all means I was not suggesting var_args, I was lazy to type. Here is the complete specification (modified from cppreference). template< class T = /* IMPLEMENTATION DEFINED */> constexpr T&& forward( typename std::remove_reference::type& t ) noexcept; template< class T = /* IMPLEMENTATION DEFINED */> constexpr T&& forward( typename std::remove_reference::type&& t ) noexcept; DONE. Old code still works, if the compiler can't deduce the argument it will be instructed to replace it with the result of decltype(t). std::forward and std::move have symmetry as they are both *transfers* - one is transferring ownership, the other is transferring "whatever you give me" (constnes, ownership, whatever, I am hands off, move along). Their naming is also good, the fact that they are syntactically NOT casts is good design decision - might be implemented as cast, but semantically they are not. Good job there. The problem is only the necessary param of forward - everyone will and does question why at some point. And the answer is not an answer but an excuse - no new understanding is received, it does not make you a better programmer it only shows limitations of the implementation, nothing more. Not unlike the pesky typename in template code (which is going away luckily, 20 years later) As for library writer only need forward. I don't see how is this the case. The moment you need to wrap any template code you need it. template< class Container, class UnaryPredicate > auto find_if(Container& c, UnaryPredicate&& val) { using std::begin; using std::end; return std::find_if(begin(c), end(c), std::forward(val)); } You might argue, this is "library code", but It is the normal user who might and will write it. As for "library solution" vs "language". Yes I agree move and forward are by nature language features, but is too late to implement them as such, and an operator is hardly "language level", just syntax sugar. And if anyone is promoted to language, it is the wildly more popular move. And by promoted I mean compiler support in the lines present by Microsoft on the cppCon last year or may be it was the year before. Right now you can move/forward twice the same variable without even an warning, which is just a joke (aka Footgun). P.S Marry Christmas, everyone! -- 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/cafca4af-400f-47f8-abab-48eef0727a99%40isocpp.org. ------=_Part_14917_1137661987.1514194029898 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


template<<= /span> class T =3D /*implementation defined= */>

constexpr= T&& forward( ... = )<= span style=3D"color:#000"> n= oexcept;
=
There is no way to make this work and using= C's var_args is the worst fix imaginable.
Retrieving a value= from a C va_list is not constexpr.
It requires a named argument.=
They are really slow.


O, boy, by all means I was not suggesting=C2=A0=C2=A0var_args, I = was lazy to type.

Here is the complete specificati= on (modified from cppreference).

template&= lt; class<= /span> T =3D= /* IMPLEMENTATION D= EFINED */>
constexpr T&& forward( typename std<=
/span>::remove_reference=
<T>::type& t ) noexcept;

template< class T =3D =C2=A0/* IMPLEMENTATION DEFINED */<=
span class=3D"styled-by-prettify" style=3D"color: #660;">>=
= 
constexpr T&& forward( typename std::remove_reference<T>::t=
ype&& t ) noexcept;


DONE. Old code stil= l works, if the compiler can't deduce the argument it will be instructe= d to replace it with the result of decltype(t).

std::forward and std::move have symmetry as they are both t= ransfers - one is transferring ownership, the other is transferring &qu= ot;whatever you give me" (constnes, ownership, whatever, I am hands of= f, move along).

Their naming is also good, the fa= ct that they are syntactically NOT casts is good design decision - might be= implemented as cast, but semantically they are not. Good job there.
<= div>
The problem is only the necessary param of forward - eve= ryone will and does question why at some point.
And the answer i= s not an answer but an excuse - no new understanding is received, it does n= ot make you a better programmer it only shows limitations of the implementa= tion, nothing more.
Not unlike the pesky typename in template cod= e (which is going away luckily, 20 years later) =C2=A0

=

As for library writer only need forward. I don't se= e how is this the case. The moment you need to wrap any template code you n= eed it.

template< class Container, <= span class=3D"styled-by-prettify" style=3D"color: #008;">class UnaryPredicate >
auto find_if(Container& c, UnaryP=
redicate&& val)
{
=C2=A0 using std::begin;
= =C2=A0 usi= ng std::end; 
=C2=A0 r=
eturn std<=
/span>::find_if(begin(c), end(c), std::forward<UnaryPredicate>(=
val));

}

You migh= t argue, this is "library code", but It is the normal user who mi= ght and will write it.

As for "library so= lution" vs "language". Yes I agree move and forward are by n= ature language features,
but is too late to implement them as su= ch, and an operator is hardly "language level", just syntax sugar= ..

And if anyone is promoted to language, it= is the wildly more popular move.
And by promoted I mean compile= r support in the lines present by Microsoft on the cppCon last year or may = be it was the year before.=C2=A0
Right now you can move/forward t= wice the same variable without even an warning, which is just a joke (aka F= ootgun).


P.S Marry Christmas, every= one!

--
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/cafca4af-400f-47f8-abab-48eef0727a99= %40isocpp.org.
------=_Part_14917_1137661987.1514194029898-- ------=_Part_14916_862137623.1514194029897-- .