On Fri, 7 Feb 2025 at 11:39, Giuseppe D'Angelo via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hello,
>
> On 07/02/2025 05:31, Marc Edouard Gauthier wrote:
> > On 03/02/2025 12:33, Giuseppe D'Angelo via Std-Proposals wrote:
> >> Hello,
> >>
> >> On 03/02/2025 20:41, Marc Edouard Gauthier via Std-Proposals wrote:
> >>> The simplest fix appears to change this line of the standard:
> >>>
> >>> https://github.com/cplusplus/draft/blob/5bfd514aa5d9a19d1dd0f4e874412c
> >>> 210a1893ce/source/utilities.tex#L3538
> >>> <https://github.com/cplusplus/draft/blob/5bfd514aa5d9a19d1dd0f4e874412
> >>> c210a1893ce/source/utilities.tex#L3538>
> >>>
> >>> from:
> >>>
> >>> !is_convertible_v<U, T>
> >>>
> >>> to :
> >>>
> >>> !is_convertible_v<U, T> || is_convertible_v<U, optional<T>>
> >>>
> >>> Doing the associated edit on clang/llvm and glibc implementations of
> >>> std::optional appears to fix the issue.
> >>>
> >>> As a quick way to run a test suite, a similar edit of the TartanLLama
> >>> implementation of optional https://github.com/TartanLlama/optional
> >>> <https://github.com/TartanLlama/optional>
> >>>
> >>> also works, and passes its test suite.
> >>
> >> I'm not sure that this actually works, and it's not IFNDR template
> magic instead. In particular I'm uncomfortable with reading the value of
> `is_convertible_v<U, optional<T>>`, since that depends from the very
> constructor / explicit(bool) specifier in which you ask if that trait is
> true...
> >
> > Although not a proof, it certainly works fine with clang and GCC. I
> assume you mean "works" in a more general sense.
> > Perhaps these existing compilers work by simply taking care to avoid
> infinite recursion, and not considering a type actively being analyzed by
> necessity rather than standard mandate.
> >
> > is_convertible<From, To> is defined in terms of example return code
> which seems to only require implicit conversion.
>
> My concern is that you're using this trait from within the constraints /
> explicit(bool) of a converting constructor. Basically the output of the
> trait may influence the truthfulness of the trait itself, catch-22; I
> fear this sort of shenanigans falls under the general "don't do it"
> (IFNDR, or even better, the "good luck" provisions) for templates.
> I'd appreciate if you would get a core language expert to chime in and
> remove these fears...
>

I share those concerns.

is_convertible_v requires complete types, and optional<T> is not complete
here.

IIRC GCC does have some shortcuts in overload resolution that avoid
constraint recursion, which might be why it "works" for GCC, but that isn't
proof that it's not technically ill-formed; no diagnostic required.