// Delay evaluation of the assert by making it dependent on a template parameter
static_assert(sizeof(ExprT) == -1, "Conversion between these types is not supported");
It seems to me that it would be a reasonable change to not let a static_assert(false) fire in template code unless the template is actually instantiated.
Are there any show-stoppers preventing such a change?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1bc49018-90f2-47e4-ad3b-ed657c39d8cc%40isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b647a6ab-5b4a-4f36-b392-3ab0884f274d%40isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMmfjbPv%2B0hEAbx6%3DRQR-Z3gX9BuOZ3P%2BDP_FuNKwwZZ6b_oFQ%40mail.gmail.com.
I can confirm I did this a lot in a previous library that I wrote.It's a common pattern where you want to tell the user that what they are trying to do will lead to wrong code, so you actually make a template that matches better in the you-used-it-wrong case and gives a friendly error (static-assert) message, instead of SFINAE-ing out and giving 48k of a template dump that no non-expert can parse into "oh, I should have tried to call this with a non-const object.".You can quote me if you write this paper. I'm all for it. There are no cases where I don't want to defer static_assert(false) in a template definition to instantiation time.On Fri, Oct 19, 2018 at 5:05 PM Brian Bi <bbi...@gmail.com> wrote:I think that it would be fine to special-case it, if you can provide a solid rationale. Static assertions are heavy-handed because they bypass SFINAE, and I've almost always found it preferable to avoid unconditional static assertions for this reason. If you are going to submit a paper, be sure to provide some good examples of when having the proposed construct be well-formed would significantly improve the code.My understanding is that the rule in [temp.res] is intended to prevent the compiler from being forced to tolerate provably nonsensical constructs that appear in a template. As far as I can tell, a static assert with false condition is not something that would make it hard for the compiler to continue, so this is something we could special-case.On Fri, Oct 19, 2018 at 10:32 AM Bengt Gustafsson <bengt.gu...@beamways.com> wrote:Well, you pointing at the rule I want to change as a motivation for not changing the rule does not lead very far. If I wasn't proposing a change to the language I would not be posting on this list.There is already special handling of the boolean expression in a static_assert compared to other constexpr boolean expressions: It causes a compilation error if false. It can't be a big deal for a compiler to defer the constexpr execution of this particular boolean expression to template instantiation time if encountered in template code.The example I gave (not by my hand) is typical of the trickery people employ to avoid this problem, which is ugly and hard to understand.The ideas you propose as alternatives have the drawback that they don't allow you to affix your own error message (which was the reason to add static_assert in the first place). Also there is no technique that works in all contexts where static_asserts work, so you'd have to think of how to get the effect each time.