r215856 - Update for llvm api changes.
dblaikie at gmail.com
Tue Aug 19 10:59:07 PDT 2014
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.)
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.
> 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
More information about the cfe-commits