------=_Part_1726_26198339.1363732962929
Content-Type: text/plain; charset=ISO-8859-1

Here are my thoughts on Relaxing constraints on constexpr functions<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3597.html>
..

It's certainly a bold proposal. But I think it has some significant issues.

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3597.html

The proposal plays lip service to this issue, but only in that it mentions
that D has this functionality. That's wonderful for D. However, that says
far less for C++.

Implementing `constexpr` was not the easiest part of C++11 to be
implemented, for any of the vendors who have done so thus far. What you're
asking for is significantly more complex than that.

I would like to see some research into what it would take to be able to
actually implement this in a C++ compiler. Even if it's not a full
implementation, I would like to see more than just "D was able to do it"
when dealing with implement-ability questions.

*Underspecified*

When making a bold proposal like this, it's a good idea to make certain
that all of the corner cases are covered. That, if spec language is not
part of the proposal, that it could at least be sufficiently specific about
corner cases.

This is not the case here. For example, the proposal states that "an
attempt to violate type-safety" is not allowed in a `constexpr` function.
OK, fine; what does that mean, exactly? The following represents perfectly
legal C++ code:

int Function()
{
  X x;
  void *vp = static_cast<void*>(&x);

  X *y = static_cast<X*>(vp);

  return y.num;
}

Can this be made a `constexpr` function? Let's say that we decide that it
is legal. OK, fine; how do we deal with this perverse code:

constexpr int CastToY(void *vp)
{
  Y &y = static_cast<Y*>(vp);
  return y.num;
}

constexpr int Badness()
{
  X x;
  return CastToY(static_cast<void*>(&x));
}

constexpr int Goodness()
{
  Y y;
  return CastToY(static_cast<void*>(&y));
}

I don't fancy the compiler writer that would have to implement detection,
at compile time, which traces through uses of `Badness` or `Goodness` to
find out if they do the wrong thing.

And if this shouldn't be allowed... why not? Is casting to a `void*`
considered "an attempt to violate type-safety"? Is that the idea? If so,
this seems like a weak limitation, since this behavior is protected by the
standard. It is type-safe, so long as you do the right cast at the other
end.

And if this isn't allow, which part isn't allowed exactly? The casting to a
`void*` part or the casting from a `void*`?

I want to see more details and specifics regarding exactly what the
requirements on `constexpr` functions are. It doesn't need to be
spec-language, but it should be sufficiently detailed enough to know what
exactly is required of an implementation.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_1726_26198339.1363732962929
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Here are my thoughts on <a href=3D"http://www.open-std.org/JTC1/SC22/WG21/d=
ocs/papers/2013/n3597.html">Relaxing constraints on constexpr functions</a>=
..<br><br>It's certainly a bold proposal. But I think it has some significan=
t issues.<br><br>http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3=
597.html<br><br>The proposal plays lip service to this issue, but only in t=
hat it mentions that D has this functionality. That's wonderful for D. Howe=
ver, that says far less for C++.<br><br>Implementing `constexpr` was not th=
e easiest part of C++11 to be implemented, for any of the vendors who have =
done so thus far. What you're asking for is significantly more complex than=
 that.<br><br>I would like to see some research into what it would take to =
be able to actually implement this in a C++ compiler. Even if it's not a fu=
ll implementation, I would like to see more than just "D was able to do it"=
 when dealing with implement-ability questions.<br><br><b>Underspecified</b=
><br><br>When making a bold proposal like this, it's a good idea to make ce=
rtain that all of the corner cases are covered. That, if spec language is n=
ot part of the proposal, that it could at least be sufficiently specific ab=
out corner cases.<br><br>This is not the case here. For example, the propos=
al states that "an attempt to violate type-safety" is not allowed in a `con=
stexpr` function. OK, fine; what does that mean, exactly? The following rep=
resents perfectly legal C++ code:<br><br><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
 border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Function</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp;=
 X x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">vp </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">static_cast</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">void</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">*&gt;(&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>&nbs=
p; X </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">y </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">static_cast</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">X</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">*&gt;(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">vp</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">return</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> y</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">num</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">}</span></div></code></div><br>Can=
 this be made a `constexpr` function? Let's say that we decide that it is l=
egal. OK, fine; how do we deal with this perverse code:<br><br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" cl=
ass=3D"styled-by-prettify">CastToY</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
*</span><span style=3D"color: #000;" class=3D"styled-by-prettify">vp</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>&nbsp; Y </span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">y </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">static_cast</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">Y</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*&gt;(=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">vp</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> y</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">num</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">co=
nstexpr</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Badness</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>&nbsp; X x</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pretti=
fy">CastToY</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">static_c=
ast</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">*&gt;(&amp;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">x</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">));</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">constexpr</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">G=
oodness</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; Y y</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">CastToY</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">static_cast</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">void</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">*&gt;(&amp;</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify">y</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">));</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span>=
</div></code></div><br>I don't fancy the compiler writer that would have to=
 implement detection, at compile time, which traces through uses of `Badnes=
s` or `Goodness` to find out if they do the wrong thing.<br><br>And if this=
 shouldn't be allowed... why not? Is casting to a `void*` considered "an at=
