On Tue, 24 Mar 2026, 02:03 Jonathan Wakely, <cxx_at_[hidden]> wrote:

>
>
> On Tue, 24 Mar 2026, 01:52 Jonathan Wakely, <cxx_at_[hidden]> wrote:
>
>>
>>
>> On Tue, 24 Mar 2026, 01:19 Halalaluyafail3, <luigighiron_at_[hidden]>
>> wrote:
>>
>>> On Mon, Mar 23, 2026 at 9:06 PM Jonathan Wakely <cxx_at_[hidden]> wrote:
>>> >
>>> >
>>> >
>>> > On Tue, 24 Mar 2026, 00:34 Halalaluyafail3 via Std-Proposals, <
>>> std-proposals_at_[hidden]> wrote:
>>> >>
>>> >> N5032 Section 16.3.2.4 "Detailed specifications"
>>> [structure.specifications]
>>> >> Paragraph 3:
>>> >> > Mandates: the conditions that, if not met, render the program
>>> ill-formed.
>>> >>
>>> >> Consider the following program:
>>> >>
>>> >> #include<bit>
>>> >> decltype(std::bit_cast<void*>(^^::))x;
>>> >>
>>> >> Assume sizeof(void*)==sizeof(^^::) is true. Is this program
>>> ill-formed? It would
>>> >> seem that is the case, but existing implementations do not reject
>>> this.
>>> >
>>> >
>>> > You haven't instantiated the function template. The return type is
>>> clearly void* so checking it without odr-using the function might works,
>>> but is kinda dumb.
>>> >
>>> > In an uninstantiated template the condition is not necessarily checked.
>>>
>>> I do not see how the current wording supports such an interpretation.
>>> Note that
>>> std::declval is specified using the mandate "This function is not
>>> odr-used", is
>>> this redundant and could be reduced to "false is true" similar to the
>>> preconditions of std::unreachable?
>>>
>>
>> Do you really think trying to draw general conditions from the wording
>> for those two findings makes sense?
>>
>> Those tell functions cannot be evaluated ever in a valid program. There
>> are no specializations of declval that are usable, ever. And any call to
>> unreachable is a bug.
>>
>> Maybe they're special cases, which are not good examples of general
>> purpose wording.
>>
>
> If there's a defect here, it's that declval tries to use library
> specification wording to say "this is only valid in unscented contexts"
>

Thanks autocorrect.

They should say "unevaluated contexts".


and we should have a special case in core wording just for this function.
> But it didn't seem worth doing. We know what the spec means, and no
> implementation has ever tried to implement declval as a deleted function.
> That wouldn't work (and the spec doesn't say that an implementation must
> pick *either* static assert *or* deleted functions, and use that
> consistently for every Mandates).
>
> But that's ok because declval is a very weird special case.
>
> And unreachable is another weird special case, where wording that is
> suitable for other functions is used a little strangely because we don't
> have a good way to say "this is always a bug if evaluated".
>
> But that's not a general problem with the spec for Mandates.
>
>
>
>
>>
>>
>>
>>
>>> >
>>> >> The
>>> >> example that follows the quoted text suggests that two possible
>>> implementations
>>> >> of mandates are static_asserts and deleted overloads. For uses of
>>> mandates
>>> >> outside of templates it seems like deleting the function is the only
>>> way to
>>> >> implement the mandate.
>>> >
>>> >
>>> > Why?
>>>
>>> Since a static_assert failing there would immediately make the program
>>> ill-formed. The only way to delay that until its use would be =delete.
>>>
>>> >
>>> >> For uses of mandates inside of templates both options
>>> >> would be valid, and create differences in the validity of programs
>>> such the
>>> >> program above. Was it intended for both possibilities to be valid, or
>>> was it
>>> >> intended for this program to assuredly be ill-formed or well-formed?
>>> >
>>> >
>>> > I don't think it matters. If it mattered and the condition was
>>> supposed to be SFINAE testable, it would use Constraints not Mandates.
>>> >
>>> > Why would you ever need the code above to be portable?
>>>
>>> Not to say that requiring this would be useful, but it seems like intent
>>> is not
>>> currently reflected in how Mandates is specified.
>>>
>>> >
>>> >
>>> >>
>>> >> It seems like the uses of Mandates for the purposes of specifying
>>> deletion could
>>> >> be split up into a new "Deleted When" element, if the intent was to
>>> require one
>>> >> form be used. For example text_encoding uses mandates to require
>>> CHAR_BIT==8,
>>> >> that could realistically only be implemented as a deleted overload.
>>> Would it
>>> >> make sense to open a LWG issue for this?
>>> >
>>> >
>>> > I don't see a defect here.
>>> >
>>> >
>>> >
>>>
>>