----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/53492/#review155677 -----------------------------------------------------------
I've thought about this before as well, since Future is a shared object, adding a non-const operator isn't very safe. There can be multiple sites holding this Future and it's not clear who has the ownership necessary to perform non-const operations. My thinking about this in the past was that we'd need to introduce an explicit type (e.g. OwnedFuture) in order to enforce that there is a single owner that can perform non-const operations, move out the underyling object, etc. - Benjamin Mahler On Nov. 4, 2016, 5:30 p.m., Benjamin Hindman wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/53492/ > ----------------------------------------------------------- > > (Updated Nov. 4, 2016, 5:30 p.m.) > > > Review request for mesos, Benjamin Mahler, Jie Yu, and Michael Park. > > > Repository: mesos > > > Description > ------- > > Added non-const operator-> to Future. > > > Diffs > ----- > > 3rdparty/libprocess/include/process/future.hpp > 175214a9090f8cc8241a81e535c87370102f3011 > > Diff: https://reviews.apache.org/r/53492/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Benjamin Hindman > >
