------=_Part_61_21059161.1378651236102
Content-Type: text/plain; charset=ISO-8859-1

I was looking at the latest C++14 draft, N3691, and noticed its relaxed
constexpr rules.  I'm also writing a function that needs to be constexprand I wanted to take the address of its input.  I was thinking of using
std::addressof to be safe, but it isn't currently constexpr.  A sample
implementation at http://en.cppreference.com/w/cpp/memory/addressofcouldn't be
constexpr under the C++11 rules, but might under C++14.  Could we add the
specifier?

Daryle W.


--

---
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/.

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

<div dir=3D"ltr"><div>I was looking at the latest C++14 draft, N3691, and n=
oticed its relaxed <font face=3D"courier new,monospace">constexpr</font> ru=
les.&nbsp; I'm also writing a function that needs to be <font face=3D"couri=
er new,monospace">constexpr</font> and I wanted to take the address of its =
input.&nbsp; I was thinking of using <font face=3D"courier new,monospace">s=
td::addressof</font> to be safe, but it isn't currently <font face=3D"couri=
er new,monospace">constexpr</font>.&nbsp; A sample implementation at <a hre=
f=3D"http://en.cppreference.com/w/cpp/memory/addressof">http://en.cpprefere=
nce.com/w/cpp/memory/addressof</a> couldn't be <font face=3D"courier new,mo=
nospace">constexpr</font> under the C++11 rules, but might under C++14.&nbs=
p; Could we add the specifier?</div><div>&nbsp;</div><div>Daryle W.</div><d=
iv>&nbsp;</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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_61_21059161.1378651236102--

.

--e89a8f3ba25b0608c604e5e06674
Content-Type: text/plain; charset=ISO-8859-1

2013/9/8 Daryle Walker <darylew@gmail.com>

> I was looking at the latest C++14 draft, N3691, and noticed its relaxed
> constexpr rules.  I'm also writing a function that needs to be constexprand I wanted to take the address of its input.  I was thinking of using
> std::addressof to be safe, but it isn't currently constexpr.  A sample
> implementation at http://en.cppreference.com/w/cpp/memory/addressofcouldn't be
> constexpr under the C++11 rules, but might under C++14.  Could we add the
> specifier?
>

Yes, I think we have a real urgent need for this, especially since the core
language has made it pretty clear that reinterpret_cast is not valid in
constant expressions. This means that current attempts to realize the
effect of working for class types with overloaded unary operator& are not
valid. A library should be able to realize this (i.e. by an intrinsic).

I would even go so far and suggest to submit a library issue regarding this
problem.

- Daniel

--

---
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/.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
2013/9/8 Daryle Walker <span dir=3D"ltr">&lt;<a href=3D"mailto:darylew@gmai=
l.com" target=3D"_blank">darylew@gmail.com</a>&gt;</span><br><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"><div>I was looking at the latest C++14 draft, N3691, and n=
oticed its relaxed <font face=3D"courier new,monospace">constexpr</font> ru=
les.=A0 I&#39;m also writing a function that needs to be <font face=3D"cour=
ier new,monospace">constexpr</font> and I wanted to take the address of its=
 input.=A0 I was thinking of using <font face=3D"courier new,monospace">std=
::addressof</font> to be safe, but it isn&#39;t currently <font face=3D"cou=
rier new,monospace">constexpr</font>.=A0 A sample implementation at <a href=
=3D"http://en.cppreference.com/w/cpp/memory/addressof" target=3D"_blank">ht=
tp://en.cppreference.com/w/cpp/memory/addressof</a> couldn&#39;t be <font f=
ace=3D"courier new,monospace">constexpr</font> under the C++11 rules, but m=
ight under C++14.=A0 Could we add the specifier?</div>
</div></blockquote><div><br></div><div>Yes, I think we have a real urgent n=
eed for this, especially since the core language has made it pretty clear t=
hat reinterpret_cast is not valid in constant expressions. This means that =
current attempts to realize the effect of working for class types with over=
loaded unary operator&amp; are not valid. A library should be able to reali=
ze this (i.e. by an intrinsic).<br>
<br></div><div>I would even go so far and suggest to submit a library issue=
 regarding this problem.<br></div><div><br></div></div>- Daniel<br></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--e89a8f3ba25b0608c604e5e06674--

