220 36326 article Path: news.gmane.org!.POSTED!not-for-mail From: bastienpenava@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Now that the std::forward alternative has been rejected Date: Sun, 24 Dec 2017 17:17:30 -0800 (PST) Lines: 378 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_14282_1694928488.1514164650151" X-Trace: blaine.gmane.org 1514164538 11866 195.159.176.226 (25 Dec 2017 01:15:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 25 Dec 2017 01:15:38 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCG3XHNI6IDRBK5DQHJAKGQEXAOUCQA@isocpp.org Mon Dec 25 02:15:34 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f199.google.com ([209.85.217.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eTHMY-0002TV-2z for gclcip-std-proposals@m.gmane.org; Mon, 25 Dec 2017 02:15:30 +0100 Original-Received: by mail-ua0-f199.google.com with SMTP id e13sf13270716ual.3 for ; Sun, 24 Dec 2017 17:17:33 -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=G9BWqGHnWKtn82V3sq0fD05Dlzv1L045u8729b7c+Vk=; b=OwyUxuAFUG0/y0bTD/0bixQJbTlm4EMAvjyon2JgTaF4eKXXEZUOWXA1bsmxa0PK77 cSemHhu1SS1U11NS67m/DpeEbe7GPaQPQ95oHtC36tn8cphBzIWwRNVA+135gc6sbj3o myP2q5Q6k5F/Bh3STJQaE0VnLdToZ3el1fcvISeqnLyJlxDujSrpG7nKPPWR7m4V2xrm 7ubM9s14wulHgkG8kGAWT/2zgierNwNxiV2VJ8ovNe4EdLbGpZonwtM9h0YkCLrGXLZ0 qK6gKTDUdfkCEd3wm+V1dp5YJroF8eCl3MWlx5Ef2/vcfZAFnKlU57RnRpK/ir8zchWU FDPg== 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=G9BWqGHnWKtn82V3sq0fD05Dlzv1L045u8729b7c+Vk=; b=AcihP0XkmmkB6d8rc1Vcyn40SlEmiPAva2tC4Lt1TO/umFUxlfNlgRCA34VVvtksTU sdmzuQmGohmta4CDicVRfXjSsdcdXqSExwIxYx6S4SuFagz92FrJAr1TtsYaWJ2Kcv8n qax9ESOqm9g2rkTgiWYDvK+VpH923JuENAYnHx9YhoYnKzrxhkFUlPfTVx7rZOyUeIRI F3xyXdzAuvH4ZEZosmqrwyOYOWIy4I5XSRRsfl1xNL34kVE2mzf3bEIOGOYQGgdSbHRF njKFHV3C34gMq0/RCn7XzibL4DicOlNyU+7l43iGeJCQP/g0PW66JnsVhU+jXhr4lyX3 vj+Q== 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=G9BWqGHnWKtn82V3sq0fD05Dlzv1L045u8729b7c+Vk=; b=Ujlqc4IIBd6qIKC1SX+0IVyJM10UWEZjMfYiRrqPGHS8Cm9Bgyx3bp8f6tisD43iqD N6Zb9Mb9U9NzXzZE1PDzGbbfDSd60DD9+x5slSP4/OvHWSQWDe8XkUqKdZsf2YT6aEXz 5Ury82v5stX5o3AUMuhB4mC2nVHq2ulC7Ube+hr/3DDid9F0J4yaCOINxcoTWa2icbX2 GlbJ3TlqsbS27WtGCQV8QWikHRyZpca/4AvnuqmL0vcE41orUGiFnBDI9LWdRBHcLJH9 q4qsS37uuH2NkpHC8GzM0wFFJdoP0M0JljpNekfm7ZsVKl1WawfGX+ymWk05LHIdbEfW 1ypw== X-Gm-Message-State: AKGB3mKICu5I8yDycRQE6hYqXgwYeM0G+dBvikQxc5d7FeYCwwfzOajk Riqe7DVVaYF5vrpcpe7mrq+6kQ== X-Google-Smtp-Source: ACJfBovy4P0enDwiYqpiogpp6bKqK1nJGId9ZQKBX0lb+60yge2VN6cX1X0Bw7EbMHZlGqcnFXfxVw== X-Received: by 10.176.24.79 with SMTP id j15mr3224560uag.15.1514164652480; Sun, 24 Dec 2017 17:17:32 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.160.200 with SMTP id j191ls2188736vke.12.gmail; Sun, 24 Dec 2017 17:17:30 -0800 (PST) X-Received: by 10.31.49.200 with SMTP id x191mr1935451vkx.2.1514164650649; Sun, 24 Dec 2017 17:17:30 -0800 (PST) In-Reply-To: X-Original-Sender: BastienPenava@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:36326 Archived-At: ------=_Part_14282_1694928488.1514164650151 Content-Type: multipart/alternative; boundary="----=_Part_14283_1056359764.1514164650151" ------=_Part_14283_1056359764.1514164650151 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sunday, December 24, 2017 at 9:47:30 AM UTC+1, mihailn...@gmail.com=20 wrote: > > Hello, I read=20 > =20 > the proposal "Forward without forward" has been rejected. > > Now, can we please reconsider fixing forward "the right way" even if it= =20 > involves hacks? > > And by "the right way" a mean, of course, let the template param be=20 > omitted. > > Why is the right way? Multiple reasons: > > > 1. Preserve the API taught for close to 10 years now. > > actually this is false.std::forward without template param is valid and= =20 your change would change its meaning. > > 1. Remove confusion for EVERYONE learning C++11+, be at a beginner or= =20 > advanced user. > 2. The param is confusing on its own (to a beginner) - should I pass T= =20 > or T&&, what happens if I pass const T, const T&&, T*? Do I really hav= e=20 > options here?!? Or Just One Right Param?!?! > > std::forward is fairly easy to explain to a beginner. But even if it wasn't the case, cases where std::forward is required are=20 not for beginners (library writing, etc...). > > 1. The param is an ugly nightmare to pass in [](auto) {} scenario > > C++20 has template parameter for lambda so this is no longer a valid issu= e. > > 1. *Preserve* *and improve* symmetry with std::move!!! Both an=20 > operator and keyword break this, which is not good - std::move and=20 > std::forward are closely related and should use similar API > 2. std::move is *way* more commonly used then frw for everyone except= =20 > library writers - why should frw be that special to have its own op/ke= yword=20 > and move does not?!? > > I'm sorry but no. There is no symmetry between the two. std::move force an object into a temporary object through casting. std::forward ensures that rvalue arguments' ownership is transferred to=20 another function. > > 1. There is no good operator and no good keyword to use > 2. Noone is really asking for a replacement (except library writers)= =20 > but EVRYONE (except experts, I guess) ask for the bloody param to get = lost. > =20 > Library writers are really the only people that uses it so belittling=20 their opinion is wrong. > > 1. The param, technically CAN be deduced, thought not as regular=20 > argument passing. > =20 > > It might be na=C3=AFve, but why, oh why, can't we define forward as > > template< class T =3D /*implementation defined*/> > > constexpr T&& forward( ... ) noexcept; > > There is no way to make this work and using C's var_args is the worst fix= =20 imaginable. Retrieving a value from a C va_list is not constexpr. It requires a named argument. They are really slow. Even today std::forward is already way slower than a simple static_cast so= =20 making it worse is out of the question. If you want a forward without parameter simply write a macro. The point of barry's proposal was to fix at the language level a language= =20 issue instead of using a library solution to a language issue. =20 > I mean, seriously?=20 > > The moment the compiler opens it mouth to say "can't deduce template=20 > parameter '_Tp'" it just replaces it with decltype(arg). Old code still= =20 > works.=20 > I am 1000% sure there is "a technical reason" why this "is not possible",= =20 > but... well if this case needs special rules, so be it - forward deserves= =20 > it. > > And I mean it - no one is expecting forward and move to be "normal=20 > functions", people are even surprised, move is so simple and (much like= =20 > forward) can be hacked with a simple cast! > If a special rule can be applied - forward deserves it - it is better,=20 > simpler and backwards compatible then any keyword and operator. > > > Thank You > MihailNaydenov > =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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/e447b9dd-d8d1-4b73-b1f3-4a6a5ab295a5%40isocpp.or= g. ------=_Part_14283_1056359764.1514164650151 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sunday, December 24, 2017 at 9:47:30 AM UTC+1, = mihailn...@gmail.com wrote:
Hello, I read the proposal = "Forward without forward" has been rejected.