tempt to violate type-safety"? Is that the idea? If so, this seems like a w=
eak limitation, since this behavior is protected by the standard. It is typ=
e-safe, so long as you do the right cast at the other end.<br><br>And if th=
is isn't allow, which part isn't allowed exactly? The casting to a `void*` =
part or the casting from a `void*`?<br><br>I want to see more details and s=
pecifics regarding exactly what the requirements on `constexpr` functions a=
re. It doesn't need to be spec-language, but it should be sufficiently deta=
iled enough to know what exactly is required of an implementation.<br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1726_26198339.1363732962929--

.

Nicol Bolas <jmckesson@gmail.com> writes:

[...]

| Implementing `constexpr` was not the easiest part of C++11 to be implemented,
| for any of the vendors who have done so thus far.

I originally implemented constexpr for GCC; I've seen far more challenging
implementation issues (in C++98 and C++03) than what I faced with
constexpr, even given the fact that g++ didn't have high level ASTs and
some internal very low-level representation needed to be "reverse
engineered"  -- but that is only because g++ lowered too fast and too
quickly useful information.

I do confess that an implementation with a more regular and more
principled representation and close enough to the C++ abstract machine
will have an easier time -- see for example what I did with the IPR.

There is a real meaningful discussion to be had about  relaxing
constraints on constexpr functions, but let's not start by blowing
issues out of proportion.

-- Gaby

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_686_27073766.1363738377478
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, March 19, 2013 4:42:02 PM UTC-7, Gabriel Dos Reis wrote:
>
> Nicol Bolas <jmck...@gmail.com <javascript:>> writes:
>
> [...]
>
> | Implementing `constexpr` was not the easiest part of C++11 to be
> implemented,
> | for any of the vendors who have done so thus far.
>
> I originally implemented constexpr for GCC; I've seen far more challenging
> implementation issues (in C++98 and C++03) than what I faced with
> constexpr, even given the fact that g++ didn't have high level ASTs and
> some internal very low-level representation needed to be "reverse
> engineered"  -- but that is only because g++ lowered too fast and too
> quickly useful information.
>
> I do confess that an implementation with a more regular and more
> principled representation and close enough to the C++ abstract machine
> will have an easier time -- see for example what I did with the IPR.
>
> There is a real meaningful discussion to be had about  relaxing
> constraints on constexpr functions, but let's not start by blowing
> issues out of proportion.
>
> -- Gaby
>

I don't mean to blow anything out of proportion. But as I *heard* it (so
take that for what it's worth), the Clang folks basically had to implement
a compile-time interpreter to make constexpr work. And the VC folks haven't
even attempted to implement it (though admittedly they're rather behind on
C++11 support in general). The Intel compiler only claims "Partial" support<http://software.intel.com/en-us/articles/c0x-features-supported-by-intel-c-compiler/>for it.

While that's far from definitive, it does suggest that it's not among the
easiest features in the world to implement. And one of the main reasons for
the current suite of limitations is to make it as easy to implement while
still being able to get reasonable functionality.