.

Daniel Kr=FCgler <daniel.kruegler@gmail.com> writes:

| 2013/9/8 Daryle Walker <darylew@gmail.com>
|=20
|     I was looking at the latest C++14 draft, N3691, and noticed its relax=
ed
|     constexpr rules.=A0 I'm also writing a function that needs to be cons=
texpr
|     and I wanted to take the address of its input.=A0 I was thinking of u=
sing
|     std::addressof to be safe, but it isn't currently constexpr.=A0 A sam=
ple
|     implementation at http://en.cppreference.com/w/cpp/memory/addressof
|     couldn't be constexpr under the C++11 rules, but might under C++14.=
=A0 Could
|     we add the specifier?
|=20
|=20
| Yes, I think we have a real urgent need for this, especially since the co=
re
| language has made it pretty clear that reinterpret_cast is not valid in
| constant expressions.

which, we should all celebrate :-)

| This means that current attempts to realize the effect of
| working for class types with overloaded unary operator& are not valid. A
| library should be able to realize this (i.e. by an intrinsic).
|=20
| I would even go so far and suggest to submit a library issue regarding th=
is
| problem.

Agreed.

-- Gaby

--=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/.

.

--047d7b6d95e612677004e5e4a746
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sun, Sep 8, 2013 at 7:50 AM, Daniel Kr=FCgler <daniel.kruegler@gmail.com=
>wrote:

>
> 2013/9/8 Daryle Walker <darylew@gmail.com>
>
>> I was looking at the latest C++14 draft, N3691, and noticed its relaxed
>> constexpr rules.  I'm also writing a function that needs to be constexpr=
and I wanted to take the address of its input.  I was thinking of using
>> std::addressof to be safe, but it isn't currently constexpr.  A sample
>> implementation at http://en.cppreference.com/w/cpp/memory/addressofcould=
n't be
>> constexpr under the C++11 rules, but might under C++14.  Could we add
>> the specifier?
>>
>
> Yes, I think we have a real urgent need for this, especially since the
> core language has made it pretty clear that reinterpret_cast is not valid
> in constant expressions. This means that current attempts to realize the
> effect of working for class types with overloaded unary operator& are not
> valid. A library should be able to realize this (i.e. by an intrinsic).
>

Agreed. Clang trunk, for instance, already provides a __builtin_addressof
for this exact reason.


> I would even go so far and suggest to submit a library issue regarding
> this problem.
>

Sounds like a great idea to me.

I would suggest taking this a step further and also removing the weird
special case from std::optional's operator-> (although perhaps as a
separate issue).

--=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/.

--047d7b6d95e612677004e5e4a746
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sun, Sep 8, 2013 at 7:50 AM, Daniel Kr=FCgler <span dir=
=3D"ltr">&lt;<a href=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank"=
>daniel.kruegler@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><div class=3D"im">2013/9/8 Daryle Walker <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:darylew@gmail.com" target=3D"_blank">d=
arylew@gmail.com</a>&gt;</span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>I was looking at the latest C++14 draft, N3691, and n=
oticed its relaxed <font face=3D"courier new,monospace">constexpr</font> ru=
les.=A0 I&#39;m also writing a function that needs to be <font face=3D"cour=
ier new,monospace">constexpr</font> and I wanted to take the address of its=
 input.=A0 I was thinking of using <font face=3D"courier new,monospace">std=
::addressof</font> to be safe, but it isn&#39;t currently <font face=3D"cou=
rier new,monospace">constexpr</font>.=A0 A sample implementation at <a href=
=3D"http://en.cppreference.com/w/cpp/memory/addressof" target=3D"_blank">ht=
tp://en.cppreference.com/w/cpp/memory/addressof</a> couldn&#39;t be <font f=
ace=3D"courier new,monospace">constexpr</font> under the C++11 rules, but m=
ight under C++14.=A0 Could we add the specifier?</div>

</div></blockquote><div><br></div></div><div>Yes, I think we have a real ur=
gent need for this, especially since the core language has made it pretty c=
lear that reinterpret_cast is not valid in constant expressions. This means=
 that current attempts to realize the effect of working for class types wit=
h overloaded unary operator&amp; are not valid. A library should be able to=
 realize this (i.e. by an intrinsic).<br>
</div></div></div></div></blockquote><div><br></div><div>Agreed. Clang trun=
k, for instance, already provides a __builtin_addressof for this exact reas=
on.</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 dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
></div><div>I would even go so far and suggest to submit a library issue re=
garding this problem.</div></div></div></div></blockquote><div><br></div><d=
iv>
Sounds like a great idea to me.</div><div><br></div><div>I would suggest ta=
king this a step further and also removing the weird special case from std:=
:optional&#39;s operator-&gt; (although perhaps as a separate issue).</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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b6d95e612677004e5e4a746--

.

------=_Part_253_7244165.1378673282279
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Sunday, September 8, 2013 10:50:53 AM UTC-4, Daniel Kr=FCgler wrote:
>
>
> 2013/9/8 Daryle Walker <dar...@gmail.com <javascript:>>
>
>> I was looking at the latest C++14 draft, N3691, and noticed its relaxed=
=20
>> constexpr rules.  I'm also writing a function that needs to be constexpr=
and I wanted to take the address of its input.  I was thinking of using=20
>> std::addressof to be safe, but it isn't currently constexpr.  A sample=
=20
>> implementation at http://en.cppreference.com/w/cpp/memory/addressofcould=
n't be=20
>> constexpr under the C++11 rules, but might under C++14.  Could we add=20
>> the specifier?
>>
>
> Yes, I think we have a real urgent need for this, especially since the=20
> core language has made it pretty clear that reinterpret_cast is not valid=
=20
> in constant expressions. This means that current attempts to realize the=
=20
> effect of working for class types with overloaded unary operator& are not=
=20
> valid. A library should be able to realize this (i.e. by an intrinsic).
>
=20
Using reinterpret_cast is still banned for constexpr in C++14?  Where,=20
since it has to be indirect?  (The huge list of actions that disqualify a=
=20
function from being constexpr has been drastically reduced.)=20
=20

> I would even go so far and suggest to submit a library issue regarding=20
> this problem.
>
=20
Done.
=20
Daryle W.
=20

--=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/.

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

<div dir=3D"ltr"><br>On Sunday, September 8, 2013 10:50:53 AM UTC-4, Daniel=
 Kr=FCgler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><br><div><di=
v class=3D"gmail_quote">2013/9/8 Daryle Walker <span dir=3D"ltr">&lt;<a hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"nFQGQajknycJ">=
dar...@gmail.com</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;">
<div dir=3D"ltr"><div>I was looking at the latest C++14 draft, N3691, and n=
oticed its relaxed <font face=3D"courier new,monospace">constexpr</font> ru=
les.&nbsp; I'm also writing a function that needs to be <font face=3D"couri=
er new,monospace">constexpr</font> and I wanted to take the address of its =
input.&nbsp; I was thinking of using <font face=3D"courier new,monospace">s=
td::addressof</font> to be safe, but it isn't currently <font face=3D"couri=
er new,monospace">constexpr</font>.&nbsp; A sample implementation at <a hre=
f=3D"http://en.cppreference.com/w/cpp/memory/addressof" target=3D"_blank">h=
ttp://en.cppreference.com/w/<wbr>cpp/memory/addressof</a> couldn't be <font=
 face=3D"courier new,monospace">constexpr</font> under the C++11 rules, but=
 might under C++14.&nbsp; Could we add the specifier?</div>
