220 36305 article Path: news.gmane.org!.POSTED!not-for-mail From: mihailnajdenov@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Now that the std::forward alternative has been rejected Date: Sun, 24 Dec 2017 00:47:29 -0800 (PST) Lines: 409 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_12554_1402040117.1514105249893" X-Trace: blaine.gmane.org 1514105135 30083 195.159.176.226 (24 Dec 2017 08:45:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 24 Dec 2017 08:45:35 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBIWT7XIQKGQEEUOUI4A@isocpp.org Sun Dec 24 09:45:31 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f200.google.com ([209.85.217.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eT1uT-0007M6-Oq for gclcip-std-proposals@m.gmane.org; Sun, 24 Dec 2017 09:45:30 +0100 Original-Received: by mail-ua0-f200.google.com with SMTP id 7sf19946299uap.5 for ; Sun, 24 Dec 2017 00:47:32 -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:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=JXGIokQ5ULJWPknR8auWhAyqNDAq5dJfOhgzPCezIr4=; b=aItOvPYkd3z0HrIY5juSxa9CYYe3BzEF92n48uhK2qyEsen4WGOmG2Zz0KJg5qrJPV Whm1KMUA94PmhLhZ78hZfDPXRgqBWuc3WRaIbSI9FhBJFwiTKKaqXp9qsyLTixV3IzIn yYcW8M/IZacvQx7iImu/THEk1RDCFVeOeEIEqEERrBbf5FNv1sYb1Rrp9JmQwwyKLfkg n/x9elel7UNXrgTeXkR9cynIcl4yHO0OqtP2YypHRDYIwQ6YWPio4Ogar+SX/hE6XYqk NkuFvkydr/w81i16g2B3IxB8RfmBTQQlPEoHF0/d9b2ZNiF8UUXIBhmsE54rMTWPd6/R uIWg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=JXGIokQ5ULJWPknR8auWhAyqNDAq5dJfOhgzPCezIr4=; b=lExNwLLzcDOY4JE0PvIFHuhRGSa2yzsED3ZZoG565aMdpvWTRjvowUeCsDYWOaYMz+ LrF6saBR/YGi8xAM6YAeftOFkIhUnFAqIKz++Ot59EQeyDm22VVvGBYyslvp5eePGVd4 DAUvvaOzM2f+myDax4DeVAv+LN1p7wlrZujBU1oSZB89eG7g+Vvb9Wb5OKnvMT3JuQWU m9NAudFKSzP8C36MYNKYLIcGVRMVQv2hTH1xiI1zXQE/xfczSxyBMrjeeMthl11c+bip 7EkK4ShOo5Z6Xnz25HqL4bvP+55xBVJLrTk89EZzKUTzeFNv4bWtsev3t6SChTD432G6 BlPA== 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: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=JXGIokQ5ULJWPknR8auWhAyqNDAq5dJfOhgzPCezIr4=; b=rmTbfZIh3bST+7FvVcB1NHxI6TTEJlGcNdl1JqTQ7i9CJcSiUe2Ykb4A5p89gxM50S +Cdx+dT/J0QUHKCTkzvGNT9KxiITCtQ7FzgtkCvaY/738sreeCtC0VA4WqKf9hQ8wLrz QrYO12ZRHroKrDItWcqzhGS6koNsji5Ysq01S0OQGVBnq9l8XrF6szUhZfKmXlAhqgIC 6qV+Oq665OIyobDNSRkZF4RxJfCaH1QUgSKcVYoNy0jNkNXE5moYkcakTMAGHss2eqRw rIri+gSk8ObuoNW0y8pRB82FKHQrcKKhC8NZIB4Sjto1OhB21yqmAQrlSsobbZh5/xq1 d4rg== X-Gm-Message-State: AKGB3mIgSaGKO4kCmn0XqLQwXH07wWBc1/bBdq++wPenaFCvfWHutI4Y B3TINJfcp20SJzB0UoeD0vIvGg== X-Google-Smtp-Source: ACJfBoub7m8KvsM4Twq8crycWlWrvZ3IlaMllEzB5TANVT0NAxm2uO/L6kJyW1rAve8bxvTCJkaZ1Q== X-Received: by 10.159.38.36 with SMTP id 33mr10001278uag.90.1514105252068; Sun, 24 Dec 2017 00:47:32 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.159.150 with SMTP id i144ls1991469vke.11.gmail; Sun, 24 Dec 2017 00:47:30 -0800 (PST) X-Received: by 10.31.49.200 with SMTP id x191mr1751591vkx.2.1514105250385; Sun, 24 Dec 2017 00:47:30 -0800 (PST) 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:36305 Archived-At: ------=_Part_12554_1402040117.1514105249893 Content-Type: multipart/alternative; boundary="----=_Part_12555_870348575.1514105249894" ------=_Part_12555_870348575.1514105249894 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 omitted= .. Why is the right way? Multiple reasons: 1. Preserve the API taught for close to 10 years now. 2. Remove confusion for EVERYONE learning C++11+, be at a beginner or=20 advanced user. 3. 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 have= =20 options here?!? Or Just One Right Param?!?! 4. The param is an ugly nightmare to pass in [](auto) {} scenario 5. *Preserve* *and improve* symmetry with std::move!!! Both an operator= =20 and keyword break this, which is not good - std::move and std::forward a= re=20 closely related and should use similar API 6. 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/keyw= ord=20 and move does not?!? 7. There is no good operator and no good keyword to use 8. Noone is really asking for a replacement (except library writers) but= =20 EVRYONE (except experts, I guess) ask for the bloody param to get lost. 9. 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; 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 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/ebc148fa-9b1f-4972-8a53-6f52c6ead259%40isocpp.or= g. ------=_Part_12555_870348575.1514105249894 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello, I = read the proposal "Forward without forward" has been rejected= ..