My main point is this: the paper doesn't *address* any of this. It just
glosses over the issue with a "D does it, so we should to" statement. I
want to see some real investigation into the implement-ability of this
feature.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_686_27073766.1363738377478
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, March 19, 2013 4:42:02 PM UTC-7, Gabriel Dos Reis wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">Nicol Bolas &lt;<a href=3D"ja=
vascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"r_E6C9a2yGoJ">jmck...=
@gmail.com</a>&gt; writes:
<br>
<br>[...]
<br>
<br>| Implementing `constexpr` was not the easiest part of C++11 to be impl=
emented,
<br>| for any of the vendors who have done so thus far.=20
<br>
<br>I originally implemented constexpr for GCC; I've seen far more challeng=
ing
<br>implementation issues (in C++98 and C++03) than what I faced with
<br>constexpr, even given the fact that g++ didn't have high level ASTs and
<br>some internal very low-level representation needed to be "reverse
<br>engineered" &nbsp;-- but that is only because g++ lowered too fast and =
too
<br>quickly useful information.
<br>
<br>I do confess that an implementation with a more regular and more
<br>principled representation and close enough to the C++ abstract machine
<br>will have an easier time -- see for example what I did with the IPR.
<br>
<br>There is a real meaningful discussion to be had about &nbsp;relaxing
<br>constraints on constexpr functions, but let's not start by blowing
<br>issues out of proportion.
<br>
<br>-- Gaby
<br></blockquote><div><br>I don't mean to blow anything out of proportion. =
But as I <i>heard</i> it (so take that for what it's worth), the Clang folk=
s basically had to implement a compile-time interpreter to make constexpr w=
ork. And the VC folks haven't even attempted to implement it (though admitt=
edly they're rather behind on C++11 support in general). The Intel compiler=
 only <a href=3D"http://software.intel.com/en-us/articles/c0x-features-supp=
orted-by-intel-c-compiler/">claims "Partial" support</a> for it.<br><br>Whi=
le that's far from definitive, it does suggest that it's not among the easi=
est features in the world to implement. And one of the main reasons for the=
 current suite of limitations is to make it as easy to implement while stil=
l being able to get reasonable functionality.<br><br>My main point is this:=
 the paper doesn't <i>address</i> any of this. It just glosses over the iss=
ue with a "D does it, so we should to" statement. I want to see some real i=
nvestigation into the implement-ability of this feature.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_686_27073766.1363738377478--

.

--20cf3071c6b042265304d852839c
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 19, 2013 at 5:12 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Tuesday, March 19, 2013 4:42:02 PM UTC-7, Gabriel Dos Reis wrote:
>
>> Nicol Bolas <jmck...@gmail.com> writes:
>>
>> [...]
>>
>> | Implementing `constexpr` was not the easiest part of C++11 to be
>> implemented,
>> | for any of the vendors who have done so thus far.
>>
>> I originally implemented constexpr for GCC; I've seen far more
>> challenging
>> implementation issues (in C++98 and C++03) than what I faced with
>> constexpr, even given the fact that g++ didn't have high level ASTs and
>> some internal very low-level representation needed to be "reverse
>> engineered"  -- but that is only because g++ lowered too fast and too
>> quickly useful information.
>>
>> I do confess that an implementation with a more regular and more
>> principled representation and close enough to the C++ abstract machine
>> will have an easier time -- see for example what I did with the IPR.
>>
>> There is a real meaningful discussion to be had about  relaxing
>> constraints on constexpr functions, but let's not start by blowing
>> issues out of proportion.
>>
>> -- Gaby
>>
>
> I don't mean to blow anything out of proportion. But as I *heard* it (so
> take that for what it's worth), the Clang folks basically had to implemen=
t
> a compile-time interpreter to make constexpr work.
>

As the person who implemented this for Clang (and the author of the paper
in question), I'd like to address this. Yes, we have a compile-time
interpreter, and C++ is a large language with lots of different expression
forms and types, and handling all the combinations of these took time. But
the larger reason for the time cost was split between:

1) The core language around constexpr was changing as it was being
implemented, partly due to issues uncovered by my implementation work.
2) Core issue 1313: this requires a constexpr implementation to catch *all*
(explicit and implicit) undefined behavior which occurs during constant
expression evaluation.
3) constexpr support requires, in essence, a denotational semantics for the
constant-expression fragment of C++ -- for instance, what really *is* a
pointer, and how much information do you actually need to track to know
whether an operation on one has undefined behavior?

The second and third issues don't particularly affect this proposal (the
statement language of C++ adds little over the expression language in these
areas). Some amount of work will be required to detect unsequenced
modification and use of variables within a constant expression evaluation,
but not a great deal. And I'm hopeful that the language won't be so much of
a moving target this time around, since the semantic impact of permitting
statements is more constrained than that of permitting almost arbitrary
expressions, as C++11 did.


> While that's far from definitive, it does suggest that it's not among the
> easiest features in the world to implement. And one of the main reasons f=
or
> the current suite of limitations is to make it as easy to implement while
> still being able to get reasonable functionality.
>
> My main point is this: the paper doesn't *address* any of this. It just
> glosses over the issue with a "D does it, so we should to" statement.
>

That's a mischaracterization; "D does it" is not used as motivation for the
feature; it's used to demonstrate that the feature can be implemented in a
language with semantics which are substantially similar to C++'s.


> I want to see some real investigation into the implement-ability of this
> feature.
>

FYI, I've implemented some of it already, but not enough that I felt it was
worth including my implementation experience in the paper. I'm hopeful that
I'll have a full implementation in time for the meeting.

In reply to your original email:

On Tue, Mar 19, 2013 at 3:42 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> When making a bold proposal like this, it's a good idea to make certain
> that all of the corner cases are covered. That, if spec language is not
> part of the proposal, that it could at least be sufficiently specific abo=
ut
> corner cases.
>

Yes, I had intended to include wording changes in the paper which would
have clarified some of these cases, but I did not complete them in time for
the mailing.