</div></blockquote><div><br></div><div>Yes, I think we have a real urgent n=
eed for this, especially since the core language has made it pretty clear t=
hat reinterpret_cast is not valid in constant expressions. This means that =
current attempts to realize the effect of working for class types with over=
loaded unary operator&amp; are not valid. A library should be able to reali=
ze this (i.e. by an intrinsic).</div></div></div></div></blockquote><div>&n=
bsp;</div><div>Using <font face=3D"courier new,monospace">reinterpret_cast<=
/font> is still banned for <font face=3D"courier new,monospace">constexpr</=
font> in C++14?&nbsp; Where, since it&nbsp;has to be indirect?&nbsp; (The&n=
bsp;huge list of actions that disqualify a function from being <font face=
=3D"courier new,monospace">constexpr</font> has been drastically reduced.)&=
nbsp;</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, =
204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><=
div><div class=3D"gmail_quote"><div>
I would even go so far and suggest to submit a library issue regarding this=
 problem.</div></div></div></div></blockquote><div>&nbsp;</div><div>Done.</=
div><div>&nbsp;</div><div>Daryle W.</div><div>&nbsp;</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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_253_7244165.1378673282279--

.

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

2013/9/8 Daryle Walker <darylew@gmail.com>

>
> On Sunday, September 8, 2013 10:50:53 AM UTC-4, Daniel Kr=FCgler wrote:
>>
>>
>> Yes, I think we have a real urgent need for this, especially since the
>> core language has made it pretty clear that reinterpret_cast is not vali=
d
>> in constant expressions. This means that current attempts to realize the
>> effect of working for class types with overloaded unary operator& are no=
t
>> valid. A library should be able to realize this (i.e. by an intrinsic).
>>
>
> Using reinterpret_cast is still banned for constexpr in C++14?  Where,
> since it has to be indirect?  (The huge list of actions that disqualify a
> function from being constexpr has been drastically reduced.)
>

No, this is very clear and directly said in 5.19 [expr.const]:

"A conditional-expression e is a core constant expression unless the
evaluation of e, following the rules of the
abstract machine (1.9), would evaluate one of the following expressions:
[..]
=97 a conversion from type cv void * to a pointer-to-object type;
=97 a dynamic cast (5.2.7);
=97 a reinterpret_cast (5.2.10);
[..]
"

- Daniel

--=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/.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
2013/9/8 Daryle Walker <span dir=3D"ltr">&lt;<a href=3D"mailto:darylew@gmai=
l.com" target=3D"_blank">darylew@gmail.com</a>&gt;</span><br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr"><br>On Sunday, September 8, 2013 10:50:53 AM UTC-4, Daniel=
 Kr=FCgler wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;padding-left:1ex;border-left:1px solid rgb(204,204,204)"><div dir=
=3D"ltr">
<br><div><div class=3D"gmail_quote"><div class=3D"im"><div>Yes, I think we =
have a real urgent need for this, especially since the core language has ma=
de it pretty clear that reinterpret_cast is not valid in constant expressio=
ns. This means that current attempts to realize the effect of working for c=
lass types with overloaded unary operator&amp; are not valid. A library sho=
uld be able to realize this (i.e. by an intrinsic).</div>
</div></div></div></div></blockquote><div>=A0</div><div>Using <font face=3D=
"courier new,monospace">reinterpret_cast</font> is still banned for <font f=
ace=3D"courier new,monospace">constexpr</font> in C++14?=A0 Where, since it=
=A0has to be indirect?=A0 (The=A0huge list of actions that disqualify a fun=
ction from being <font face=3D"courier new,monospace">constexpr</font> has =
been drastically reduced.)=A0</div>
</div></blockquote><div><br></div><div>No, this is very clear and directly =
said in 5.19 [expr.const]:<br><br>&quot;A conditional-expression e is a cor=
e constant expression unless the evaluation of e, following the rules of th=
e<br>
abstract machine (1.9), would evaluate one of the following expressions:<br=
>[..]<br>=97 a conversion from type cv void * to a pointer-to-object type;<=
br>=97 a dynamic cast (5.2.7);<br>=97 a reinterpret_cast (5.2.10);<br>[..]<=
br>
&quot;<br><br></div><div>- Daniel<br>=A0<br></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--e89a8f3ba25bfc8b2804e5e57055--