Now, can we please reconsider fixing forward &qu= ot;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.
  2. Remove confusion for EVERYONE learning C++11+, be at a beginn= er or advanced user.
  3. The param is confusing on its own (to a beginn= er) - should I pass T or T&&, what happens if I pass const T, const= T&&, T*? Do I really have options here?!? Or Just One Right Param?= !?!
  4. The param is an ugly nightmare to pass in [](auto) {} scenario<= /li>
  5. 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 related and should use similar API
  6. std::move is= *way* more commonly used then frw for everyone except library writers - wh= y should frw be that special to have its own op/keyword and move does not?!= ?
  7. Th= ere is no good operator and no good keyword to use
  8. Noone is really= asking for a replacement (except library writers) but EVRYONE (except expe= rts, I guess) ask for the bloody param to get lost.
  • The param, tec= hnically CAN be deduced, thought not as regular argument passing.

    • <= div style=3D"margin: 0px; padding: 0px; border: 0px rgb(34, 34, 34); border= -image: none; text-align: left; color: rgb(34, 34, 34); text-transform: non= e; text-indent: 0px; letter-spacing: normal; font-size: 13px; font-variant:= normal; word-spacing: 0px; white-space: normal; orphans: 2; -webkit-text-s= troke-width: 0px; background-color: transparent;">It might be na=C3=AFve, b= ut why, oh why, can't we define forward as

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

    constexpr T&& forward( ...<= span class=3D"styled-by-prettify" style=3D"color: #000;">     ) noexcept;
    =
    I mean, seriously?=C2=A0

    The moment the compiler opens it mouth t= o 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 functions", people are even surprised, mov= e is so simple and (much like forward) can be hacked with a simple cast!
    If a special rule can= be applied - forward deserves it - it is better, simpler and backwards com= patible then any keyword and operator.


    Thank Yo= u
    MihailNaydenov

    --
    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/ebc148fa-9b1f-4972-8a53-6f52c6ead259= %40isocpp.org.
    ------=_Part_12555_870348575.1514105249894-- ------=_Part_12554_1402040117.1514105249893-- .