I can confirm I did this a lot in a previous library that I wrote.
call this with a non-const object.".
You can quote me if you write this paper. I'm all for it. There are no
definition to instantiation time.
Post by Brian BiI 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 <
Post by Bengt GustafssonWell, 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.
Post by Nicolas LesserThe problem with this is that it would special case the condition of
staric_assert.
If the condition in a template is not value-dependent, and it evaluates
to false, then the program is ill-formed. [temp.res]p8
IMO the right solution would be to not use such a static_assert. You can
always delete an overload, make an incomplete type, ... if you don't want
people using that particular instantiation.
Post by Bengt GustafssonIt seems a recurring pattern that you try to use static_assert(false);
in template code to indicate that a template should not be instantiated,
but this currently does not work as the assert fires before the template is
// Delay evaluation of the assert by making it dependent on a template parameter
This line has a comment.Add a comment on this line.
33
+
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
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
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1bc49018-90f2-47e4-ad3b-ed657c39d8cc%40isocpp.org?utm_medium=email&utm_source=footer>
.
--
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
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
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b647a6ab-5b4a-4f36-b392-3ab0884f274d%40isocpp.org?utm_medium=email&utm_source=footer>
.
--
*Brian Bi*
--
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
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
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMmfjbPv%2B0hEAbx6%3DRQR-Z3gX9BuOZ3P%2BDP_FuNKwwZZ6b_oFQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.