.

------=_Part_1305_24121669.1378675804790
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Sunday, September 8, 2013 4:48:02 PM UTC-4, Daryle Walker wrote:
>
>
> On Sunday, September 8, 2013 10:50:53 AM UTC-4, Daniel Kr=FCgler wrote:
>>
>>
>> 2013/9/8 Daryle Walker <dar...@gmail.com>
>>
>>> I was looking at the latest C++14 draft, N3691, and noticed its relaxed=
=20
>>> constexpr rules.  I'm also writing a function that needs to be constexp=
rand I wanted to take the address of its input.  I was thinking of using=20
>>> std::addressof to be safe, but it isn't currently constexpr.  A sample=
=20
>>> implementation at http://en.cppreference.com/w/cpp/memory/addressofcoul=
dn't be=20
>>> constexpr under the C++11 rules, but might under C++14.  Could we add=
=20
>>> the specifier?
>>>
>>
>> Yes, I think we have a real urgent need for this, especially since the=
=20
>> core language has made it pretty clear that reinterpret_cast is not vali=
d=20
>> in constant expressions. This means that current attempts to realize the=
=20
>> effect of working for class types with overloaded unary operator& are no=
t=20
>> valid. A library should be able to realize this (i.e. by an intrinsic).
>>
> =20
> Using reinterpret_cast is still banned for constexpr in C++14?  Where,=20
> since it has to be indirect?  (The huge list of actions that disqualify a=
=20
> function from being constexpr has been drastically reduced.) =20
>
=20
The constexpr list changed, but the general constant-expression list hasn't=
=20
(as much).
=20

> I would even go so far and suggest to submit a library issue regarding=20
>> this problem.
>>
> =20
> Done.
>
=20
Maybe one of you experts should write a better defect report....=20
=20
Daryle W.
=20

--=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/.

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

<div dir=3D"ltr"><br>On Sunday, September 8, 2013 4:48:02 PM UTC-4, Daryle =
Walker wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px=
 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-le=
ft-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><br>On Sunday, S=
eptember 8, 2013 10:50:53 AM UTC-4, Daniel Kr=FCgler wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bo=
rder-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-st=
yle: solid;"><div dir=3D"ltr"><br><div><div class=3D"gmail_quote">2013/9/8 =
Daryle Walker <span dir=3D"ltr">&lt;<a>dar...@gmail.com</a>&gt;</span><br><=
blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddin=
g-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px;=
 border-left-style: solid;">
<div dir=3D"ltr"><div>I was looking at the latest C++14 draft, N3691, and n=
oticed its relaxed <font face=3D"courier new,monospace">constexpr</font> ru=
les.&nbsp; I'm also writing a function that needs to be <font face=3D"couri=
er new,monospace">constexpr</font> and I wanted to take the address of its =
input.&nbsp; I was thinking of using <font face=3D"courier new,monospace">s=
td::addressof</font> to be safe, but it isn't currently <font face=3D"couri=
er new,monospace">constexpr</font>.&nbsp; A sample implementation at <a hre=
f=3D"http://en.cppreference.com/w/cpp/memory/addressof" target=3D"_blank">h=
ttp://en.cppreference.com/w/<wbr>cpp/memory/addressof</a> couldn't be <font=
 face=3D"courier new,monospace">constexpr</font> under the C++11 rules, but=
 might under C++14.&nbsp; Could we add the specifier?</div>
