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