Functionally speaking, this does work but I want to create something more clear, and that does not explicitly depend on constexpr bools.

For example
if constexpr(1 == 0)
{
 static_assert(false, "Compile Error!");
}

Does not have the intended affect, in this case the static assert will always run and compilation will fail regardless. At least on MSVC 16.10.2

David Aaron Braun
519-680-9822
226-236-4898
da.braun1_at_[hidden]

-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Marcin Jaczewski via Std-Proposals
Sent: Friday, June 18, 2021 6:36 AM
To: std-proposals <std-proposals_at_lists.isocpp.org>
Cc: Marcin Jaczewski <marcinjaczewski86_at_gmail.com>
Subject: Re: [std-proposals] Static Failure - Custom Compile-Time Errors

pt., 18 cze 2021 o 11:19 chuanqi.xcq via Std-Proposals <std-proposals_at_lists.isocpp.org> napisał(a):
>
> > Whole problem here is that `static_assert` has a design goal to be
> > eager in evaluation of its condition. And changing this will reduce
> > its usefulness in that case.
>
> Out of curiousty, in what situation, changing this would reduce its usefulness?
>

`static_assert(false, "message");` should have the same behavior as
`static_assert(1 < 0, "message");` (otherwise we will add another corner case that will confuse people) And this condition could check some complex condition that depends on overall compilation state and not current template context.
And probably it is better to have this information as soon as possible, and this is a different use case to removing some corner cases.

`static_assert` could be interpreted as you can't use this library (require 8bit `char`) or library have fatal logic flaw `static_failure` or `static_assert_lazy` could be interpreted as you can't use this function (like trying call helper function for windows on linux) or you use this function incorrectly

> > Here are some data to consider:
> >
> > template<bool B>
> > void func() {
> > if constexpr (B) {
> > static_assert(false, "message");
> > }
> > }
> >
> > and
> >
> > template<bool B>
> > void func;
> >
> > template<>
> > void func<true>() {
> > static_assert(false, "message");
> > }
> >
> > template<>
> > void func<false>() {}
>
> Yeah, this is an example. And from my point of view, changing this
> would make the power of static_assert get weaker in `if constexpr`.
> But it is OK for me, from my experience for using static_assert, it seems OK to assert evaluate lazily (after instantiation).
> I am curious about if there is any realistic example tell the down side for lazily evaluate assert.
>
> Thanks,
> Chuanqi
>
> ------------------------------------------------------------------
> From:Jefferson Carpenter via Std-Proposals
> <std-proposals_at_lists.isocpp.org> Send Time:2021年6月18日(星期五) 16:09
> To:std-proposals <std-proposals_at_lists.isocpp.org> Cc:Jefferson
> Carpenter <jeffersoncarpenter2_at_[hidden]>
> Subject:Re: [std-proposals] Static Failure - Custom Compile-Time
> Errors
>
> On 6/18/2021 7:49 AM, chuanqi.xcq via Std-Proposals wrote:
> > Yeah, another question is that can we use 'static_assert(false, "string");' to replace the use case? I understand the current document and implementation wouldn't work.
> > But I mean, what if to change the semantics for static_assert to make `static_assert(false, "")` work for the use case you mentioned? It looks not bad to me, too.
>
> Here are some data to consider:
>
> template<bool B>
> void func() {
> if constexpr (B) {
> static_assert(false, "message");
> }
> }
>
> and
>
> template<bool B>
> void func;
>
> template<>
> void func<true>() {
> static_assert(false, "message");
> }
>
> template<>
> void func<false>() {}
>
> both fail to compile. So currently static_assert behaves similarly
> whether it is used with template specializations, or with `if
> constexpr` statements. (Even if the code in question is never
> instantiated)
> --
> Std-Proposals mailing list
> Std-Proposals_at_lists.isocpp.org
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]socpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals