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