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...




>> Maybe you could ask if U has a converting operator towards optional<T> instead. See for instance https://eel.is/c++draft/string.view#cons-12.5
> for a precedent.
>
> Sorry I'm missing some subtlety here, I don't understand the difference. Isn't that exactly what is_convertible_v does?
> (Also, did you mean 12.4 instead of 12.5? The latter seems unrelated.)

No, I meant 12.5:

> d.operator ​::​std​::​basic_string_view<charT, traits>() is not a valid expression.

basic_string_view got a converting constructor from a range in C++23.
Since this got added "after the fact" (basic_string_view itself is
C++17), there is the possibility that the input range already had a
conversion operator towards basic_string_view. (Example: std::string
itself!)

If that is the case, then adding basic_string_view's range constructor
would introduce an ambiguity, and break user code. The constructor has
therefore been constrained to exclude the possibility of the conversion
operator being present.

The point is that is_convertible_v<A, B> for two classes A and B can be
true for two distinct reasons:

1) A got an implicit conversion operator towards B, or
2) B got an implicit conversion constructor from A.

If they're both true the conversion is ambiguous. The provision for
basic_string_view that I linked blocks 2) by checking if 1) exists, and
therefore avoids introducing an ambiguity.

I guess this got noticed _right away_ for std::string_view's range
constructor because of std::string's conversion operator; but I was
wondering if the same thing could be done to constrain optional's
constructor and if that would solve your problem.

Also, does all of this apply to other classes, like std::expected?



>>> Is submitting a defect report appropriate? How might we proceed?
>>
>> This sounds borderline evolutionary. Maybe submit a paper to LEWG and they can forward it straight to LWG if they think it's a defect?
>
> Writing a paper does seem a big hammer for what seems like a trivial change. I guess I can consider that if this cannot be addressed in a more straightforward manner.

Well, you can try submitting a LWG issue

https://isocpp.org/std/submit-issue

but I wouldn't be surprised if LWG asks Library Evolution to confirm the
design, even if the "technical fix" is correct and straightforward.


>
>> (It would help if you add strong motivation on why you think it's a defect and not a new feature.)
>
> Basically when considering the optional(U&& v) constructor, if U already converts to optional<T>, making the constructor implicit is a redundant such conversion. And that redundant conversion always ends up ambiguous. Instead of achieving its goal of allowing the conversion, the constructor effectively prevents it.
>
> Reading through several optional related papers, it seems pretty clear this behavior was never the intent, and that it simply hadn't come up in the various scenarios examined.
>
> Fixing this also should not break any existing code, because any existing code that tries this fails to compile. It essentially only allows compiling code that could not previously compile. In that sense it's backward compatible.
>
>
> In terms of more general motivation, one use case for this is allowing templated code to return some default value as a function of the return type, without knowing the return type. Which happens to help better support an explicit error handling coding style (as opposed to using exceptions) with reduced noise.

See, the paper is writing itself :-)

--
Giuseppe D'Angelo