Why std::bind can’t be formally deprecated

Re:Why std::bind can’t be formally deprecated by kevingadd on Sunday July 02, 2017 @04:57PM (#14684296)

Am I misunderstanding or does this example from the post:

    auto g1 = std::bind(g, _1);
    auto f2 = std::bind(f, _1, g1, 4);
    f2(10); // calls f(10, g(10), 4);

Imply that function values in a bind's argument list are silently converted into function invocations? Doesn't this mean you can't pass functions around? Why would you break fundamental assumptions about the type system like this?

The way placeholder values seem to silently propagate across nested binds is also super gross. This stuff doesn't seem composable at all and it seems like it shouldn't have made it into any standard.

[ Parent | on HN ]

Re:Why std::bind can’t be formally deprecated by gpderetta on Monday July 03, 2017 @08:27AM (#14687742)

Bind is a stripped down version of boost.lambda [1] which is a generalized DSL for arbitrary expressions. Boost.lambda had, among other things, ways to protected nested binds calls and introduce new scopes for placeholders.

Adding special magic for nested binds (which is used about 0% of the time) was, in hindsight, a big mistake, but when bind was designed and added to the standard, lambda expressions were many years away, so any syntactic sugar that would ease the pain of higher order programming was very welcome.

[1] Although I don't recall who came first. Likely boost.bind was first, then boost.lambda improved on it and some of the improvements were fed back into bind. In fact boost.bind still has some features that std::bind doesn't have (and viceversa).

[ Parent | on HN ]

Re:Why std::bind can’t be formally deprecated by evincarofautumn on Sunday July 02, 2017 @07:06PM (#14684784)

No, if I understand your question. You can pass a function pointer or function object via bind, it’s just that the behaviour may be surprising if it’s the result of a bind.

[ Parent | on HN ]