Topic: Always defer evaluation of static_assert to
Author: Nicolas Lesser <blitzrakete@gmail.com>
Date: Fri, 19 Oct 2018 16:20:51 +0200
Raw View
--000000000000f8e6b40578959c1c
Content-Type: text/plain; charset="UTF-8"
The 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.
On Fri, Oct 19, 2018, 3:16 AM Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:
> It 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
> ever instantiated. A work around I have seen 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 an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@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
> <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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq3MY4dkqhgiSCQRqJh0GCu-APM-M458sk7HzYJdWwgZqw%40mail.gmail.com.
--000000000000f8e6b40578959c1c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div>The problem with this is that it would special case =
the condition of staric_assert.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">If the condition in a template is not value-dependent, and it eva=
luates to false, then the program is ill-formed. [temp.res]p8</div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><br>IMO the right solution would be t=
o 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 ins=
tantiation.</div><div dir=3D"auto"><br><div class=3D"gmail_quote" dir=3D"au=
to"><div dir=3D"ltr">On Fri, Oct 19, 2018, 3:16 AM Bengt Gustafsson <<a =
href=3D"mailto:bengt.gustafsson@beamways.com">bengt.gustafsson@beamways.com=
</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">It=
seems a recurring pattern that you try to use static_assert(false); in tem=
plate code to indicate that a template should not be instantiated, but this=
currently does not work as the assert fires before the template is ever in=
stantiated. A work around I have seen is:<div><br></div><div><div class=3D"=
m_-3695411137697019816added m_-3695411137697019816modified m_-3695411137697=
019816line" style=3D"background-color:rgb(235,242,249);font-size:12px;borde=
r-top-color:rgb(221,255,221)"><pre class=3D"m_-3695411137697019816CodeMirro=
r-line" style=3D"padding-right:4px;padding-left:4px;border-radius:0px;backg=
round:transparent;font-size:inherit;line-height:inherit;color:inherit;overf=
low:visible;font-variant-ligatures:contextual"><span style=3D"padding-right=
:0.1px"> <span class=3D"m_-3695411137697019816ediff-add" style=3D"ba=
ckground-color:rgb(151,242,149)">// Delay evaluation of the </span>assert<s=
pan class=3D"m_-3695411137697019816ediff-add" style=3D"background-color:rgb=
(151,242,149)"> by making it dependent on a template parameter</span></span=
></pre></div><div class=3D"m_-3695411137697019816added m_-36954111376970198=
16modified m_-3695411137697019816line m_-3695411137697019816commented" styl=
e=3D"font-size:12px;border-top-color:rgb(221,255,221)"><div class=3D"m_-369=
5411137697019816CodeMirror-gutter-wrapper" style=3D"background:none!importa=
nt;color:rgb(0,0,0);font-family:Arial,sans-serif;white-space:nowrap;border-=
width:initial!important;border-style:none!important"><div class=3D"m_-36954=
11137697019816CodeMirror-gutter-elt" style=3D"width:26px"><button class=3D"=
m_-3695411137697019816add-comment-trigger m_-3695411137697019816bitbucket-g=
utter-marker" title=3D"Add a comment on this line." style=3D"box-sizing:con=
tent-box;width:16px;height:17px;padding:0px 5px;border-width:0px;border-sty=
le:initial;border-top-color:rgb(221,255,221);border-right-color:initial;bor=
der-bottom-color:initial;border-left-color:initial;border-radius:0px;margin=
:0px;line-height:17px;vertical-align:top;background-color:rgb(221,255,221)"=
><span class=3D"m_-3695411137697019816aui-icon m_-3695411137697019816aui-ic=
on-small m_-3695411137697019816aui-iconfont-comment" style=3D"background-re=
peat:no-repeat;background-position:0px 0px;border-width:initial;border-styl=
e:none;display:inline-block;height:16px;text-align:left;vertical-align:text=
-top;width:16px;line-height:0;opacity:0;color:rgb(112,112,112)">This line h=
as a comment.</span><span class=3D"m_-3695411137697019816aui-icon m_-369541=
1137697019816aui-icon-small m_-3695411137697019816aui-iconfont-add-comment"=
style=3D"background-repeat:no-repeat;background-position:0px 0px;border-wi=
dth:initial;border-style:none;display:inline-block;height:16px;text-align:l=
eft;vertical-align:text-top;width:16px;line-height:0;opacity:0;color:rgb(11=
2,112,112)">Add a comment on this line.</span></button></div><div class=3D"=
m_-3695411137697019816CodeMirror-gutter-elt" style=3D"width:37px"><div clas=
s=3D"m_-3695411137697019816line-number m_-3695411137697019816line-number-fr=
om m_-3695411137697019816bitbucket-gutter-marker" style=3D"height:17px;font=
-family:monospace;color:rgb(51,51,51);width:37px;display:inline-block;text-=
align:right;vertical-align:top;border-top-color:rgb(221,255,221)">=C2=A0</d=
iv></div><div class=3D"m_-3695411137697019816CodeMirror-gutter-elt" style=
=3D"width:37px"><div class=3D"m_-3695411137697019816line-number m_-36954111=
37697019816line-number-to m_-3695411137697019816bitbucket-gutter-marker" st=
yle=3D"height:17px;font-family:monospace;color:rgb(51,51,51);width:37px;dis=
play:inline-block;text-align:right;vertical-align:top;border-top-color:rgb(=
221,255,221)">33</div></div><div class=3D"m_-3695411137697019816CodeMirror-=
gutter-elt" style=3D"width:20px"><div class=3D"m_-3695411137697019816line-n=
umber-marker m_-3695411137697019816line-locator m_-3695411137697019816bitbu=
cket-gutter-marker" style=3D"height:17px;font-family:monospace;color:rgb(51=
,51,51);width:20px;text-align:center;display:inline-block;vertical-align:to=
p;border-top-color:rgb(221,255,221)">+</div></div></div><pre class=3D"m_-36=
95411137697019816CodeMirror-line" style=3D"background:transparent;padding-r=
ight:4px;padding-left:4px;border-radius:0px;line-height:inherit;color:rgb(0=
,0,0);overflow:visible;font-variant-ligatures:contextual"><span style=3D"pa=
dding-right:0.1px"><span class=3D"m_-3695411137697019816ediff-add" style=3D=
"background-color:rgb(151,242,149)"> static_assert</span>(<span clas=
s=3D"m_-3695411137697019816ediff-change" style=3D"background-color:rgb(151,=
242,149)">sizeof(ExprT)</span> <span class=3D"m_-3695411137697019816ediff-c=
hange" style=3D"background-color:rgb(151,242,149)">=3D=3D</span> <span clas=
s=3D"m_-3695411137697019816ediff-add" style=3D"background-color:rgb(151,242=
,149)">-1, </span>"Conversion between these types is not supported&quo=
t;);</span></pre><pre class=3D"m_-3695411137697019816CodeMirror-line" style=
=3D"background:transparent;padding-right:4px;padding-left:4px;border-radius=
:0px;line-height:inherit;color:rgb(0,0,0);overflow:visible;font-variant-lig=
atures:contextual"><span style=3D"padding-right:0.1px"><br></span></pre><pr=
e class=3D"m_-3695411137697019816CodeMirror-line" style=3D"background:trans=
parent;padding-right:4px;padding-left:4px;border-radius:0px;line-height:inh=
erit;color:rgb(0,0,0);overflow:visible;font-variant-ligatures:contextual"><=
span style=3D"padding-right:0.1px">It seems to me that it would be a reason=
able change to not let a static_assert(false) fire in template code unless =
the template is actually instantiated.</span></pre><pre class=3D"m_-3695411=
137697019816CodeMirror-line" style=3D"background:transparent;padding-right:=
4px;padding-left:4px;border-radius:0px;line-height:inherit;color:rgb(0,0,0)=
;overflow:visible;font-variant-ligatures:contextual"><span style=3D"padding=
-right:0.1px"><br></span></pre><pre class=3D"m_-3695411137697019816CodeMirr=
or-line" style=3D"background:transparent;padding-right:4px;padding-left:4px=
;border-radius:0px;line-height:inherit;color:rgb(0,0,0);overflow:visible;fo=
nt-variant-ligatures:contextual"><span style=3D"padding-right:0.1px">Are th=
ere any show-stoppers preventing such a change?</span></pre></div></div></d=
iv>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1bc49018-90f2-47e4-ad3b-ed657c39d8cc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/1bc49018-90f2-47e4-ad3b-ed657c39d8cc%40isocpp.org</a>.<br>
</blockquote></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALmDwq3MY4dkqhgiSCQRqJh0GCu-APM-M458=
sk7HzYJdWwgZqw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq3MY4dkqhgi=
SCQRqJh0GCu-APM-M458sk7HzYJdWwgZqw%40mail.gmail.com</a>.<br />
--000000000000f8e6b40578959c1c--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Fri, 19 Oct 2018 08:32:10 -0700 (PDT)
Raw View
------=_Part_3533_494370343.1539963130414
Content-Type: multipart/alternative;
boundary="----=_Part_3534_586500904.1539963130414"
------=_Part_3534_586500904.1539963130414
Content-Type: text/plain; charset="UTF-8"
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.
Den fredag 19 oktober 2018 kl. 16:21:04 UTC+2 skrev Nicolas Lesser:
>
> The 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.
>
> On Fri, Oct 19, 2018, 3:16 AM Bengt Gustafsson <bengt.gu...@beamways.com
> <javascript:>> wrote:
>
>> It 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
>> ever instantiated. A work around I have seen 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 an
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> 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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.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.
------=_Part_3534_586500904.1539963130414
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Well, you pointing at the rule I want to change as a motiv=
ation for not changing the rule does not lead very far. If I wasn't pro=
posing a change to the language I would not be posting on this list.<div><b=
r></div><div>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 tem=
plate instantiation time if encountered in template code.</div><div><br></d=
iv><div>The example I gave (not by my hand) is typical of the trickery peop=
le employ to avoid this problem, which is ugly and hard to understand.</div=
><div><br></div><div>The ideas you propose as alternatives have the drawbac=
k 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 techn=
ique that works in all contexts where static_asserts work, so you'd hav=
e to think of how to get the effect each time.<br><br>Den fredag 19 oktober=
2018 kl. 16:21:04 UTC+2 skrev Nicolas Lesser:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"auto"><div>The problem with this is that it wou=
ld special case the condition of staric_assert.</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">If the condition in a template is not value-depende=
nt, and it evaluates to false, then the program is ill-formed. [temp.res]p8=
</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br>IMO the right solut=
ion would be to not use such a static_assert. You can always delete an over=
load, make an incomplete type, ... if you don't want people using that =
particular instantiation.</div><div dir=3D"auto"><br><div class=3D"gmail_qu=
ote" dir=3D"auto"><div dir=3D"ltr">On Fri, Oct 19, 2018, 3:16 AM Bengt Gust=
afsson <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"Mf0BfDQmCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascri=
pt:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;">bengt.gu...@beamways.com</a><wbr>> wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr">It 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 ever instantiated. A work around I have seen i=
s:<div><br></div><div><div style=3D"background-color:rgb(235,242,249);font-=
size:12px;border-top-color:rgb(221,255,221)"><pre style=3D"padding-right:4p=
x;padding-left:4px;border-radius:0px;background:transparent;font-size:inher=
it;line-height:inherit;color:inherit;overflow:visible"><span style=3D"paddi=
ng-right:0.1px"> <span style=3D"background-color:rgb(151,242,149)">/=
/ Delay evaluation of the </span>assert<span style=3D"background-color:rgb(=
151,242,149)"> by making it dependent on a template parameter</span></span>=
</pre></div><div style=3D"font-size:12px;border-top-color:rgb(221,255,221)"=
><div style=3D"background:none!important;color:rgb(0,0,0);font-family:Arial=
,sans-serif;white-space:nowrap;border-width:initial!important;border-style:=
none!important"><div style=3D"width:26px"><button title=3D"Add a comment on=
this line." style=3D"width:16px;min-height:17px;padding:0px 5px;border-wid=
th:0px;border-style:initial;border-top-color:rgb(221,255,221);border-right-=
color:initial;border-bottom-color:initial;border-left-color:initial;border-=
radius:0px;margin:0px;line-height:17px;vertical-align:top;background-color:=
rgb(221,255,221)"><span style=3D"background-repeat:no-repeat;background-pos=
ition:0px 0px;border-width:initial;border-style:none;display:inline-block;m=
in-height:16px;text-align:left;vertical-align:text-top;width:16px;line-heig=
ht:0;color:rgb(112,112,112)">This line has a comment.</span><span style=3D"=
background-repeat:no-repeat;background-position:0px 0px;border-width:initia=
l;border-style:none;display:inline-block;min-height:16px;text-align:left;ve=
rtical-align:text-top;width:16px;line-height:0;color:rgb(112,112,112)">Add =
a comment on this line.</span></button></div><div style=3D"width:37px"><div=
style=3D"min-height:17px;font-family:monospace;color:rgb(51,51,51);width:3=
7px;display:inline-block;text-align:right;vertical-align:top;border-top-col=
or:rgb(221,255,221)">=C2=A0</div></div><div style=3D"width:37px"><div style=
=3D"min-height:17px;font-family:monospace;color:rgb(51,51,51);width:37px;di=
splay:inline-block;text-align:right;vertical-align:top;border-top-color:rgb=
(221,255,221)">33</div></div><div style=3D"width:20px"><div style=3D"min-he=
ight:17px;font-family:monospace;color:rgb(51,51,51);width:20px;text-align:c=
enter;display:inline-block;vertical-align:top;border-top-color:rgb(221,255,=
221)">+</div></div></div><pre style=3D"background:transparent;padding-right=
:4px;padding-left:4px;border-radius:0px;line-height:inherit;color:rgb(0,0,0=
);overflow:visible"><span style=3D"padding-right:0.1px"><span style=3D"back=
ground-color:rgb(151,242,149)"> static_assert</span>(<span style=3D"=
background-color:rgb(151,242,149)">sizeof(ExprT)</span> <span style=3D"back=
ground-color:rgb(151,242,149)">=3D=3D</span> <span style=3D"background-colo=
r:rgb(151,242,149)">-1, </span>"Conversion between these types is not =
supported");</span></pre><pre style=3D"background:transparent;padding-=
right:4px;padding-left:4px;border-radius:0px;line-height:inherit;color:rgb(=
0,0,0);overflow:visible"><span style=3D"padding-right:0.1px"><br></span></p=
re><pre style=3D"background:transparent;padding-right:4px;padding-left:4px;=
border-radius:0px;line-height:inherit;color:rgb(0,0,0);overflow:visible"><s=
pan style=3D"padding-right:0.1px">It seems to me that it would be a reasona=
ble change to not let a static_assert(false) fire in template code unless t=
he template is actually instantiated.</span></pre><pre style=3D"background:=
transparent;padding-right:4px;padding-left:4px;border-radius:0px;line-heigh=
t:inherit;color:rgb(0,0,0);overflow:visible"><span style=3D"padding-right:0=
..1px"><br></span></pre><pre style=3D"background:transparent;padding-right:4=
px;padding-left:4px;border-radius:0px;line-height:inherit;color:rgb(0,0,0);=
overflow:visible"><span style=3D"padding-right:0.1px">Are there any show-st=
oppers preventing such a change?</span></pre></div></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" rel=3D"nofollow" target=3D"_blank" gdf-obfu=
scated-mailto=3D"Mf0BfDQmCQAJ" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" rel=3D"nofollo=
w" target=3D"_blank" gdf-obfuscated-mailto=3D"Mf0BfDQmCQAJ" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1bc49018-90f2-47e4-ad3b-ed657c39d8cc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/1bc49018-90f2-47e4-ad3b-ed657c39d8cc%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/1bc49018-90f2-47e4-ad3b-ed657c39d8cc%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/1bc49018-90f2-47e4-<wbr>ad3b-=
ed657c39d8cc%40isocpp.org</a><wbr>.<br>
</blockquote></div></div></div>
</blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b647a6ab-5b4a-4f36-b392-3ab0884f274d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b647a6ab-5b4a-4f36-b392-3ab0884f274d=
%40isocpp.org</a>.<br />
------=_Part_3534_586500904.1539963130414--
------=_Part_3533_494370343.1539963130414--
.
Author: Brian Bi <bbi5291@gmail.com>
Date: Fri, 19 Oct 2018 11:05:37 -0500
Raw View
--000000000000b6bdb7057897133d
Content-Type: text/plain; charset="UTF-8"
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.gustafsson@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.
>
> Den fredag 19 oktober 2018 kl. 16:21:04 UTC+2 skrev Nicolas Lesser:
>>
>> The 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.
>>
>> On Fri, Oct 19, 2018, 3:16 AM Bengt Gustafsson <bengt.gu...@beamways.com>
>> wrote:
>>
>>> It 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
>>> ever instantiated. A work around I have seen 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
>>> 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
>>> <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
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.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
> <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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.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.
--000000000000b6bdb7057897133d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I think that it would be fine to special-case it, if =
you can provide a solid rationale. Static assertions are heavy-handed becau=
se they bypass SFINAE, and I've almost always found it preferable to av=
oid unconditional static assertions for this reason. If you are going to su=
bmit a paper, be sure to provide some good examples of when having the prop=
osed construct be well-formed would significantly improve the code.</div><d=
iv><br></div><div dir=3D"ltr">My understanding is that the rule in [temp.re=
s] is intended to prevent the compiler from being forced to tolerate provab=
ly 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 ha=
rd for the compiler to continue, so this is something we could special-case=
..</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Oct 19=
, 2018 at 10:32 AM Bengt Gustafsson <<a href=3D"mailto:bengt.gustafsson@=
beamways.com">bengt.gustafsson@beamways.com</a>> wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr">Well, you pointing at the rule I w=
ant 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 post=
ing on this list.<div><br></div><div>There is already special handling of t=
he boolean expression in a static_assert compared to other constexpr boolea=
n expressions: It causes a compilation error if false. It can't be a bi=
g deal for a compiler to defer the constexpr execution of this particular b=
oolean expression to template instantiation time if encountered in template=
code.</div><div><br></div><div>The example I gave (not by my hand) is typi=
cal of the trickery people employ to avoid this problem, which is ugly and =
hard to understand.</div><div><br></div><div>The ideas you propose as alter=
natives have the drawback that they don't allow you to affix your own e=
rror 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_assert=
s work, so you'd have to think of how to get the effect each time.<br><=
br>Den fredag 19 oktober 2018 kl. 16:21:04 UTC+2 skrev Nicolas Lesser:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>The problem with =
this is that it would special case the condition of staric_assert.</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">If the condition in a template i=
s not value-dependent, and it evaluates to false, then the program is ill-f=
ormed. [temp.res]p8</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br>=
IMO the right solution would be to not use such a static_assert. You can al=
ways delete an overload, make an incomplete type, ... if you don't want=
people using that particular instantiation.</div><div dir=3D"auto"><br><di=
v class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr">On Fri, Oct 19, 2018,=
3:16 AM Bengt Gustafsson <<a rel=3D"nofollow">bengt.gu...@beamways.com<=
/a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">It =
seems a recurring pattern that you try to use static_assert(false); in temp=
late code to indicate that a template should not be instantiated, but this =
currently does not work as the assert fires before the template is ever ins=
tantiated. A work around I have seen is:<div><br></div><div><div style=3D"b=
ackground-color:rgb(235,242,249);font-size:12px;border-top-color:rgb(221,25=
5,221)"><pre style=3D"padding-right:4px;padding-left:4px;border-radius:0px;=
background:transparent;font-size:inherit;line-height:inherit;color:inherit;=
overflow:visible"><span style=3D"padding-right:0.1px"> <span style=
=3D"background-color:rgb(151,242,149)">// Delay evaluation of the </span>as=
sert<span style=3D"background-color:rgb(151,242,149)"> by making it depende=
nt on a template parameter</span></span></pre></div><div style=3D"font-size=
:12px;border-top-color:rgb(221,255,221)"><div style=3D"background:none!impo=
rtant;color:rgb(0,0,0);font-family:Arial,sans-serif;white-space:nowrap;bord=
er-width:initial!important;border-style:none!important"><div style=3D"width=
:26px"><button title=3D"Add a comment on this line." style=3D"width:16px;mi=
n-height:17px;padding:0px 5px;border-width:0px;border-style:initial;border-=
top-color:rgb(221,255,221);border-right-color:initial;border-bottom-color:i=
nitial;border-left-color:initial;border-radius:0px;margin:0px;line-height:1=
7px;vertical-align:top;background-color:rgb(221,255,221)"><span style=3D"ba=
ckground-repeat:no-repeat;background-position:0px 0px;border-width:initial;=
border-style:none;display:inline-block;min-height:16px;text-align:left;vert=
ical-align:text-top;width:16px;line-height:0;color:rgb(112,112,112)">This l=
ine has a comment.</span><span style=3D"background-repeat:no-repeat;backgro=
und-position:0px 0px;border-width:initial;border-style:none;display:inline-=
block;min-height:16px;text-align:left;vertical-align:text-top;width:16px;li=
ne-height:0;color:rgb(112,112,112)">Add a comment on this line.</span></but=
ton></div><div style=3D"width:37px"><div style=3D"min-height:17px;font-fami=
ly:monospace;color:rgb(51,51,51);width:37px;display:inline-block;text-align=
:right;vertical-align:top;border-top-color:rgb(221,255,221)">=C2=A0</div></=
div><div style=3D"width:37px"><div style=3D"min-height:17px;font-family:mon=
ospace;color:rgb(51,51,51);width:37px;display:inline-block;text-align:right=
;vertical-align:top;border-top-color:rgb(221,255,221)">33</div></div><div s=
tyle=3D"width:20px"><div style=3D"min-height:17px;font-family:monospace;col=
or:rgb(51,51,51);width:20px;text-align:center;display:inline-block;vertical=
-align:top;border-top-color:rgb(221,255,221)">+</div></div></div><pre style=
=3D"background:transparent;padding-right:4px;padding-left:4px;border-radius=
:0px;line-height:inherit;color:rgb(0,0,0);overflow:visible"><span style=3D"=
padding-right:0.1px"><span style=3D"background-color:rgb(151,242,149)"> =
static_assert</span>(<span style=3D"background-color:rgb(151,242,149)">=
sizeof(ExprT)</span> <span style=3D"background-color:rgb(151,242,149)">=3D=
=3D</span> <span style=3D"background-color:rgb(151,242,149)">-1, </span>&qu=
ot;Conversion between these types is not supported");</span></pre><pre=
style=3D"background:transparent;padding-right:4px;padding-left:4px;border-=
radius:0px;line-height:inherit;color:rgb(0,0,0);overflow:visible"><span sty=
le=3D"padding-right:0.1px"><br></span></pre><pre style=3D"background:transp=
arent;padding-right:4px;padding-left:4px;border-radius:0px;line-height:inhe=
rit;color:rgb(0,0,0);overflow:visible"><span style=3D"padding-right:0.1px">=
It seems to me that it would be a reasonable change to not let a static_ass=
ert(false) fire in template code unless the template is actually instantiat=
ed.</span></pre><pre style=3D"background:transparent;padding-right:4px;padd=
ing-left:4px;border-radius:0px;line-height:inherit;color:rgb(0,0,0);overflo=
w:visible"><span style=3D"padding-right:0.1px"><br></span></pre><pre style=
=3D"background:transparent;padding-right:4px;padding-left:4px;border-radius=
:0px;line-height:inherit;color:rgb(0,0,0);overflow:visible"><span style=3D"=
padding-right:0.1px">Are there any show-stoppers preventing such a change?<=
/span></pre></div></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1bc49018-90f2-47e4-ad3b-ed657c39d8cc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/1bc49018-90f2-47e4-ad3b-ed657c39d8cc%40isocpp.org</a>.<br>
</blockquote></div></div></div>
</blockquote></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b647a6ab-5b4a-4f36-b392-3ab0884f274d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b647a6ab-5b4a-=
4f36-b392-3ab0884f274d%40isocpp.org</a>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"l=
tr"><div><div dir=3D"ltr"><font color=3D"#c0c0c0"><i>Brian Bi</i></font><br=
><div></div><div></div><div></div></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAMmfjbPv%2B0hEAbx6%3DRQR-Z3gX9BuOZ3P=
%2BDP_FuNKwwZZ6b_oFQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMmfjbPv%2=
B0hEAbx6%3DRQR-Z3gX9BuOZ3P%2BDP_FuNKwwZZ6b_oFQ%40mail.gmail.com</a>.<br />
--000000000000b6bdb7057897133d--
.
Author: =?UTF-8?B?R2HFoXBlciBBxb5tYW4=?= <gasper.azman@gmail.com>
Date: Sat, 20 Oct 2018 12:09:14 +0100
Raw View
--0000000000008b42560578a70df3
Content-Type: text/plain; charset="UTF-8"
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 <bbi5291@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.gustafsson@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.
>>
>> Den fredag 19 oktober 2018 kl. 16:21:04 UTC+2 skrev Nicolas Lesser:
>>>
>>> The 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.
>>>
>>> On Fri, Oct 19, 2018, 3:16 AM Bengt Gustafsson <bengt.gu...@beamways.com>
>>> wrote:
>>>
>>>> It 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
>>>> ever instantiated. A work around I have seen 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
>>>> 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
>>>> <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
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.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
>> <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
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.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
> <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>
> .
>
--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkXNRQCJkPB2CgEKYAwtNk8-qejUrMftxSX%2BwLyoAsK8bA%40mail.gmail.com.
--0000000000008b42560578a70df3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I can confirm I did this a lot in a previous library that =
I wrote.<div><br></div><div>It's a common pattern where you want to tel=
l 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 o=
ut and giving 48k of a template dump that no non-expert can parse into &quo=
t;oh, I should have tried to call this with a non-const object.".</div=
><div><br></div><div>You can quote me if you write this paper. I'm all =
for it. There are no cases where I <i>don't</i> want to defer static_as=
sert(false) in a template definition to instantiation time.</div></div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Oct 19, 2018 at 5:05 PM=
Brian Bi <<a href=3D"mailto:bbi5291@gmail.com">bbi5291@gmail.com</a>>=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I th=
ink that it would be fine to special-case it, if you can provide a solid ra=
tionale. Static assertions are heavy-handed because they bypass SFINAE, and=
I've almost always found it preferable to avoid unconditional static a=
ssertions for this reason. If you are going to submit a paper, be sure to p=
rovide some good examples of when having the proposed construct be well-for=
med would significantly improve the code.</div><div><br></div><div dir=3D"l=
tr">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 con=
tinue, so this is something we could special-case.</div></div><br><div clas=
s=3D"gmail_quote"><div dir=3D"ltr">On Fri, Oct 19, 2018 at 10:32 AM Bengt G=
ustafsson <<a href=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_b=
lank">bengt.gustafsson@beamways.com</a>> wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">Well, you pointing at the rule I want to c=
hange 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 t=
his list.<div><br></div><div>There is already special handling of the boole=
an expression in a static_assert compared to other constexpr boolean expres=
sions: It causes a compilation error if false. It can't be a big deal f=
or a compiler to defer the constexpr execution of this particular boolean e=
xpression to template instantiation time if encountered in template code.</=
div><div><br></div><div>The example I gave (not by my hand) is typical of t=
he trickery people employ to avoid this problem, which is ugly and hard to =
understand.</div><div><br></div><div>The ideas you propose as alternatives =
have the drawback that they don't allow you to affix your own error mes=
sage (which was the reason to add static_assert in the first place). Also t=
here 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.<br><br>Den f=
redag 19 oktober 2018 kl. 16:21:04 UTC+2 skrev Nicolas Lesser:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"auto"><div>The problem with this is =
that it would special case the condition of staric_assert.</div><div dir=3D=
"auto"><br></div><div dir=3D"auto">If the condition in a template is not va=
lue-dependent, and it evaluates to false, then the program is ill-formed. [=
temp.res]p8</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br>IMO the =
right solution would be to not use such a static_assert. You can always del=
ete an overload, make an incomplete type, ... if you don't want people =
using that particular instantiation.</div><div dir=3D"auto"><br><div class=
=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr">On Fri, Oct 19, 2018, 3:16 A=
M Bengt Gustafsson <<a rel=3D"nofollow">bengt.gu...@beamways.com</a>>=
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">It seems a=
recurring pattern that you try to use static_assert(false); in template co=
de to indicate that a template should not be instantiated, but this current=
ly does not work as the assert fires before the template is ever instantiat=
ed. A work around I have seen is:<div><br></div><div><div style=3D"backgrou=
nd-color:rgb(235,242,249);font-size:12px;border-top-color:rgb(221,255,221)"=
><pre style=3D"padding-right:4px;padding-left:4px;border-radius:0px;backgro=
und:transparent;font-size:inherit;line-height:inherit;color:inherit;overflo=
w:visible"><span style=3D"padding-right:0.1px"> <span style=3D"backg=
round-color:rgb(151,242,149)">// Delay evaluation of the </span>assert<span=
style=3D"background-color:rgb(151,242,149)"> by making it dependent on a t=
emplate parameter</span></span></pre></div><div style=3D"font-size:12px;bor=
der-top-color:rgb(221,255,221)"><div style=3D"background:none!important;col=
or:rgb(0,0,0);font-family:Arial,sans-serif;white-space:nowrap;border-width:=
initial!important;border-style:none!important"><div style=3D"width:26px"><b=
utton title=3D"Add a comment on this line." style=3D"width:16px;min-height:=
17px;padding:0px 5px;border-width:0px;border-style:initial;border-top-color=
:rgb(221,255,221);border-right-color:initial;border-bottom-color:initial;bo=
rder-left-color:initial;border-radius:0px;margin:0px;line-height:17px;verti=
cal-align:top;background-color:rgb(221,255,221)"><span style=3D"background-=
repeat:no-repeat;background-position:0px 0px;border-width:initial;border-st=
yle:none;display:inline-block;min-height:16px;text-align:left;vertical-alig=
n:text-top;width:16px;line-height:0;color:rgb(112,112,112)">This line has a=
comment.</span><span style=3D"background-repeat:no-repeat;background-posit=
ion:0px 0px;border-width:initial;border-style:none;display:inline-block;min=
-height:16px;text-align:left;vertical-align:text-top;width:16px;line-height=
:0;color:rgb(112,112,112)">Add a comment on this line.</span></button></div=
><div style=3D"width:37px"><div style=3D"min-height:17px;font-family:monosp=
ace;color:rgb(51,51,51);width:37px;display:inline-block;text-align:right;ve=
rtical-align:top;border-top-color:rgb(221,255,221)">=C2=A0</div></div><div =
style=3D"width:37px"><div style=3D"min-height:17px;font-family:monospace;co=
lor:rgb(51,51,51);width:37px;display:inline-block;text-align:right;vertical=
-align:top;border-top-color:rgb(221,255,221)">33</div></div><div style=3D"w=
idth:20px"><div style=3D"min-height:17px;font-family:monospace;color:rgb(51=
,51,51);width:20px;text-align:center;display:inline-block;vertical-align:to=
p;border-top-color:rgb(221,255,221)">+</div></div></div><pre style=3D"backg=
round:transparent;padding-right:4px;padding-left:4px;border-radius:0px;line=
-height:inherit;color:rgb(0,0,0);overflow:visible"><span style=3D"padding-r=
ight:0.1px"><span style=3D"background-color:rgb(151,242,149)"> stati=
c_assert</span>(<span style=3D"background-color:rgb(151,242,149)">sizeof(Ex=
prT)</span> <span style=3D"background-color:rgb(151,242,149)">=3D=3D</span>=
<span style=3D"background-color:rgb(151,242,149)">-1, </span>"Convers=
ion between these types is not supported");</span></pre><pre style=3D"=
background:transparent;padding-right:4px;padding-left:4px;border-radius:0px=
;line-height:inherit;color:rgb(0,0,0);overflow:visible"><span style=3D"padd=
ing-right:0.1px"><br></span></pre><pre style=3D"background:transparent;padd=
ing-right:4px;padding-left:4px;border-radius:0px;line-height:inherit;color:=
rgb(0,0,0);overflow:visible"><span style=3D"padding-right:0.1px">It seems t=
o 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.</span>=
</pre><pre style=3D"background:transparent;padding-right:4px;padding-left:4=
px;border-radius:0px;line-height:inherit;color:rgb(0,0,0);overflow:visible"=
><span style=3D"padding-right:0.1px"><br></span></pre><pre style=3D"backgro=
und:transparent;padding-right:4px;padding-left:4px;border-radius:0px;line-h=
eight:inherit;color:rgb(0,0,0);overflow:visible"><span style=3D"padding-rig=
ht:0.1px">Are there any show-stoppers preventing such a change?</span></pre=
></div></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1bc49018-90f2-47e4-ad3b-ed657c39d8cc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/1bc49018-90f2-47e4-ad3b-ed657c39d8cc%40isocpp.org</a>.<br>
</blockquote></div></div></div>
</blockquote></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b647a6ab-5b4a-4f36-b392-3ab0884f274d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b647a6ab-5b4a-=
4f36-b392-3ab0884f274d%40isocpp.org</a>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
class=3D"m_2801100867198980096gmail_signature" data-smartmail=3D"gmail_sig=
nature"><div dir=3D"ltr"><div><div dir=3D"ltr"><font color=3D"#c0c0c0"><i>B=
rian Bi</i></font><br><div></div><div></div><div></div></div></div></div></=
div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAMmfjbPv%2B0hEAbx6%3DRQR-Z3gX9BuOZ3P=
%2BDP_FuNKwwZZ6b_oFQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAMmfjbPv%2B0hEAbx6%3DRQR-Z3gX9BuOZ3P%2BDP_FuNKwwZZ6b_oFQ%40mail=
..gmail.com</a>.<br>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkXNRQCJkPB2CgEKYAwtNk8-qejUrM=
ftxSX%2BwLyoAsK8bA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkXNRQ=
CJkPB2CgEKYAwtNk8-qejUrMftxSX%2BwLyoAsK8bA%40mail.gmail.com</a>.<br />
--0000000000008b42560578a70df3--
.
Author: pasa@lib.hu
Date: Sat, 20 Oct 2018 05:49:33 -0700 (PDT)
Raw View
------=_Part_4103_1677179569.1540039773577
Content-Type: multipart/alternative;
boundary="----=_Part_4104_395762146.1540039773577"
------=_Part_4104_395762146.1540039773577
Content-Type: text/plain; charset="UTF-8"
I completely agree with the motivation and the shown example looks like
another embarrassment.
Yes, it is just another entry on the list of victims from the
export-detour, but I think it stands out enough to be addressed as "special
case" until a better general way to force full instantiation-time
substitution emerges.
Is there a motivation to have a 1st phase static_assert evaluation in a
template? Maybe inside an if constexpr block.
As for specification, we already have like 4 pages describing what is
dependent in the template, adding one line for static_assert fells like a
drop in the ocean. Maybe can just use the value-dependent expression
section to state the condition part of static_assert is always such. Then
all the rest just falls in place.
--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fb40c88e-a16f-41e2-8361-bd98220f4809%40isocpp.org.
------=_Part_4104_395762146.1540039773577
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I completely agree with the motivation and the shown =
example looks like another embarrassment. <br></div><div><br></div><div>Yes=
, it is just another entry on the list of victims from the export-detour, b=
ut I think it stands out enough to be addressed as "special case"=
until a better general way to force full instantiation-time substitution e=
merges. <br></div><div><br></div><div>Is there a motivation to have a 1st p=
hase static_assert evaluation in a template?=C2=A0 Maybe inside an if const=
expr block. <br></div><div><br></div><div>As for specification, we already =
have like 4 pages describing what is dependent in the template, adding one =
line for static_assert fells like a drop in the ocean. Maybe can just use t=
he value-dependent expression section to state the condition part of static=
_assert is always such.=C2=A0 Then all the rest just falls in place.<br></d=
iv><div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fb40c88e-a16f-41e2-8361-bd98220f4809%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fb40c88e-a16f-41e2-8361-bd98220f4809=
%40isocpp.org</a>.<br />
------=_Part_4104_395762146.1540039773577--
------=_Part_4103_1677179569.1540039773577--
.
Author: inkwizytoryankes@gmail.com
Date: Sat, 20 Oct 2018 16:02:30 -0700 (PDT)
Raw View
------=_Part_4093_205763240.1540076550844
Content-Type: multipart/alternative;
boundary="----=_Part_4094_1227592267.1540076550844"
------=_Part_4094_1227592267.1540076550844
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Saturday, October 20, 2018 at 1:09:28 PM UTC+2, Ga=C5=A1per A=C5=BEman w=
rote:
>
> 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=
=20
> trying to do will lead to wrong code, so you actually make a template tha=
t=20
> matches better in the you-used-it-wrong case and gives a friendly error=
=20
> (static-assert) message, instead of SFINAE-ing out and giving 48k of a=20
> template dump that no non-expert can parse into "oh, I should have tried =
to=20
> call this with a non-const object.".
>
> You can quote me if you write this paper. I'm all for it. There are no=20
> cases where I *don't* want to defer static_assert(false) in a template=20
> definition to instantiation time.
>
> On Fri, Oct 19, 2018 at 5:05 PM Brian Bi <bbi...@gmail.com <javascript:>>=
=20
> wrote:
>
>> I think that it would be fine to special-case it, if you can provide a=
=20
>> solid rationale. Static assertions are heavy-handed because they bypass=
=20
>> SFINAE, and I've almost always found it preferable to avoid unconditiona=
l=20
>> static assertions for this reason. If you are going to submit a paper, b=
e=20
>> sure to provide some good examples of when having the proposed construct=
be=20
>> well-formed would significantly improve the code.
>>
>> My understanding is that the rule in [temp.res] is intended to prevent=
=20
>> the compiler from being forced to tolerate provably nonsensical construc=
ts=20
>> that appear in a template. As far as I can tell, a static assert with fa=
lse=20
>> condition is not something that would make it hard for the compiler to=
=20
>> continue, so this is something we could special-case.
>>
>> On Fri, Oct 19, 2018 at 10:32 AM Bengt Gustafsson <
>> bengt.gu...@beamways.com <javascript:>> wrote:
>>
>>> Well, you pointing at the rule I want to change as a motivation for not=
=20
>>> changing the rule does not lead very far. If I wasn't proposing a chang=
e to=20
>>> the language I would not be posting on this list.
>>>
>>> There is already special handling of the boolean expression in a=20
>>> static_assert compared to other constexpr boolean expressions: It cause=
s a=20
>>> compilation error if false. It can't be a big deal for a compiler to de=
fer=20
>>> the constexpr execution of this particular boolean expression to templa=
te=20
>>> instantiation time if encountered in template code.
>>>
>>> The example I gave (not by my hand) is typical of the trickery people=
=20
>>> 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=
=20
>>> allow you to affix your own error message (which was the reason to add=
=20
>>> static_assert in the first place). Also there is no technique that work=
s in=20
>>> all contexts where static_asserts work, so you'd have to think of how t=
o=20
>>> get the effect each time.
>>>
>>
I wondering why in first place we have current behavior? What is use case=
=20
where this is useful?
One place I could image is where you write unintendly code that can't=20
compile because you mix up condition but in 95% cases is impossible to=20
catch because it depend on template parameter.
Overall for me I would prefer to change this to proposed behavior that=20
assertions are only trigger when template is used, this is similar do how=
=20
`assert(false)` work, even compiler see that is impossible to fulfill but=
=20
it break only when code try execute it.
--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ca6d27fd-91b9-49a2-8012-b53a45f3bd24%40isocpp.or=
g.
------=_Part_4094_1227592267.1540076550844
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, October 20, 2018 at 1:09:28 PM UTC+2,=
Ga=C5=A1per A=C5=BEman wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr">I can confirm I did this a lot in a previous library that =
I wrote.<div><br></div><div>It's a common pattern where you want to tel=
l 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 o=
ut and giving 48k of a template dump that no non-expert can parse into &quo=
t;oh, I should have tried to call this with a non-const object.".</div=
><div><br></div><div>You can quote me if you write this paper. I'm all =
for it. There are no cases where I <i>don't</i> want to defer static_as=
sert(false) in a template definition to instantiation time.</div></div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Oct 19, 2018 at 5:05 PM=
Brian Bi <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"JtVAiVRqCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javasc=
ript:';return true;" onclick=3D"this.href=3D'javascript:';retur=
n true;">bbi...@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div>I think that it would be fine to special-case i=
t, 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 th=
e proposed construct be well-formed would significantly improve the code.</=
div><div><br></div><div dir=3D"ltr">My understanding is that the rule in [t=
emp.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 specia=
l-case.</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, =
Oct 19, 2018 at 10:32 AM Bengt Gustafsson <<a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"JtVAiVRqCQAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hr=
ef=3D'javascript:';return true;">bengt.gu...@beamways.com</a><wbr>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Well, y=
ou pointing at the rule I want to change as a motivation for not changing t=
he rule does not lead very far. If I wasn't proposing a change to the l=
anguage I would not be posting on this list.<div><br></div><div>There is al=
ready special handling of the boolean expression in a static_assert compare=
d 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 exe=
cution of this particular boolean expression to template instantiation time=
if encountered in template code.</div><div><br></div><div>The example I ga=
ve (not by my hand) is typical of the trickery people employ to avoid this =
problem, which is ugly and hard to understand.</div><div><br></div><div>The=
ideas you propose as alternatives have the drawback that they don't al=
low 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 c=
ontexts where static_asserts work, so you'd have to think of how to get=
the effect each time.<br></div></div></blockquote></div></blockquote></div=
></blockquote><div><br></div><div>I wondering why in first place we have cu=
rrent behavior? What is use case where this is useful?</div><div>One place =
I could image is where you write unintendly code that can't compile bec=
ause you mix up condition but in 95% cases is impossible to catch because i=
t depend on template parameter.</div><div>Overall for me I would prefer to =
change this to proposed behavior that assertions are only trigger when temp=
late is used, this is similar do how `assert(false)` work, even compiler se=
e that is impossible to fulfill but it break only when code try execute it.=
<br></div><div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ca6d27fd-91b9-49a2-8012-b53a45f3bd24%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ca6d27fd-91b9-49a2-8012-b53a45f3bd24=
%40isocpp.org</a>.<br />
------=_Part_4094_1227592267.1540076550844--
------=_Part_4093_205763240.1540076550844--
.