> This is not the case here. For example, the proposal states that "an
> attempt to violate type-safety" is not allowed in a `constexpr` function.
> OK, fine; what does that mean, exactly?


It means (and I'm sorry that I didn't state this in the paper) the existing
set of constexpr rules which prevent violations of type-safety. For
instance:


> The following represents perfectly legal C++ code:
>
> int Function()
> {
>   X x;
>   void *vp =3D static_cast<void*>(&x);
>
>   X *y =3D static_cast<X*>(vp);
>
>   return y.num;
> }
>
> Can this be made a `constexpr` function?


No; static_cast from void* remains invalid in constant expression
evaluation.


> Let's say that we decide that it is legal. OK, fine; how do we deal with
> this perverse code:
>
> constexpr int CastToY(void *vp)
> {
>   Y &y =3D static_cast<Y*>(vp);
>   return y.num;
> }
>
> constexpr int Badness()
> {
>   X x;
>   return CastToY(static_cast<void*>(&x));
> }
>
> constexpr int Goodness()
> {
>   Y y;
>   return CastToY(static_cast<void*>(&y));
> }
>
> I don't fancy the compiler writer that would have to implement detection,
> at compile time, which traces through uses of `Badness` or `Goodness` to
> find out if they do the wrong thing.
>
> And if this shouldn't be allowed... why not? Is casting to a `void*`
> considered "an attempt to violate type-safety"? Is that the idea? If so,
> this seems like a weak limitation, since this behavior is protected by th=
e
> standard. It is type-safe, so long as you do the right cast at the other
> end.
>
> And if this isn't allow, which part isn't allowed exactly? The casting to
> a `void*` part or the casting from a `void*`?
>

In addition to the cast from void*, attempting to access a member of type Y
through a glvalue which doesn't refer to an object of type Y has undefined
behavior, and is therefore banned. Note that your question applies equally
well in C++11:

constexpr int CastToY(void *p) { return static_cast<Y*>(p)->n; }
constexpr int Badness(X x) { return CastToY(static_cast<void*>(&x)); }
constexpr int Goodness(Y y) { return CastToY(static_cast<void*>(&y)); }

And then note that constexpr implementations in C++11 already have to be
able to perform this kind of type check, if instead of casting from X* and
Y* to void* and back, you instead cast from X* / Y* to some common base
class of X and Y:

struct Void {};
struct X : Void { int n; };
struct Y : Void { int n; };
constexpr int CastToY(Void *p) { return static_cast<Y*>(p)->n; }
constexpr int Badness(X x) { return CastToY(static_cast<Void*>(&x)); }
constexpr int Goodness(Y y) { return CastToY(static_cast<Void*>(&y)); }
constexpr int k1 =3D Goodness(Y()); // ok
constexpr int k2 =3D Badness(X()); // error

GCC says:

<stdin>: At global scope:
<stdin>:7:30:   in constexpr expansion of =91Badness(X{0})=92
<stdin>:5:67:   in constexpr expansion of =91CastToY(((Void*)(& x)))=92
<stdin>:7:30: error: accessing value of =91X{0}=92 through a =91Y=92 glvalu=
e in a
constant expression

Clang says:

<stdin>:7:15: error: constexpr variable 'k' must be initialized by a
constant expression
constexpr int k =3D Badness(X());
              ^   ~~~~~~~~~~~~
<stdin>:4:41: note: cannot cast object of dynamic type 'X' to type 'Y'
constexpr int CastToY(Void *p) { return static_cast<Y*>(p)->n; }
                                        ^
<stdin>:5:37: note: in call to 'CastToY(&x)'
constexpr int Badness(X x) { return CastToY(static_cast<Void*>(&x)); }
                                    ^
<stdin>:7:19: note: in call to 'Badness({{}, 0})'
constexpr int k =3D Badness(X());
                  ^

I want to see more details and specifics regarding exactly what the
> requirements on `constexpr` functions are. It doesn't need to be
> spec-language, but it should be sufficiently detailed enough to know what
> exactly is required of an implementation.


Here's my current draft of the suggested wording:

https://github.com/zygoloid/cplusplus/compare/master...liberal-constexpr

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



--20cf3071c6b042265304d852839c
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 19, 2013 at 5:12 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=
=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&g=
t;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">
On Tuesday, March 19, 2013 4:42:02 PM UTC-7, Gabriel Dos Reis wrote:<br><di=
v class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Nicol Bolas &lt;<a>j=
mck...@gmail.com</a>&gt; writes:
<br>
<br>[...]
<br>
<br>| Implementing `constexpr` was not the easiest part of C++11 to be impl=
emented,
<br>| for any of the vendors who have done so thus far.=20
<br>
<br>I originally implemented constexpr for GCC; I&#39;ve seen far more chal=
lenging
<br>implementation issues (in C++98 and C++03) than what I faced with
<br>constexpr, even given the fact that g++ didn&#39;t have high level ASTs=
 and
