{"push_id":2719322719,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"0b1134d2c269c9e6466f936798f72d0b49b21ec9","before":"41ed7dd908acb259b444ee9ce3959d7c9a4f609d","commits":[{"sha":"0b1134d2c269c9e6466f936798f72d0b49b21ec9","author":{"name":"Marshall Cline","email":"61f556da428a359e7bc1eb3d899b81cae276ed82@oculus.com"},"message":"remove lvalue-qual Future::get(...)\n\nSummary:\nThis is part of \"the great r-valuification of folly::Future\":\n\n* This is something we should do for safety in general.\n* Using lvalue-qualified `Future::get(...)` has caused some failures around D7840699 since lvalue-qualification hides that operation's move-out semantics - leads to some use of future operations that are really not correct, but are not obviously incorrect.\n* Problems with `Future::get(...) &`: it moves-out the result but doesn't invalidate the Future - the Future remains (technically) valid even though it actually is partially moved-out. Callers can subsequently access that moved-out result via things like `future.get()`, `future.result()`, `future.value()`, etc. - these access an already-moved-out result which is/can be surprising.\n* Reasons `Future::get(...) &&` is better: its semantics are more obvious and user-testable. It moves-out the Future, leaving it with `future.valid() == false`.\n* Note: `get(...)` refers to `get()` and `get(Duration)`.\n\nReviewed By: yfeldblum\n\nDifferential Revision: D8710296\n\nfbshipit-source-id: ae201af1928eb2f6a2897c9b7db884393b36b910","distinct":true,"url":"https://api.github.com/repos/facebook/folly/commits/0b1134d2c269c9e6466f936798f72d0b49b21ec9"}]}
{"actor":{"display_login":"facebook-github-bot"}}