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

Marek Kurdej via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Tue Mar 30 07:44:17 PDT 2021


curdeius planned changes to this revision.
curdeius added inline comments.


================
Comment at: libcxx/include/future:505-514
+#if _LIBCPP_STD_VER <= 14
 public:
+#endif
     future_error(error_code __ec);
-#if _LIBCPP_STD_VERS > 14
-    explicit future_error(future_errc _Ev) : logic_error(), __ec_(make_error_code(_Ev)) {}
+
+public:
+#if _LIBCPP_STD_VER > 14
----------------
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?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99567/new/

https://reviews.llvm.org/D99567



More information about the libcxx-commits mailing list