<br>some internal very low-level representation needed to be &quot;reverse
<br>engineered&quot; =A0-- but that is only because g++ lowered too fast an=
d too
<br>quickly useful information.
<br>
<br>I do confess that an implementation with a more regular and more
<br>principled representation and close enough to the C++ abstract machine
<br>will have an easier time -- see for example what I did with the IPR.
<br>
<br>There is a real meaningful discussion to be had about =A0relaxing
<br>constraints on constexpr functions, but let&#39;s not start by blowing
<br>issues out of proportion.
<br>
<br>-- Gaby
<br></blockquote></div><div><br>I don&#39;t mean to blow anything out of pr=
oportion. But as I <i>heard</i> it (so take that for what it&#39;s worth), =
the Clang folks basically had to implement a compile-time interpreter to ma=
ke constexpr work.</div>
</blockquote><div><br></div><div>As the person who implemented this for Cla=
ng (and the author of the paper in question), I&#39;d like to address this.=
 Yes, we have a compile-time interpreter, and C++ is a large language with =
lots of different expression forms and types, and handling all the combinat=
ions of these took time. But the larger reason for the time cost was split =
between:</div>
<div><br></div><div>1) The core language around constexpr was changing as i=
t was being implemented, partly due to issues uncovered by my implementatio=
n work.</div><div>2) Core issue 1313: this requires a constexpr implementat=
ion to catch *all* (explicit and implicit) undefined behavior which occurs =
during constant expression evaluation.</div>
<div>3) constexpr support requires, in essence, a denotational semantics fo=
r the constant-expression fragment of C++ -- for instance, what really *is*=
 a pointer, and how much information do you actually need to track to know =
whether an operation on one has undefined behavior?</div>
<div><br></div><div>The second and third issues don&#39;t particularly affe=
ct this proposal (the statement language of C++ adds little over the expres=
sion language in these areas). Some amount of work will be required to dete=
ct unsequenced modification and use of variables within a constant expressi=
on evaluation, but not a great deal. And I&#39;m hopeful that the language =
won&#39;t be so much of a moving target this time around, since the semanti=
c impact of permitting statements is more constrained than that of permitti=
ng almost arbitrary expressions, as C++11 did.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div>While that&#39;s far from=
 definitive, it does suggest that it&#39;s not among the easiest features i=
n the world to implement. And one of the main reasons for the current suite=
 of limitations is to make it as easy to implement while still being able t=
o get reasonable functionality.<br>
<br>My main point is this: the paper doesn&#39;t <i>address</i> any of this=
.. It just glosses over the issue with a &quot;D does it, so we should to&qu=
ot; statement.</div></blockquote><div><br></div><div>That&#39;s a mischarac=
terization; &quot;D does it&quot; is not used as motivation for the feature=
; it&#39;s used to demonstrate that the feature can be implemented in a lan=
guage with semantics which are substantially similar to C++&#39;s.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div>I want to see some real i=
nvestigation into the implement-ability of this feature.</div></blockquote>=
<div>
<br></div><div>FYI, I&#39;ve implemented some of it already, but not enough=
 that I felt it was worth including my implementation experience in the pap=
er. I&#39;m hopeful that I&#39;ll have a full implementation in time for th=
e meeting.</div>
<div><br></div><div>In reply to your original email:</div><div><br></div><d=
iv>On Tue, Mar 19, 2013 at 3:42 PM, Nicol Bolas=A0<span dir=3D"ltr">&lt;<a =
href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</=
a>&gt;</span>=A0wrote:<br>
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204=
);border-left-style:solid;padding-left:1ex">When making a bold proposal lik=
e this, it&#39;s a good idea to make certain that all of the corner cases a=
re covered. That, if spec language is not part of the proposal, that it cou=
ld at least be sufficiently specific about corner cases.<br>
</blockquote><div><br></div><div>Yes, I had intended to include wording cha=
nges in the paper which would have clarified some of these cases, but I did=
 not complete them in time for the mailing.</div><div>=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex">
This is not the case here. For example, the proposal states that &quot;an a=
ttempt to violate type-safety&quot; is not allowed in a `constexpr` functio=
n. OK, fine; what does that mean, exactly?</blockquote><div><br></div><div>
It means (and I&#39;m sorry that I didn&#39;t state this in the paper) the =
existing set of constexpr rules which prevent violations of type-safety. Fo=
r instance:</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204=
,204);border-left-style:solid;padding-left:1ex">
 The following represents perfectly legal C++ code:<br><br><div style=3D"ba=