</div></blockquote><div><br></div><div>Yes, I think we have a real urgent n=
eed for this, especially since the core language has made it pretty clear t=
hat reinterpret_cast is not valid in constant expressions. This means that =
current attempts to realize the effect of working for class types with over=
loaded unary operator&amp; are not valid. A library should be able to reali=
ze this (i.e. by an intrinsic).</div></div></div></div></blockquote><div>&n=
bsp;</div><div>Using <font face=3D"courier new,monospace">reinterpret_cast<=
/font> is still banned for <font face=3D"courier new,monospace">constexpr</=
font> in C++14?&nbsp; Where, since it&nbsp;has to be indirect?&nbsp; (The&n=
bsp;huge list of actions that disqualify a function from being <font face=
=3D"courier new,monospace">constexpr</font> has been drastically reduced.)&=
nbsp;&nbsp;</div></div></blockquote><div>&nbsp;</div><div>The <font face=3D=
"courier new,monospace">constexpr</font> list changed, but the general cons=
tant-expression list hasn't (as much).</div><div>&nbsp;</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; =
border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-=
style: solid;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"=
margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 2=
04, 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"lt=
r"><div><div class=3D"gmail_quote"><div>
I would even go so far and suggest to submit a library issue regarding this=
 problem.</div></div></div></div></blockquote><div>&nbsp;</div><div>Done.</=
div></div></blockquote><div>&nbsp;</div><div>Maybe one of you experts shoul=
d write a better defect report....&nbsp;</div><div>&nbsp;</div><div>Daryle =
W.</div><div>&nbsp;</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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1305_24121669.1378675804790--

.

--047d7b6251b07d531904e5e60c0f
Content-Type: text/plain; charset=ISO-8859-1

2013/9/8 Daryle Walker <darylew@gmail.com>

>
>>
>> Using reinterpret_cast is still banned for constexpr in C++14?  Where,
>> since it has to be indirect?  (The huge list of actions that disqualify a
>> function from being constexpr has been drastically reduced.)
>>
>
> The constexpr list changed, but the general constant-expression list
> hasn't (as much).
>

You are misreading the wording, please check back what I quote from 5.19 in
my last reply - this has nothing to do with constexpr, it is a restriction
about *every* /core constant expression/. Note also that a (general)
/constant expression/ *is* a special form of a core constant expression, so
it applies for these as well.


>
>
>> I would even go so far and suggest to submit a library issue regarding
>>> this problem.
>>>
>>
>> Done.
>>
>
> Maybe one of you experts should write a better defect report....
>

I don't see a reason why - could you please elaborate?

- Daniel

--

---
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/.

--047d7b6251b07d531904e5e60c0f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
2013/9/8 Daryle Walker <span dir=3D"ltr">&lt;<a href=3D"mailto:darylew@gmai=
l.com" target=3D"_blank">darylew@gmail.com</a>&gt;</span><br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr"><div class=3D"im">=A0<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left:1px solid rgb(2=
04,204,204)"><div dir=3D"ltr"><div>Using <font face=3D"courier new,monospac=
e">reinterpret_cast</font> is still banned for <font face=3D"courier new,mo=
nospace">constexpr</font> in C++14?=A0 Where, since it=A0has to be indirect=
?=A0 (The=A0huge list of actions that disqualify a function from being <fon=
t face=3D"courier new,monospace">constexpr</font> has been drastically redu=
ced.)=A0=A0</div>
</div></blockquote><div>=A0</div></div><div>The <font face=3D"courier new,m=
onospace">constexpr</font> list changed, but the general constant-expressio=
n list hasn&#39;t (as much).</div></div></blockquote><div><br></div><div>Yo=
u are misreading the wording, please check back what I quote from 5.19 in m=
y last reply - this has nothing to do with constexpr, it is a restriction a=
bout *every* /core constant expression/. Note also that a (general) /consta=
nt expression/ *is* a special form of a core constant expression, so it app=
lies for these as well.<br>
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><div class=3D"im"><div>=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left:1px solid rgb(204,20=
4,204)">
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;padding-left:1ex;border-left:1px solid rgb(204,204,204)"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><div>
I would even go so far and suggest to submit a library issue regarding this=
 problem.</div></div></div></div></blockquote><div>=A0</div><div>Done.</div=
