Lang Hames via llvm-dev
2016-Feb-23 20:07 UTC
[llvm-dev] [RFC] Error handling in LLVM libraries.
Hi Michael, Rafael, Pawel, Apologies for the delayed reply - I was out on vacation last week.> In fact I would actually support outright > replacing ErrorOr with this if it can be done safely, as I find the > name TypedErrorOr a bit long.I find the name awkward too. I'll leave these classes as TypedError and TypedErrorOr<T> when I submit the initial patch to llvm-commits, but please feel free to comment on the names in that review. If the proposal is adopted I think the eventual plan should be to move to 'Error' and 'ErrorOr<T>', or Error and Expected<T> (Pawel - I really like that suggestion - thanks!).> The main differences are > * This will hopefully be used. > * TypedErrorOr is really a TypedError or T. The situation before was notthat ErrorOr was std::error_code or T. I don't follow that second point. As I see it, TypedErrorOr<T> and ErrorOr<T> are identical except for two points: TypedError replaces std::error_code, and as a consequence TypedErrorOr is only movable, not copyable. Cheers, Lang. On Thu, Feb 18, 2016 at 7:40 AM, Paweł Bylica <llvm-dev at lists.llvm.org> wrote:> On Thu, Feb 18, 2016 at 4:36 PM Rafael Espíndola <llvm-dev at lists.llvm.org> > wrote: > >> > I like this idea in general. It's a better implementation of what >> > ErrorOr originally was before we removed the custom error support >> > because it wasn't used. In fact I would actually support outright >> > replacing ErrorOr with this if it can be done safely, as I find the >> > name TypedErrorOr a bit long. >> >> >> The main differences are >> * This will hopefully be used. >> * TypedErrorOr is really a TypedError or T. The situation before was >> not that ErrorOr was std::error_code or T. >> >> Since we are adding it, I would also support replacing every use of >> ErrorOr with TypedErrorOr and renaming it. >> > > Alternative name could be Expected<T> as proposed by Andrei Alexandrescu. > > >> >> Cheers, >> Rafael >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160223/7e6f9b90/attachment.html>
Rafael Espíndola via llvm-dev
2016-Feb-23 20:26 UTC
[llvm-dev] [RFC] Error handling in LLVM libraries.
>> The main differences are >> * This will hopefully be used. >> * TypedErrorOr is really a TypedError or T. The situation before was not >> that ErrorOr was std::error_code or T. > > I don't follow that second point. As I see it, TypedErrorOr<T> and > ErrorOr<T> are identical except for two points: TypedError replaces > std::error_code, and as a consequence TypedErrorOr is only movable, not > copyable.That is the case now. Sorry, Mchiael and I were talking about ancient history when ErrorOr<T> was *not* an std::error_code or T. Cheers, Rafael
Lang Hames via llvm-dev
2016-Feb-24 01:30 UTC
[llvm-dev] [RFC] Error handling in LLVM libraries.
Ahh - that makes sense. Thanks. :) - Lang. On Tue, Feb 23, 2016 at 12:26 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote:> >> The main differences are > >> * This will hopefully be used. > >> * TypedErrorOr is really a TypedError or T. The situation before was not > >> that ErrorOr was std::error_code or T. > > > > I don't follow that second point. As I see it, TypedErrorOr<T> and > > ErrorOr<T> are identical except for two points: TypedError replaces > > std::error_code, and as a consequence TypedErrorOr is only movable, not > > copyable. > > > That is the case now. Sorry, Mchiael and I were talking about ancient > history when ErrorOr<T> was *not* an std::error_code or T. > > Cheers, > Rafael >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160223/b97cbf34/attachment.html>