ckground-color:rgb(250,250,250);border:1px solid rgb(187,187,187);word-wrap=
:break-word"><code><span style=3D"color:rgb(0,0,136)">int</span>=A0<span st=
yle=3D"color:rgb(102,0,102)">Function</span><span style=3D"color:rgb(102,10=
2,0)">()</span><br>
<span style=3D"color:rgb(102,102,0)">{</span><br>=A0 X x<span style=3D"colo=
r:rgb(102,102,0)">;</span><br>=A0=A0<span style=3D"color:rgb(0,0,136)">void=
</span>=A0<span style=3D"color:rgb(102,102,0)">*</span>vp=A0<span style=3D"=
color:rgb(102,102,0)">=3D</span>=A0<span style=3D"color:rgb(0,0,136)">stati=
c_cast</span><span style=3D"color:rgb(102,102,0)">&lt;</span><span style=3D=
"color:rgb(0,0,136)">void</span><span style=3D"color:rgb(102,102,0)">*&gt;(=
&amp;</span>x<span style=3D"color:rgb(102,102,0)">);</span><br>
<br>=A0 X=A0<span style=3D"color:rgb(102,102,0)">*</span>y=A0<span style=3D=
"color:rgb(102,102,0)">=3D</span>=A0<span style=3D"color:rgb(0,0,136)">stat=
ic_cast</span><span style=3D"color:rgb(102,102,0)">&lt;</span>X<span style=
=3D"color:rgb(102,102,0)">*&gt;(</span>vp<span style=3D"color:rgb(102,102,0=
)">);</span><br>
<br>=A0=A0<span style=3D"color:rgb(0,0,136)">return</span>=A0y<span style=
=3D"color:rgb(102,102,0)">.</span>num<span style=3D"color:rgb(102,102,0)">;=
</span><br><span style=3D"color:rgb(102,102,0)">}</span></code></div><br>Ca=
n this be made a `constexpr` function?</blockquote>
<div><br></div><div>No; static_cast from void* remains invalid in constant =
expression evaluation.</div><div>=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:=
rgb(204,204,204);border-left-style:solid;padding-left:1ex">
 Let&#39;s say that we decide that it is legal. OK, fine; how do we deal wi=
th this perverse code:<br><br><div style=3D"background-color:rgb(250,250,25=
0);border:1px solid rgb(187,187,187);word-wrap:break-word"><code><span styl=
e=3D"color:rgb(0,0,136)">constexpr</span>=A0<span style=3D"color:rgb(0,0,13=
6)">int</span>=A0<span style=3D"color:rgb(102,0,102)">CastToY</span><span s=
tyle=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,136)">vo=
id</span>=A0<span style=3D"color:rgb(102,102,0)">*</span>vp<span style=3D"c=
olor:rgb(102,102,0)">)</span><br>
<span style=3D"color:rgb(102,102,0)">{</span><br>=A0 Y=A0<span style=3D"col=
or:rgb(102,102,0)">&amp;</span>y=A0<span style=3D"color:rgb(102,102,0)">=3D=
</span>=A0<span style=3D"color:rgb(0,0,136)">static_cast</span><span style=
=3D"color:rgb(102,102,0)">&lt;</span>Y<span style=3D"color:rgb(102,102,0)">=
*&gt;(</span>vp<span style=3D"color:rgb(102,102,0)">);</span><br>
=A0=A0<span style=3D"color:rgb(0,0,136)">return</span>=A0y<span style=3D"co=
lor:rgb(102,102,0)">.</span>num<span style=3D"color:rgb(102,102,0)">;</span=
><br><span style=3D"color:rgb(102,102,0)">}</span><br><br><span style=3D"co=
lor:rgb(0,0,136)">constexpr</span>=A0<span style=3D"color:rgb(0,0,136)">int=
</span>=A0<span style=3D"color:rgb(102,0,102)">Badness</span><span style=3D=
"color:rgb(102,102,0)">()</span><br>
<span style=3D"color:rgb(102,102,0)">{</span><br>=A0 X x<span style=3D"colo=
r:rgb(102,102,0)">;</span><br>=A0=A0<span style=3D"color:rgb(0,0,136)">retu=
rn</span>=A0<span style=3D"color:rgb(102,0,102)">CastToY</span><span style=
=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,136)">static=
_cast</span><span style=3D"color:rgb(102,102,0)">&lt;</span><span style=3D"=
color:rgb(0,0,136)">void</span><span style=3D"color:rgb(102,102,0)">*&gt;(&=
amp;</span>x<span style=3D"color:rgb(102,102,0)">));</span><br>
<span style=3D"color:rgb(102,102,0)">}</span><br><br><span style=3D"color:r=
gb(0,0,136)">constexpr</span>=A0<span style=3D"color:rgb(0,0,136)">int</spa=
n>=A0<span style=3D"color:rgb(102,0,102)">Goodness</span><span style=3D"col=
or:rgb(102,102,0)">()</span><br>
<span style=3D"color:rgb(102,102,0)">{</span><br>=A0 Y y<span style=3D"colo=
r:rgb(102,102,0)">;</span><br>=A0=A0<span style=3D"color:rgb(0,0,136)">retu=
rn</span>=A0<span style=3D"color:rgb(102,0,102)">CastToY</span><span style=
=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,136)">static=
_cast</span><span style=3D"color:rgb(102,102,0)">&lt;</span><span style=3D"=
color:rgb(0,0,136)">void</span><span style=3D"color:rgb(102,102,0)">*&gt;(&=
amp;</span>y<span style=3D"color:rgb(102,102,0)">));</span><br>
<span style=3D"color:rgb(102,102,0)">}</span></code></div><br>I don&#39;t f=
ancy the compiler writer that would have to implement detection, at compile=
 time, which traces through uses of `Badness` or `Goodness` to find out if =
