8

In C++20, bind_front was added to the standard library, per this paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0356r4.html

That paper originally included a bind_back function, but after Revision 1 it says it was removed per guidance from LEWG.

This decision was motivated by lack of compelling use cases for this function.

It appears to me that partial application of non-commutative math operations, such as std::minus and std::divides are obvious use cases for such a function. Does anyone have any insight for why LEWG decided this should be removed?

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
RoboCop87
  • 825
  • 1
  • 8
  • 21
  • Lambdas can replace all the use cases of bind – Daniel Aug 24 '20 at 17:09
  • @Barry You are correct, that is an error in my transcription. Will edit. – RoboCop87 Aug 24 '20 at 17:23
  • @Dani That is true for bind_front also, but it was still added – RoboCop87 Aug 24 '20 at 17:24
  • I agree on `bind_front`; I think it was a mistake and shouldn't have been added, and existing `std::bind` should have been deprecated and slated for future removal. – Eljay Aug 24 '20 at 17:26
  • 6
    @Eljay [Why use `std::bind_front` over lambdas in C++20?](https://stackoverflow.com/questions/62807743/why-use-stdbind-front-over-lambdas-in-c20) – bolov Aug 24 '20 at 17:29
  • 1
    I think there is a compelling argument that lambdas can add syntactic noise when used as an argument to another function. Something like transform(begin(a), end(a), begin(b), [y](auto x) { return x - y; }); vs transform(begin(a), end(a), begin(b), bind_back(minus, y)); – RoboCop87 Aug 24 '20 at 17:31
  • if no one on the committee brought any compelling use cases then there is your source of "lack of compelling use cases" – bolov Aug 24 '20 at 17:32
  • @bolov Perhaps I should reword the question to be "why did LEWG decide that the obvious uses for bind_back were not compelling?" Would that clear up the confusion? – RoboCop87 Aug 24 '20 at 17:36
  • You should ask the author of the paper / members of the WG (those who *made* the decision), for rationale, not random strangers on the internet. – Jesper Juhl Aug 24 '20 at 17:41
  • @Barry my apologies if I came across as condescending, I was attempting exactly the opposite. Emoting over text is hard! I am honestly curious why this decision was made. – RoboCop87 Aug 24 '20 at 17:42
  • 2
    @JesperJuhl I've seen members of working groups give great answers to similar questions on SO before. I believe this is an appropriate forum – RoboCop87 Aug 24 '20 at 17:43
  • @RoboCop87 It's rather hit'n'miss though. Why not ask them directly? Worst case; you get ignored. – Jesper Juhl Aug 24 '20 at 17:44
  • @RoboCop87: "*why did LEWG decide that the obvious uses for bind_back were not compelling?*" Do you see anything especially compelling about them? I don't. Compelling use cases are typically self-justifying. Experienced programmers know what pain points they encounter and the general frequency of them. So if they see a way that's better, it doesn't take much convincing to make them go "yes, that's better." You've shown one use case: the second parameter to certain operators. But even that's not good, because calling operator functions directly is *usually* a bad idea. – Nicol Bolas Aug 24 '20 at 17:47
  • @NicolBolas My example was appropriate for a comment on a SO thread. I think bolov's earlier link gives a better justification – RoboCop87 Aug 24 '20 at 17:49
  • @RoboCop87: If you call an operator function directly, then you have to know exactly how it was declared. Is it a member function? Is it a namespace scoped function? Was it defined as a `friend` and thus is only really findable via ADL? These go away when you use the operator in actual code. And if you want to simulate that kind of thing, you can't use any form of `bind`. – Nicol Bolas Aug 24 '20 at 17:49
  • @RoboCop87: Bolov's link is about `bind_front` *specifically*. The answers don't apply to `bind_back`. – Nicol Bolas Aug 24 '20 at 17:50
  • @NicolBolas to clarify, i was using the std::minus functor from the header, I omitted namespaces for brevity – RoboCop87 Aug 24 '20 at 17:50
  • @NicolBolas my interpretation of the answers on that question lead me to disagree with your conclusion that they would not apply to bind_back. – RoboCop87 Aug 24 '20 at 17:52
  • 1
    @RoboCop87: It was rejected for lacking *compelling* use cases, not use cases in general. So where are the "compelling" use cases for it? As I said, this is usually something that's obvious to an experienced programmer. But the examples you've provided are not compelling. They are things that a user might sometimes desire to do. But they're not *compelling*. `bind_front` has compelling use cases just by virtue of turning a member pointer into an interface without the class member. C++ programmers do that far more often than using `std::minus`. – Nicol Bolas Aug 24 '20 at 17:54
  • 3
    @NicolBolas I think that should be an answer to the question rather a comment. If you could expound on the differences between compelling and desirable, I think that would be very helpful to the community of programmers at large. – RoboCop87 Aug 24 '20 at 17:57
  • @Barry: In the version before he clarified that he meant the standard library operator functors, and before I *edited* the post to match the clarification. – Nicol Bolas Aug 24 '20 at 18:04
  • @NicolBolas I think you misunderstood, my clarification was to the example I provided in an earlier comment where I showed a usage of std::transform – RoboCop87 Aug 24 '20 at 18:06
  • 4
    `std::bind_back` was added in C++23 (https://en.cppreference.com/w/cpp/utility/functional/bind_back) – Desmond Gold Mar 18 '22 at 01:49

0 Answers0