></div></blockquote><div>=A0</div></div><div>Maybe one of you experts shoul=
d write a better defect report....=A0</div>
</div></blockquote><div><br></div></div>I don&#39;t see a reason why - coul=
d you please elaborate?<br><br></div><div class=3D"gmail_extra">- Daniel<br=
></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b6251b07d531904e5e60c0f--

.

--001a11c34302c8ba7304e5e63770
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2013/9/8 Daniel Kr=FCgler <daniel.kruegler@gmail.com>

>
> 2013/9/8 Daryle Walker <darylew@gmail.com>
>
>>
>>>
>>> Using reinterpret_cast is still banned for constexpr in C++14?  Where,
>>> since it has to be indirect?  (The huge list of actions that disqualify=
 a
>>> function from being constexpr has been drastically reduced.)
>>>
>>
>> The constexpr list changed, but the general constant-expression list
>> hasn't (as much).
>>
>
> You are misreading the wording, please check back what I quote from 5.19
> in my last reply - this has nothing to do with constexpr, it is a
> restriction about *every* /core constant expression/. Note also that a
> (general) /constant expression/ *is* a special form of a core constant
> expression, so it applies for these as well.
>

I see now the reason for the misunderstanding - that's my fault: You are
wondering about why the language has removed previous restrictions from
functions that are declared with constexpr, but instead has worked on the
list for constant expressions. This seemingly difference is not a defect by
intended. But for library functions it is really important that if we mark
them with constexpr they should really be useable in constant expressions.
This was the reason why I was always trying to point you back to 5.19,
which defines valid constant expressions.

- Daniel

--=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/.

--001a11c34302c8ba7304e5e63770
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
2013/9/8 Daniel Kr=FCgler <span dir=3D"ltr">&lt;<a href=3D"mailto:daniel.kr=
uegler@gmail.com" target=3D"_blank">daniel.kruegler@gmail.com</a>&gt;</span=
><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<div class=3D"im">2013/9/8 Daryle Walker <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:darylew@gmail.com" target=3D"_blank">darylew@gmail.com</a>&gt;</span>=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">

<div dir=3D"ltr"><div>=A0<blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;padding-left:1ex;border-left:1px solid rgb(204,204,204)">=
<div dir=3D"ltr"><div>Using <font face=3D"courier new,monospace">reinterpre=
t_cast</font> is still banned for <font face=3D"courier new,monospace">cons=
texpr</font> in C++14?=A0 Where, since it=A0has to be indirect?=A0 (The=A0h=
uge list of actions that disqualify a function from being <font face=3D"cou=
rier new,monospace">constexpr</font> has been drastically reduced.)=A0=A0</=
div>

</div></blockquote><div>=A0</div></div><div>The <font face=3D"courier new,m=
onospace">constexpr</font> list changed, but the general constant-expressio=
n list hasn&#39;t (as much).</div></div></blockquote><div><br></div></div>
<div>You are misreading the wording, please check back what I quote from 5.=
19 in my last reply - this has nothing to do with constexpr, it is a restri=
ction about *every* /core constant expression/. Note also that a (general) =
/constant expression/ *is* a special form of a core constant expression, so=
 it applies for these as well.<br>
</div></div></div></div></blockquote><div><br></div><div>I see now the reas=
on for the misunderstanding - that&#39;s my fault: You are wondering about =
why the language has removed previous restrictions from functions that are =
declared with constexpr, but instead has worked on the list for constant ex=
pressions. This seemingly difference is not a defect by intended. But for l=
ibrary functions it is really important that if we mark them with constexpr=
 they should really be useable in constant expressions. This was the reason=
 why I was always trying to point you back to 5.19, which defines valid con=
stant expressions.<br>
<br></div><div>- Daniel<br></div><div><br></div></div><br></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c34302c8ba7304e5e63770--

.