Implementes P0356R5. Adds bind_front to functional.
I don't believe this patch implements the perfect forwarding call wrapper requirements laid out in the paper. Take a look at the not_fn implementation as an example of this (perhaps even generalize it's implementation to be used here as well).
Types don't need to be qualified. Only functions calls that potentially use ADL do.
No need to quality tuple.
I updated this patch to use a more generalized perfect forwarding call struct. I modeled it after not_fn and got a lot of help from @EricWF. I also updated not_fn to use this more generalized struct.
I added tests similar to not_fn's tests to ensure perfect forwarding functions properly. I also generalized the structs used in those tests so I would not have to duplicate code. I think these tests cover the perfect forwarding implementation, but I can add more if needed.
The return type of this function is not specified, it might be beneficial to make it a constexpr (though that would require other parts of this to be updated and might not work). Thoughts?
I am unsure of how to format the fail tests.
I am not sure why this was expected to throw. I think this can simply be moved (but I might be wrong).
More to come.
Formatting nit. Note how the other bits of code have three identical chunks of code, all aligned so that you could see that they were identical. Please do that here. See the code that you're replacing (lines 2815->17) for an example.
This line can be removed; if the compilation never succeeds.
This one too
Formatting nit. When ganging a bunch of static asserts, leave a space after the '(', so that the negations are easily visible. See test/std/utilities/meta/meta.unary/meta.unary.cat/nullptr.pass.cpp as an example.
There are a couple of bugs in this patch related to the value-categories we should (A) store, and (B) initialize the storage with.
The specification specifies both cases here: http://eel.is/c++draft/func.bind.front#1
Let me know if I can help interpret that.
Why is this different than below?
The standard library is not allowed to add constexpr as an extension.
Also the return type has nothing to do with the constexpr-ness of the function.
Why does at least one argument need to be provided?
Sure, it seems silly to std::bind_front no arguments, but I don't see anything in the standard forbidding it.
This doesn't correctly implement the value categories for the functor nor arguments.
The type we store is different from the types we're passed in.
This doesn't seem right.
It's probably related to the bug mentioned below.
It's expected to throw because the functor must be copied or moved into the not_fn wrapper. ThrowsOnCopy doesn't have a move constructor so its copy constructor is always used.
The reason this test isn't failing anymore is because of a bug in your implementation.
Missing the license header.
Missing header guards.
This needs inline now that it's in a header.
@EricWF, Thanks for the review :) I will try to apply those changes today.
For some reason, I thought I remembered reading something about that in the paper, but looking back at it I cannot find it. I will remove this.
I seem to have skipped over that part, my bad. Will fix.