P1285R0 and type_traits hardening discussion
Jonathan Wakely
jwakely@redhat.com
Thu Apr 11 09:33:00 GMT 2019
On 11/04/19 12:18 +0300, Antony Polukhin wrote:
>On Wed, Apr 10, 2019, 23:43 Jonathan Wakely <jwakely@redhat.com> wrote:
>
>> On 10/04/19 23:25 +0300, Antony Polukhin wrote:
>> >2) The check does not do memoization of the result, so it may produce
>> >different results with the same template arguments. This works on GCC and
>> >Clang, but is this feature desired?
>>
>> It will only produce different results when UB has been detected,
>> right? In other words, if all such assertions pass, the results are
>> the same. If one fails because a type is incomplete at one point and
>> complete later we have an ODR violation, but that's OK because we've
>> already terminated compilation due to the failed assertion. Do I
>> understand correctly?
>>
>> I think that's OK as long as we only use the __is_size_known function
>> in static assertions. If we used it in other contexts, we'd have ODR
>> violations for valid code, which would be bad.
>>
>
>Yes, I was thinking in the same way.
>
>But some experiments showed that there is a difference:
>
>struct X;
>// produces an error, OK
>constexpr bool res1 = std::is_move_constructible<X>::value;
>
>struct X{};
>// With memoization produces an incorrect error, because
>// __is_size_konwn remebered the result for X.
>constexpr bool res2 = std::is_copy_constructible<X>::value;
>
>
>So without memoization the errors are produced only for the incorrect
>usages rather than for all the type triats usages after the first failure.
That seems fine. As long as we terminate compilation when there is at
least one undefined trait use, it's OK.
If users don't like the handling of later traits, they should fix the
first problem and try compiling again.
More information about the Libstdc++
mailing list