r215856 - Update for llvm api changes.
Sean Silva
chisophugis at gmail.com
Tue Aug 19 10:48:09 PDT 2014
On Mon, Aug 18, 2014 at 11:15 PM, Kim Gräsman <kim.grasman at gmail.com> wrote:
> On Mon, Aug 18, 2014 at 1:25 AM, David Blaikie <dblaikie at gmail.com> wrote:
> > On Sun, Aug 17, 2014 at 3:20 PM, Rafael Espindola
> > <rafael.espindola at gmail.com> 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()
with an enable_if to remove it for non-movable types.
However, I personally I don't find the std::move(*x) to be that problematic.
-- Sean Silva
>
> - Kim
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140819/5c60bef8/attachment.html>
More information about the cfe-commits
mailing list