However, even if it could be fixed up, I don't think it will get deprecated.
C++ is (rightly in my mind) extremely cautious about removing things -- it's easy to ignore std::bind, it's just a library function. On the other hand, I'd be annoyed if my perfectly working C++ code base I've been building over 10 years just broke one day. One thing I love about C++ and C is that I can leave my code for 5 or even 10 years, come back, and expect it to still work just fine.
Also, not being able to create an automated tool to rewrite someone's code is not the same as not being able to tell them how to fix the code themselves.
I originally learned that "deprecated" was meant to indicate that the language no longer promised to include that feature in a future version. So, it still works now, but this is your warning that you should be moving away from it.
The dictionary meaning which comes into play in the software maintenance use of "deprecated" is that "disapprove/disparage" one.
Something that will be removed because it is unfashionable, and being replaced by shiny new idioms, is "obsolescent". Rather than abruptly removing such features, we phase them through an obsolescence period.
Deprecated example: the C gets function (almost impossible to use without creating a security hole, now removed from ISO C).
Obsolescent example: bzero function. (Appears in tradtional BSD sockets networking code, superseded by memset).
It's a black stain on any code which uses it, old or new.
A neutral word for "going away" is "obsolescent".
It does however fix the basic problem of a complete program.
Hopefully, one day modules will fix this and we'll be able to link modules from different versions of C++ together, but I'm not holding my breath.
> which is likely working by accident, rather than design.
> At the time, it made some sense. But it makes reasoning about bind expressions difficult. Don’t do this.
> Example of fail code
Where do you get the idea the author likes it?! To me it reads more "it's stupid, but this edge case can't be trivially replaced and thus we can't just rip it out"
Indeed. std::bind seems to work more like a Lisp-ish macro than a function in this regard.
Essentially, in order to provide something that sort of feels like lambda functions, but entirely in templates, the placeholder arguments do not end up locked to a single expression--instead of returning something semantically like a function, std::bind returns something that might be better described as a partial syntax tree that happens to be something you can call as a function, at which point it is only then wrapped up as a function and all subexpression parameters are bound to arguments--and so if you bind something and include in it a bound function, that function is not passed as a value like you would expect: its parameter is hoisted and it becomes a call expression in the new bound composite. The author likes this behavior for some reason, but I can't figure out why it would ever be considered to be a feature and it is trivially simulated with lambdas (while the opposite is not true).