On Tue, Aug 19, 2014 at 10:48 AM, Sean Silva <[email protected]> wrote: > > > > On Mon, Aug 18, 2014 at 11:15 PM, Kim Gräsman <[email protected]> wrote: >> >> On Mon, Aug 18, 2014 at 1:25 AM, David Blaikie <[email protected]> wrote: >> > On Sun, Aug 17, 2014 at 3:20 PM, Rafael Espindola >> > <[email protected]> wrote: >> >> >> >> llvm::SourceMgr SM; >> >> - Stream YAMLStream(FileBufOrErr.get().release(), SM); >> >> + Stream YAMLStream(std::move(FileBufOrErr.get()), SM); >> > >> > Thought: this is actually one place where I more strongly prefer using >> > the pointer-like API of ErrorOr. Seeing "move(x.get())" makes me >> > twitch and think "is that moving a raw pointer? some mistake where the >> > user was trying to indicate transfer of ownership from a unique_ptr >> > and clearly failing". Whereas move(*x) seems clear/sort of better. >> >> I also did a double-take when I updated our tool and saw this. I >> considered std::move(*x), and I agree that it's less confusing, but I >> wonder if something more explicit could be done with ErrorOr to move >> out its value? A take() method, for example (I can't quite see clearly >> how it would play with move semantics for non-movable T's, exercise >> for the reader.) > > > Strawman: > > FooOrErr.takeByMove()
We've pretty consistently used "take" for "returns ownership/by-move" so just "take" or "takeValue" might suffice if we decide to add this. > with an enable_if to remove it for non-movable types. Potentially. > However, I personally I don't find the std::move(*x) to be that problematic. Likewise - doesn't sound like anyone's too confused by this. > > -- Sean Silva > >> >> >> - Kim >> _______________________________________________ >> cfe-commits mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
