[libcxx-commits] [PATCH] D99567: [libc++] Make future_error constructor standard-compliant.

Arthur O'Dwyer via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Tue Mar 30 07:53:42 PDT 2021

Quuxplusone added inline comments.

Comment at: libcxx/include/future:505-514
+#if _LIBCPP_STD_VER <= 14
     future_error(error_code __ec);
-#if _LIBCPP_STD_VERS > 14
-    explicit future_error(future_errc _Ev) : logic_error(), __ec_(make_error_code(_Ev)) {}
+#if _LIBCPP_STD_VER > 14
curdeius wrote:
> Quuxplusone wrote:
> > `make_error_code` should remain called via ADL; it's a customization point.
> > https://boostorg.github.io/outcome/motivation/plug_error_code.html
> > If your de-ADL'ed version passes the test suite, then we need more tests around this.
> > 
> > The pre-existing ctor sets up `logic_error(__ec.message())` appropriately, so we want to find a way of duplicating that behavior. Also, I recommend adding a test for the message under `test/libcxx/`!
> > 
> > I'm suggesting that there be a private constructor from `error_code` (to avoid calling the user's `make_error_code` twice), but that it be tagged with a private tag to prevent people from stumbling into it accidentally. Your current patch leaves the existing ctor in place, but marks it private in C++17 and later; I think that's more likely to lead to confusion.
> > ```
> > struct MyErrC { operator future_errc() const; operator error_code() const; };
> > auto err = std::future_error(MyErrC());
> > ```
> > https://godbolt.org/z/rzs6K5a16
> Concerning `make_error_code`, isn't it a customisation point in the ctor of `error_code` only? Here we know that we call it with `future_errc` argument and we should call std-provided overload, no?
Ah, true. Okay, I retract that objection: it doesn't matter whether we qualify it or not. I have no strong opinion on whether it's better to consistently unqualify `make_error_code` everywhere it appears, or to consistently qualify every call //except// those that require ADL for correctness.

  rG LLVM Github Monorepo



More information about the libcxx-commits mailing list