[llvm] [STLExtras] Introduce bind_{front, back}, [not_]equal_to (PR #175056)

[Ramkumar Ramachandra via llvm-commits]

artagnon wrote:

> Current implementation is ok to me if we apply the suggestion in [#175056 (comment)](https://github.com/llvm/llvm-project/pull/175056#discussion_r2674092082) and move them to "FunctionalExtras.h" or "STLFunctionalExtras.h".

I wonder why we need to std::move a value, when capturing an rvalue by reference is perfectly safe (see Ref links in previous comment)? As far as I can tell, the std::move doesn't perfect-forward either, so I'm inclined to keep the capture-by-reference for BindArgs? We can perfect-forward Fn though. Not sure why we would drop the variadic template either, as it costs us nothing extra, and we've included a test with multiple bind_{front,back} being used? I agree with the technical concern of a non-perfect "backport", but in practice, nearly all (or all) future usages of llvm::bind_{front,back} can be moved to std::bind_{front,back} when we upgrade the standard, easing a lot of pain, and minimizing churn? We've included a note saying that it's a non-perfect backport, but the only limitation is that llvm::bind_{front,back} cannot be used in all the places where std::bind_{front,back} could apply, not the other way around? The limitations of the backport are fairly esoteric for LLVM code, and I doubt there is much code in LLVM where llvm::bind_{front,back} doesn't apply due to the limitations?

I can move the functions to STLFunctionalExtras if we feel strongly about the non-perfect backport, but I'm not sure if the implementation itself is problematic? I did a lot of research before settling on this implementation.

https://github.com/llvm/llvm-project/pull/175056