Hi,

On 05/02/2023 13.36, Corentin Jabot via SG16 wrote:
> I also can't think of a single reason not to allow it, both because the wording is consistent with other places where we just want to say we don't care about CV qualifiers, and because disallowing here is just more opinionated special cases that ends up being (very) slightly more work for implementations, and arguably users, should anyone ever run into it (who might wonder why the language disallows the use of a constexpr volatile variable here specifically and anywhere else).

I disagree.

[expr.const] p5.9 expressly disallows access to volatile data in constant
expressions; why should static_assert be different?

Jens


> On Sun, Feb 5, 2023, 04:22 Daniel Krügler <daniel.kruegler_at_[hidden] <mailto:daniel.kruegler_at_[hidden]>> wrote:
>
> Hi,
>
> The paper
>
> https://isocpp.org/files/papers/P2741R1.pdf <https://isocpp.org/files/papers/P2741R1.pdf>
>
> suggests the following grammar extension
>
> static_assert (constant-expression , constant-expression ) ;
>
> and goes on to constrain it as follows:
>
> "If a second constant-expression Msg is provided:
> [..]
> - Msg.data() shall be a well-formed constant expression whose type is
> cv char* or cv char8_t*, and
> [..]"
>
> I have a hard time to understand the motivation for possibly volatile
> qualified sequences of char or char8_t in static_assert messages. The
> paper does never mention the word volatile as part of its motivation.
>
> I would like to ask whether this wording suggestion in regard to
> volatile support is meant seriously and what the use cases are for
> volatile* char or even const volatile char* messages?
>
> Thanks,
>
> - Daniel
>
>