they do the wrong thing.<br>
<br>And if this shouldn&#39;t be allowed... why not? Is casting to a `void*=
` considered &quot;an attempt to violate type-safety&quot;? Is that the ide=
a? If so, this seems like a weak limitation, since this behavior is protect=
ed by the standard. It is type-safe, so long as you do the right cast at th=
e other end.<br>
<br>And if this isn&#39;t allow, which part isn&#39;t allowed exactly? The =
casting to a `void*` part or the casting from a `void*`?<br></blockquote><d=
iv><br></div><div>In addition to the cast from void*, attempting to access =
a member of type Y through a glvalue which doesn&#39;t refer to an object o=
f type Y has undefined behavior, and is therefore banned. Note that your qu=
estion applies equally well in C++11:</div>
<div><br></div><div><font face=3D"courier new, monospace">constexpr int Cas=
tToY(void *p) { return static_cast&lt;Y*&gt;(p)-&gt;n; }</font></div><div><=
font face=3D"courier new, monospace">constexpr int Badness(X x) { return Ca=
stToY(static_cast&lt;void*&gt;(&amp;x)); }</font></div>
<div><font face=3D"courier new, monospace">constexpr int Goodness(Y y) { re=
turn CastToY(static_cast&lt;void*&gt;(&amp;y)); }</font></div><div><br></di=
v><div>And then note that constexpr implementations in C++11 already have t=
o be able to perform this kind of type check, if instead of casting from X*=
 and Y* to void* and back, you instead cast from X* / Y* to some common bas=
e class of X and Y:</div>
<div><br></div><div><font face=3D"courier new, monospace">struct Void {};</=
font></div><div><font face=3D"courier new, monospace">struct X : Void { int=
 n; };</font></div><div><font face=3D"courier new, monospace">struct Y : Vo=
id { int n; };</font></div>
<div><font face=3D"courier new, monospace">constexpr int CastToY(Void *p) {=
 return static_cast&lt;Y*&gt;(p)-&gt;n; }</font></div><div><font face=3D"co=
urier new, monospace">constexpr int Badness(X x) { return CastToY(static_ca=
st&lt;Void*&gt;(&amp;x)); }</font></div>
<div><font face=3D"courier new, monospace">constexpr int Goodness(Y y) { re=
turn CastToY(static_cast&lt;Void*&gt;(&amp;y)); }</font></div><div><font fa=
ce=3D"courier new, monospace">constexpr int k1 =3D Goodness(Y()); // ok</fo=
nt></div>
<div><div><font face=3D"courier new, monospace">constexpr int k2 =3D Badnes=
s(X()); // error</font></div></div><div><br></div><div>GCC says:</div><div>=
<br></div><div><div><font face=3D"courier new, monospace">&lt;stdin&gt;: At=
 global scope:</font></div>
<div><font face=3D"courier new, monospace">&lt;stdin&gt;:7:30: =A0 in const=
expr expansion of =91Badness(X{0})=92</font></div><div><font face=3D"courie=
r new, monospace">&lt;stdin&gt;:5:67: =A0 in constexpr expansion of =91Cast=
ToY(((Void*)(&amp; x)))=92</font></div>
<div><font face=3D"courier new, monospace">&lt;stdin&gt;:7:30: error: acces=
sing value of =91X{0}=92 through a =91Y=92 glvalue in a constant expression=
</font></div></div><div><br></div><div>Clang says:</div><div><br></div><div=
><div>
<font face=3D"courier new, monospace">&lt;stdin&gt;:7:15: error: constexpr =
variable &#39;k&#39; must be initialized by a constant expression</font></d=
iv><div><font face=3D"courier new, monospace">constexpr int k =3D Badness(X=
());</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 =A0 =A0 =A0 ^ =
=A0 ~~~~~~~~~~~~</font></div><div><font face=3D"courier new, monospace">&lt=
;stdin&gt;:4:41: note: cannot cast object of dynamic type &#39;X&#39; to ty=
pe &#39;Y&#39;</font></div>
<div><font face=3D"courier new, monospace">constexpr int CastToY(Void *p) {=
 return static_cast&lt;Y*&gt;(p)-&gt;n; }</font></div><div><font face=3D"co=
urier new, monospace">=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 ^</font></div>
<div><font face=3D"courier new, monospace">&lt;stdin&gt;:5:37: note: in cal=
l to &#39;CastToY(&amp;x)&#39;</font></div><div><font face=3D"courier new, =
monospace">constexpr int Badness(X x) { return CastToY(static_cast&lt;Void*=
&gt;(&amp;x)); }</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^</font></div><div><font face=3D"co=
urier new, monospace">&lt;stdin&gt;:7:19: note: in call to &#39;Badness({{}=
, 0})&#39;</font></div><div><font face=3D"courier new, monospace">constexpr=
 int k =3D Badness(X());</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 ^</font></div></div><div><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb=
(204,204,204);border-left-style:solid;padding-left:1ex">
I want to see more details and specifics regarding exactly what the require=
ments on `constexpr` functions are. It doesn&#39;t need to be spec-language=
, but it should be sufficiently detailed enough to know what exactly is req=
uired of an implementation.</blockquote>
<div><br></div><div>Here&#39;s my current draft of the suggested wording:</=
div><div><br></div><div><a href=3D"https://github.com/zygoloid/cplusplus/co=
mpare/master...liberal-constexpr">https://github.com/zygoloid/cplusplus/com=
pare/master...liberal-constexpr</a></div>
</div></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--20cf3071c6b042265304d852839c--

.

Nicol Bolas <jmckesson@gmail.com> writes:

| On Tuesday, March 19, 2013 4:42:02 PM UTC-7, Gabriel Dos Reis wrote:
|
|     Nicol Bolas <jmck...@gmail.com> writes:
|
|     [...]
|
|     | Implementing `constexpr` was not the easiest part of C++11 to be
|     implemented,
|     | for any of the vendors who have done so thus far.
|
|     I originally implemented constexpr for GCC; I've seen far more challenging
|     implementation issues (in C++98 and C++03) than what I faced with
|     constexpr, even given the fact that g++ didn't have high level ASTs and
|     some internal very low-level representation needed to be "reverse
|     engineered"  -- but that is only because g++ lowered too fast and too
|     quickly useful information.
|
|     I do confess that an implementation with a more regular and more
|     principled representation and close enough to the C++ abstract machine
|     will have an easier time -- see for example what I did with the IPR.
|
|     There is a real meaningful discussion to be had about  relaxing
|     constraints on constexpr functions, but let's not start by blowing
|     issues out of proportion.
|
|     -- Gaby
|
|
| I don't mean to blow anything out of proportion. But as I heard it (so take
| that for what it's worth), the Clang folks basically had to implement a
| compile-time interpreter to make constexpr work.

An obvious problem with repeating something one does not have first hand
experience with or cross checked, is that one can easily blow things out
of proportion.  Furthermore, when you present inference from partial
information and guesses as unambiguous facts, the likelyhood of blowing
something out of proportion is pretty high.

| And the VC folks haven't even
| attempted to implement it (though admittedly they're rather behind on C++11
| support in general). The Intel compiler only claims "Partial" support for it.
|
| While that's far from definitive, it does suggest that it's not among the
| easiest features in the world to implement. And one of the main reasons for the
| current suite of limitations is to make it as easy to implement while still
| being able to get reasonable functionality.
|
| My main point is this: the paper doesn't address any of this. It just glosses
| over the issue with a "D does it, so we should to" statement. I want to see
| some real investigation into the implement-ability of this feature.

That is a valid concern to have, but your statement was saying something
else with no first hand evidence, which I believe, does not serve your point.

-- Gaby

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On 3/19/13, Nicol Bolas <jmckesson@gmail.com> wrote:
> Here are my thoughts on Relaxing constraints on constexpr functions
> <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3597.html>.
>
> It's certainly a bold proposal. But I think it has some significant
> issues.

If it didn't have issues, it wouldn't be bold.  :-)

> When making a bold proposal like this, it's a good idea to make
> certain that all of the corner cases are covered. That, if spec
> language is not part of the proposal, that it could at least be
> sufficiently specific about corner cases.

There is a slippery slope of what we allow.  Pretty much everyone
agrees that the rules are too restrictive now.  We knew that when
we adopted the feature, but did so because we were pretty sure of
implementability.  We can relax the restrictions in a conservative
manner, picking rules that are simple and sufficient.  As time goes
on, we may relax them further as we learn more.

--
Lawrence Crowl

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.