Constraints on constructors sometimes depend on themselves #98
Description
In a project of mine, I'm using a lot of type erased wrappers. Those wrappers (e.g. ldgr::any_path in the error below) check for copy-constructibility of the wrapped type at construction.
For some reason, when put into an optional, this sometimes leads to a "satisfaction of constraint ... depends on itself" error on clang and libc++:
/home/jan/beman/optional26/optional.hpp:275:26: error: satisfaction of constraint 'detail::enable_forward_value<T, U>' depends on itself
275 | requires detail::enable_forward_value<T, U>;
| ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jan/beman/optional26/optional.hpp:275:18: note: while substituting template arguments into constraint expression here
275 | requires detail::enable_forward_value<T, U>;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/llvm-project/prefix/bin/../include/c++/v1/__type_traits/is_constructible.h:28:44: note: while checking constraint satisfaction for template 'optional<ldgr::any_path
>' required here
28 | inline constexpr bool is_constructible_v = __is_constructible(_Tp, _Args...);
| ^~~~~~~~~~~~~~~~~~
/llvm-project/prefix/bin/../include/c++/v1/__type_traits/is_constructible.h:28:44: note: while substituting deduced template arguments into function template 'option
al' [with U = beman::optional26::optional<ldgr::any_path>]
/prefix/bin/../include/c++/v1/__concepts/constructible.h:27:51: note: in instantiation of variable template specialization 'std::is_constructible_v<bema
n::optional26::optional<ldgr::any_path>, beman::optional26::optional<ldgr::any_path>>' requested here
27 | concept constructible_from = destructible<_Tp> && is_constructible_v<_Tp, _Args...>;
| ^
/prefix/bin/../include/c++/v1/__concepts/constructible.h:27:51: note: while substituting template arguments into constraint expression here
27 | concept constructible_from = destructible<_Tp> && is_constructible_v<_Tp, _Args...>;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~I managed to fix it by reordering the contraints and doing some std::is_same_v checks. It doesn't happen when I use libc++'s optional.