=
Now, can we please reconsider fixing forward "the right way"= even if it involves hacks?

And by "the right= way" a mean, of course, let the template param be omitted.
=
Why is the right way? Multiple reasons:

=
  1. Preserve the API taught for close to 10 years now.
<= /blockquote>
actually this is false.std::forward without template param= is valid and your change would change its meaning.
  1. Remove confusion for E= VERYONE learning C++11+, be at a beginner or advanced user.
  2. The par= am is confusing on its own (to a beginner) - should I pass T or T&&= , what happens if I pass const T, const T&&, T*? Do I really have o= ptions here?!? Or Just One Right Param?!?!
std::forward is fairly easy to explain to a beginner.
But even i= f it wasn't the case, cases where std::forward is required are not for = beginners (library writing, etc...).
  1. The param is an ugly nightmare to pass= in [](auto) {} scenario
C++20 has templat= e parameter for lambda so this is no longer a valid issue.
  1. Preserve = and improve symmetry with std::move!!! Both an operator and keyword = break this, which is not good - std::move and std::forward are closely rela= ted and should use similar API
  2. std::move is *way* more commonly use= d then frw for everyone except library writers - why should frw be that spe= cial to have its own op/keyword and move does not?!?
I'm sorry but no. There is no symmetry between the two.
std::move force an object into a temporary object through casting.
std::forward ensures that rvalue arguments' ownership is transf= erred to another function.
  1. There is n= o good operator and no good keyword to use
  2. Noone is really asking for a replacement (excep= t library writers) but EVRYONE (except experts, I guess) ask for the bloody= param to get lost.
