[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:
Depends
is depended on by SERVER-36425 Use `unique_function` in `mongo::Future` Closed
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?

Generated at Thu Feb 08 04:40:38 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.