[Bug libstdc++/111327] New: std::bind_front doesn't perfectly forward according to value category of the call wrapper object

[Bug libstdc++/111327] New: std::bind_front doesn't perfectly forward according to value category of the call wrapper object

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111327

            Bug ID: 111327
           Summary: std::bind_front doesn't perfectly forward according to
                    value category of the call wrapper object
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ppalka at gcc dot gnu.org
  Target Milestone: ---

Testcase:

#include <functional>

struct F {
  void operator()() & = delete; // #1
  void operator()() const &;    // #2
};

int main() {
  auto f = F{};
  auto g = std::bind_front(F{});
  f(); // error: use of deleted function
  g(); // incorrectly calls #2 instead of being ill-formed
}

Since f isn't invocable as a non-const lvalue, g shouldn't be either.

[Bug libstdc++/111327] std::bind_front doesn't perfectly forward according to value category of the call wrapper object

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111327

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
We might want to look into bind<R> too:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0826r0.html#3.-implementation-experience

[Bug libstdc++/111327] std::bind_front (and std::not_fn) doesn't always perfectly forward according to value category of the call wrapper object

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111327

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org
   Last reconfirmed|                            |2023-09-12
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
            Summary|std::bind_front doesn't     |std::bind_front (and
                   |perfectly forward according |std::not_fn) doesn't always
                   |to value category of the    |perfectly forward according
                   |call wrapper object         |to value category of the
                   |                            |call wrapper object

[Bug libstdc++/111327] std::bind_front (and std::not_fn) doesn't always perfectly forward according to value category of the call wrapper object

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111327

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:f1e87aee5b7023fb4f5791c6869db705e18c2705

commit r14-3901-gf1e87aee5b7023fb4f5791c6869db705e18c2705
Author: Patrick Palka <ppalka@redhat.com>
Date:   Tue Sep 12 11:23:08 2023 -0400

    libstdc++: Remove std::bind_front specialization for no bound args

    The specialization used by std::bind_front when there are no bound args
    (added by r13-4214-gcbd05ca5ab1231) seems to be mostly obsoleted by
    r13-5033-ge2eab3c4edb6aa which added [[no_unique_address]] to the main
    template's data members.  What's left to consider is the compile time
    advantage of the specialization, which doesn't seem huge since it just
    avoids using tuple<> (which is an explicit specialization anyway) and
    expanding some pack expansions with an empty argument pack.  So this
    patch removes this specialization; this means we have one less spot to
    fix the PR libstdc++/111327 perfect forwarding bug.

    libstdc++-v3/ChangeLog:

            * include/std/functional (_Bind_front0): Remove.
            (_Bind_front_t): Adjust.

[Bug libstdc++/111327] std::bind_front (and std::not_fn) doesn't always perfectly forward according to value category of the call wrapper object

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111327

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:4289f6ceefe74ea46e792692448c06197ac20c86

commit r14-3902-g4289f6ceefe74ea46e792692448c06197ac20c86
Author: Patrick Palka <ppalka@redhat.com>
Date:   Tue Sep 12 11:23:12 2023 -0400

    libstdc++: Fix std::bind_front perfect forwarding [PR111327]

    In order to properly implement a perfect forwarding call wrapper (without
    C++23 deducing 'this') we need a total of 8 operator() overloads, 4
    enabled ones and 4 deleted ones, i.e. two for each const/ref qual pair,
    as described in section 5.5 of P0847R6.  Otherwise the wrapper may not
    do the right thing if the underlying function object has a deleted
    const/ref-qualified operator() overload.  This patch fixes this issue in
    std::bind_front.

            PR libstdc++/111327

    libstdc++-v3/ChangeLog:

            * include/std/functional (_Bind_front::operator()): Add deleted
            fallback overloads for each const/ref qualifier pair.  Give the
            enabled overloads dummy constraints to make each one more
            specialized than the corresponding deleted overload.
            * testsuite/20_util/function_objects/bind_front/111327.cc: New
test.

[Bug libstdc++/111327] std::bind_front (and std::not_fn) doesn't always perfectly forward according to value category of the call wrapper object

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111327

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:52f65d17c85fa513887a3bb31e3c3c329d9ace58

commit r14-3903-g52f65d17c85fa513887a3bb31e3c3c329d9ace58
Author: Patrick Palka <ppalka@redhat.com>
Date:   Tue Sep 12 11:26:50 2023 -0400

    libstdc++: Fix std::not_fn perfect forwarding [PR111327]

    The previous patch fixed perfect forwarding in std::bind_front.
    This patch fixes the same issue in std::not_fn.

            PR libstdc++/111327

    libstdc++-v3/ChangeLog:

            * include/std/functional (_GLIBCXX_NOT_FN_CALL_OP): Also define
            a deleted fallback operator() overload.  Constrain both the
            enabled and deleted overloads accordingly.
            * testsuite/20_util/function_objects/not_fn/111327.cc: New test.

[Bug libstdc++/111327] std::bind_front (and std::not_fn) doesn't always perfectly forward according to value category of the call wrapper object

[de34 at live dot cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111327

Jiang An <de34 at live dot cn> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |de34 at live dot cn

--- Comment #5 from Jiang An <de34 at live dot cn> ---
The current fix doesn't seem sufficient (https://godbolt.org/z/rs5oYxjTc):

#include <functional>
#include <utility>

struct Weird {
    void operator()() {}
    bool operator()() const { return true; }
};

int main()
{
    auto nf = std::not_fn(Weird{});
    nf(); // should be rejected, but calls the const overload
    std::as_const(nf)();
}

[Bug libstdc++/111327] std::bind_front (and std::not_fn) doesn't always perfectly forward according to value category of the call wrapper object

[de34 at live dot cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111327

--- Comment #6 from Jiang An <de34 at live dot cn> ---
It seems that deleted operator() overloads in the return type of std::not_fn is
only necessary since C++20. The changes were made in P0356R5.

In C++17, the return type was nearly fully specified and didn't have deleted
overloads.
https://timsong-cpp.github.io/cppwp/n4659/func.not_fn#1

[Bug libstdc++/111327] std::bind_front (and std::not_fn) doesn't always perfectly forward according to value category of the call wrapper object

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111327

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The example bind_front implementation in P0356R5 doesn't use deleted overloads,
despite that paper making it a perfect forwarding call wrapper. I remain
unconvinced that anybody in WG21 intended the deleted overloads when those
changes were made.

[Bug libstdc++/111327] std::bind_front (and std::not_fn) doesn't always perfectly forward according to value category of the call wrapper object

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111327

--- Comment #8 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:ac1a399bf61b04845f5d6fc34e4b7a4db2bc5760

commit r14-7220-gac1a399bf61b04845f5d6fc34e4b7a4db2bc5760
Author: Patrick Palka <ppalka@redhat.com>
Date:   Fri Jan 12 23:02:12 2024 -0500

    libstdc++: Implement C++23 std::bind_back from P2387R3 [PR108827]

    The implementation is based off of std::bind_front.  Since this is a
    C++23 feature we use deducing this unconditionally.

            PR libstdc++/108827
            PR libstdc++/111327

    libstdc++-v3/ChangeLog:

            * include/bits/version.def (bind_back): Define.
            * include/bits/version.h: Regenerate.
            * include/std/functional (_Bind_back): Define for C++23.
            (bind_back): Likewise.
            * testsuite/20_util/function_objects/bind_back/1.cc: New test
            (adapted from corresponding bind_front test).
            * testsuite/20_util/function_objects/bind_back/111327.cc: Likewise.