Library w= riters are really the only people that uses it so=C2=A0belittling their opi= nion is wrong.
  1. The param, technical= ly CAN be deduced, thought not as regular argument passing.

It might be na=C3=AFve, but why, oh why, can't we define forward = as

template< class T =3D /*implementation defined*/>
constexpr T&& forward(= <= span style=3D"color:#660">... ) noexc= ept;

There is no way to make this work and using C&#= 39;s var_args is the worst fix imaginable.
Retrieving a value fro= m a C va_list is not constexpr.
It requires a named argument.
They are really slow.

Even today std::forwa= rd is already way slower than a simple static_cast so making it worse is ou= t of the question.
If you want a forward without parameter simply= write a macro.
The point of barry's proposal was to fix at t= he language level a language issue instead of using a library solution to a= language issue.
=C2=A0
I mean, seriously?=C2=A0

The moment the compil= er opens it mouth to say "can't deduce template parameter '_Tp= '" it just replaces it with decltype(arg). Old code still works.= =C2=A0
I am 1000% sure there is "= a technical reason" why this "is not possible", but... well = if this case needs special rules, so be it - forward deserves it.

And I= mean it - no one is expecting forward and move to be "normal function= s", people are even surprised, move is so simple and (much like forwar= d) can be hacked with a simple cast!
I= f a special rule can be applied - forward deserves it - it is better, simpl= er and backwards compatible then any keyword and operator.


<= div style=3D"margin:0px;padding:0px;border:0px rgb(34,34,34);text-align:lef= t;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spacing:no= rmal;font-size:13px;font-variant:normal;word-spacing:0px;white-space:normal= ;background-color:transparent">Thank You
MihailNaydenov
=C2=A0

--
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/e447b9dd-d8d1-4b73-b1f3-4a6a5ab295a5= %40isocpp.org.
------=_Part_14283_1056359764.1514164650151-- ------=_Part_14282_1694928488.1514164650151-- .