[SERVER-35685] Vendor naios/function2 Created: 19/Jun/18 Updated: 19/Oct/18 Resolved: 27/Aug/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Mira Carey | Assignee: | ADAM Martin (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Sprint: | Platforms 2018-08-13, Platforms 2018-08-27 | ||||||||
| Participants: | |||||||||
| Description |
|
function2 offers a unique_function as well as a function_view, both would substantially improve the move only story for futures. Let's do the third party vendor. |
| Comments |
| Comment by Gregory McKeon (Inactive) [ 27/Aug/18 ] |
|
We're not using this due to a bug. |
| Comment by Mathias Stearn [ 23/Jul/18 ] |
|
Adding to next sprint and assigning to ADAM following discussion of imminent need (the workarounds we are already doing, like shared_ptr<Future<T>>, are terrible). The README only says it is tested with MSVC2017, so it may or may not work with 2015. If it doesn't, we'll need to wait until after the toolchain bump. |
| Comment by Mathias Stearn [ 23/Jul/18 ] |
|
I don't think we'd do a stdx::function using it, however I expect we'd replace many of uses of std::function that should support move-only callables with either fu2::unique_function or mongo::unique_function which would be fu2::function_base customized with our preferred settings. I think I'd start with the former, and only do the later if we really need to.
There is currently no std::unique_future in the C++20 draft. There are some proposals, but nothing has been approved yet. If one does land I wouldn't expect it to be substantially different from this. Also, since function types are usually implicitly interconvertable (since they are themselves callables), there is little harm to having something non standard. |
| Comment by Andrew Morrow (Inactive) [ 20/Jun/18 ] |
|
Looks like it is header only? If so, this seems pretty reasonable from a third party library perspective. Would our use of this extend to replacing std::function with a stdx::function again? Or do we only want this for the new types? How well do those new types align with C+17 or C+20 plans? |