Talk:cpp/utility/functional/bind

using namespace std::placeholders

I disagree with the recent edit to the example which changed _1 to std::placeholders::_1 etc: Using _1, _2, etc, after a function-level using directive has been the established practice since the beginning of boost.bind (at least in my personal experience in the industry). In C++, this usage pattern mirrors the old using namespace std::rel_ops; or the various new using namespace std::literals::... (which are all required to enable their repective functionality), in other words, nested namespaces within std are designed for a function-level namespace using --Cubbi (talk) 07:16, 11 October 2013 (PDT)

I'm inclined to agree with you, Cubbi. I've seen this usage pattern in a fair amount of other code. In addition, I feel that the extra length added by all of those qualifiers makes the example harder to parse visually.

I guess one counter-argument might be that if the reader hasn't seen _1 etc. before, they might also be confused. However, if the example is short enough, the using declaration (with its explanatory comment) should be close to the usage of _1 etc., and that will help a bit. Perhaps we should give A-rapEST (and others) a few days to chime in on the discussion, and then consider reverting back. --Nate (talk) 14:56, 11 October 2013 (PDT)

I guess we could add a comment with something along the lines "_1, _2 are from std::placeholders namespace" at the first usage site. This way there would no chance for confusion and the code would still be written according to the best practices. --P12 01:52, 13 October 2013 (PDT)

Done. --Nate (talk) 19:01, 13 October 2013 (PDT)

Deprecation of result_type

Why is it deprecated in C++17 and removed in C++20? How can it be replaced? --Roker (talk) 03:18, 25 June 2020 (PDT)

it was there to support STL/C++98 function composition via std::bind1st etc. Which are all deprecated in C++11 and removed in C++17. --Cubbi (talk) 09:40, 25 June 2020 (PDT)

std::bind and std::function

In https://en.cppreference.com/w/cpp/utility/functional/function is mentioned, that std::function can hold the result of a "bind expression". Unfortunately on this page, std::function is not mentioned at all, so it is unclear what one can do with the result of a bind expression, except than "calling it".

Perhaps an example code snipped would be good to illustrate this aspect even more. --Roker (talk) 06:39, 25 June 2020 (PDT)

there already is an example on cpp/utility/functional/function#Example. bind is not particularly special in this respect. --Cubbi (talk) 09:40, 25 June 2020 (PDT)

Comparison with lambdas?

What do you think of providing side-by-side examples with lambdas (which I think (?) should always be preferred). As in

// void f(int n1, int n2, int n3, const int& n4, int n5);
 
// demonstrates argument reordering and pass-by-reference
int n = 7;
// (_1 and _2 are from std::placeholders, and represent future
// arguments that will be passed to f1)
auto f1 = std::bind(f, _2, 42, _1, std::cref(n), n);
n = 10;
f1(1, 2, 1001); // 1 is bound by _1, 2 is bound by _2, 1001 is unused
                // makes a call to f(2, 42, 1, n, 7)
auto f1prime = [ncref=std::cref(n), n=n](auto a, auto b, auto /*unused*/) {
    f(b, 42, a, ncref, n);
};
f1prime(1, 2, 1001); // Same as a call to f1(1, 2, 1001).

Or I guess to be pedantic/generic, it's

auto f1prime = [ncref=std::cref(n), n=n](auto&& a, auto&& b, auto&& /*unused*/) {
    f(std::forward<decltype(b)>(b), 42, std::forward<decltype(a)>(a), ncref, n);
};

I think most of us find the lambda syntax much clearer. BenFrantzDale (talk) 07:12, 19 May 2021 (PDT)

I think it's worth mentioning lambdas on the page somewhere, either in the notes or example code, and indeed I don't think std::bind is ever more sensible to use than the equivalent lambda. The example code is currently already quite dense though, I wouldn't want to worsen it, so I think just adding your first code sample would be appropriate. --Ybab321 (talk) 12:02, 19 May 2021 (PDT)

✔ Arguably, this update produces, more or less, what you have proposed. In addition, I've replaced the tags that envelop the code above from <code> to `source`.--Space Mission (talk) 16:18, 19 May 2021 (PDT)