r215856 - Update for llvm api changes.

[David Blaikie]

On Tue, Aug 19, 2014 at 10:48 AM, Sean Silva <chisophugis at gmail.com> wrote:
>
>
>
> 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()

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
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>