On Sun, Feb 5, 2023 at 5:52 AM Jens Maurer <jens.maurer_at_[hidden]> wrote:

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

Forgot about that, thanks!
Then it should not support volatile types, I'll fix it.

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