------=_Part_1688_747987695.1422735500363
Content-Type: multipart/alternative;
 boundary="----=_Part_1689_59920327.1422735500363"

------=_Part_1689_59920327.1422735500363
Content-Type: text/plain; charset=UTF-8

To further make std::integral_constant easier to work with, should we add a
specialization of std::numeric_limits to work with std::integral_constant?
max, min, and lowest would all be equal to the constant value, and all
other fields would be identical to the type argument. The only tricky part
is how to handle digits, digits10, and max_digits10. I tried to answer this
question at
https://stackoverflow.com/questions/19609186/what-is-stdnumeric-limitstdigits-supposed-to-represent
but I am not completely satisfied with the conclusion I came to. In this
case, the answer would be to define them as "0", because they are not
meaningful in this context.

This came up in the discussion of a fixed-point library:
https://github.com/mizvekov/fp . For this library, the shift operation is
important, but only by compile-time constants (as it changes the location
of the fixed point in the result type). It currently has manual support for
std::integral_constant. I was talking to the author about support of my
bounded::integer library, and we talked about a solution using
std::numeric_limits to detect that a type can only hold one value. In my
case, something like bounded::integer<5, 5> always has the value of 5, and
this can be detected with std::numeric_limits min and max (in general, you
also need to check is_bounded). However, this requires essentially
duplicate code for std::integral_constant.

--

---
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_1689_59920327.1422735500363
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">To further make std::integral_constant easier to work with=
, should we add a specialization of std::numeric_limits to work with std::i=
ntegral_constant? max, min, and lowest would all be equal to the constant v=
alue, and all other fields would be identical to the type argument. The onl=
y tricky part is how to handle digits, digits10, and max_digits10. I tried =
to answer this question at https://stackoverflow.com/questions/19609186/wha=
t-is-stdnumeric-limitstdigits-supposed-to-represent but I am not completely=
 satisfied with the conclusion I came to. In this case, the answer would be=
 to define them as "0", because they are not meaningful in this context.<br=
><br>This came up in the discussion of a fixed-point library: https://githu=
b.com/mizvekov/fp . For this library, the shift operation is important, but=
 only by compile-time constants (as it changes the location of the fixed po=
int in the result type). It currently has manual support for std::integral_=
constant. I was talking to the author about support of my bounded::integer =
library, and we talked about a solution using std::numeric_limits to detect=
 that a type can only hold one value. In my case, something like bounded::i=
nteger&lt;5, 5&gt; always has the value of 5, and this can be detected with=
 std::numeric_limits min and max (in general, you also need to check is_bou=
nded). However, this requires essentially duplicate code for std::integral_=
constant.<br></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_1689_59920327.1422735500363--
------=_Part_1688_747987695.1422735500363--

.

------=_Part_5993_1029900255.1423708956524
Content-Type: multipart/alternative;
 boundary="----=_Part_5994_815390965.1423708956524"

------=_Part_5994_815390965.1423708956524
Content-Type: text/plain; charset=UTF-8

On Saturday, January 31, 2015 at 6:18:20 PM UTC-2, David Stone wrote:
>
> To further make std::integral_constant easier to work with, should we add
> a specialization of std::numeric_limits to work with
> std::integral_constant? max, min, and lowest would all be equal to the
> constant value, and all other fields would be identical to the type
> argument. The only tricky part is how to handle digits, digits10, and
> max_digits10. I tried to answer this question at
> https://stackoverflow.com/questions/19609186/what-is-stdnumeric-limitstdigits-supposed-to-represent
> but I am not completely satisfied with the conclusion I came to. In this
> case, the answer would be to define them as "0", because they are not
> meaningful in this context.
>

Yes I second that.

But I think just adding numeric_limits support feels incomplete since right
now you can't even do arithmetic with integral_constant.

It would be interesting to add full arithmetic support on top of it. eg the
expression:

std::integral_constant<T,A>{} + std::integral_constant<U,B>{}

should type as:

std::integral_constant<decltype(A + B), A + B>

Also, in general, any place that accepts an object of type T should also
accept one of type std::integral<T,whatever>.

cmath is problematic here, for example:

std::exp2(std::integral_constant<int, 5>{})

The above blows up because the overloads are ambiguous.

Also, let's throw in here a standard literal suffix. For example, 5ic
denotes std::integral_constant<int, 5>{}

None of this is hard, and has been reinvented a couple of times already in
user code.
Except the compatibility issues with cmath for example, fixing that would
likely touch a lot of stuff.


>
> This came up in the discussion of a fixed-point library:
> https://github.com/mizvekov/fp . For this library, the shift operation is
> important, but only by compile-time constants (as it changes the location
> of the fixed point in the result type). It currently has manual support for
> std::integral_constant. I was talking to the author about support of my
> bounded::integer library, and we talked about a solution using
> std::numeric_limits to detect that a type can only hold one value. In my
> case, something like bounded::integer<5, 5> always has the value of 5, and
> this can be detected with std::numeric_limits min and max (in general, you
> also need to check is_bounded). However, this requires essentially
> duplicate code for std::integral_constant.
>

Yes that was me, we talked about this, but I didn't see this post till 5
minutes ago.

The arithmetic support on top of std::integral constant is cool because
then by composing it with the fixed point library, you get a compile time
fixed point arithmetic type.

For example the expression:

fp_t<std::integral_constant<int, 5>, 10>{} * fp_t<std::integral_constant<int
, 4>, 12>{}

would type as:

fp_t<std::integral_constant<int, 5 * 4>, 10 + 12>

and this should work as the library is right now.


--

---
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_5994_815390965.1423708956524
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, January 31, 2015 at 6:18:20 PM UTC-2, David S=
tone wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">To=
 further make std::integral_constant easier to work with, should we add a s=
pecialization of std::numeric_limits to work with std::integral_constant? m=
ax, min, and lowest would all be equal to the constant value, and all other=
 fields would be identical to the type argument. The only tricky part is ho=
w to handle digits, digits10, and max_digits10. I tried to answer this ques=
tion at <a href=3D"https://stackoverflow.com/questions/19609186/what-is-std=
numeric-limitstdigits-supposed-to-represent" target=3D"_blank" rel=3D"nofol=
low" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F=
%2Fstackoverflow.com%2Fquestions%2F19609186%2Fwhat-is-stdnumeric-limitstdig=
its-supposed-to-represent\46sa\75D\46sntz\0751\46usg\75AFQjCNEzaV70FjFmQEBg=
hki43RMVsRgVWw';return true;" onclick=3D"this.href=3D'https://www.google.co=
m/url?q\75https%3A%2F%2Fstackoverflow.com%2Fquestions%2F19609186%2Fwhat-is-=
stdnumeric-limitstdigits-supposed-to-represent\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNEzaV70FjFmQEBghki43RMVsRgVWw';return true;">https://stackoverflow.co=
m/<wbr>questions/19609186/what-is-<wbr>stdnumeric-limitstdigits-<wbr>suppos=
ed-to-represent</a> but I am not completely satisfied with the conclusion I=
 came to. In this case, the answer would be to define them as "0", because =
they are not meaningful in this context.<br></div></blockquote><div><br>Yes=
 I second that.<br><br>But I think just adding numeric_limits support feels=
 incomplete since right now you can't even do arithmetic with integral_cons=
tant.<br><br>It would be interesting to add full arithmetic support on top =
of it. eg the expression:<br><br><div class=3D"prettyprint" style=3D"backgr=
ound-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-st=
yle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D=
"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">integral_constant</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">A</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&gt;{}</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">+</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">integral_constant</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">U</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">B</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;{}<=
/span></div></code></div><br> should type as:<br><br><div class=3D"prettypr=
int" 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 class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">integral_constant</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">decltype</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">A </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">+</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
B</span><span style=3D"color: #660;" class=3D"styled-by-prettify">),</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> A </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">+</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> B</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span></div></code></div><br>Also, in gene=
ral, any place that accepts an object of type T should also accept one of t=
ype std::integral&lt;T,whatever&gt;.<br><br>cmath is problematic here, for =
example:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(2=
50, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; borde=
r-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div clas=
s=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">exp2</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">integral_constant</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-=
prettify">5</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>&gt;{})</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span></div></code></div><br>The above blows up because the overloads ar=
e ambiguous.<br><br>Also, let's throw in here a standard literal suffix. Fo=
r example, 5ic denotes std::integral_constant&lt;int, 5&gt;{}<br><br>None o=
f this is hard, and has been reinvented a couple of times already in user c=
ode.<br>Except the compatibility issues with cmath for example, fixing that=
 would likely touch a lot of stuff.<br>&nbsp;</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr"><br>This came up in the discussion of=
 a fixed-point library: <a href=3D"https://github.com/mizvekov/fp" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://www.google=
..com/url?q\75https%3A%2F%2Fgithub.com%2Fmizvekov%2Ffp\46sa\75D\46sntz\0751\=
46usg\75AFQjCNE9axYk-AM1s_3aq_MwcO6lyc57kQ';return true;" onclick=3D"this.h=
ref=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fmizvekov%2=
Ffp\46sa\75D\46sntz\0751\46usg\75AFQjCNE9axYk-AM1s_3aq_MwcO6lyc57kQ';return=
 true;">https://github.com/mizvekov/fp</a> . For this library, the shift op=
eration is important, but only by compile-time constants (as it changes the=
 location of the fixed point in the result type). It currently has manual s=
upport for std::integral_constant. I was talking to the author about suppor=
t of my bounded::integer library, and we talked about a solution using std:=
:numeric_limits to detect that a type can only hold one value. In my case, =
something like bounded::integer&lt;5, 5&gt; always has the value of 5, and =
this can be detected with std::numeric_limits min and max (in general, you =
also need to check is_bounded). However, this requires essentially duplicat=
e code for std::integral_constant.<br></div></blockquote><div><br>Yes that =
was me, we talked about this, but I didn't see this post till 5 minutes ago=
..<br><br>The arithmetic support on top of std::integral constant is cool be=
cause then by composing it with the fixed point library, you get a compile =
time fixed point arithmetic type.<br><br>For example the expression:<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; w=
ord-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyp=
rint"><span style=3D"color: #000;" class=3D"styled-by-prettify">fp_t</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">integral_constant</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styl=
ed-by-prettify">5</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&gt;,</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">10</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;{}</span><s=
pan 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"> fp_t</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">integral_constant</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">int</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #066;" class=3D"styled-by-prettify">4</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&gt;,</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #066;" class=3D"styled-by-prettify">12</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&gt;{}</span></div></code></div><br> would =
type as:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(2=
50, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; borde=
r-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div clas=
s=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">fp_t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&l=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">integral_constant</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" =
class=3D"styled-by-prettify">5</span><span 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=
"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">4</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;,</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">10</span><span style=3D"colo=
r: #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"> </span><span style=3D"color: #066;" class=3D"styled-b=
y-prettify">12</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span></div></code></div><br>and this should work as the library is righ=
t now.<br></div><div>&nbsp;</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_5994_815390965.1423708956524--
------=_Part_5993_1029900255.1423708956524--

.

--Apple-Mail=_6A8ABE04-F730-431E-A5CF-C92C9C4D20C2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9302=E2=80=9312, at 10:42 AM, Matheus Izvekov <mizvekov@gma=
il.com> wrote:
>=20
> cmath is problematic here, for example:
>=20
> std::exp2(std::integral_constant<int, 5>{})
>=20
> The above blows up because the overloads are ambiguous.

This is because promotion rank isn=E2=80=99t considered in overload orderin=
g. From the perspective of overload resolution, such programs tend to be un=
derspecified because there=E2=80=99s no good way to tell what floating-poin=
t precision is suitable for an integer argument.

On the other hand, [c.math] =C2=A726.8/11 requires expressions like exp2(5)=
 to work by defining double precision as the default: =E2=80=9Cif any arith=
metic argument corresponding to a double parameter has type double or an in=
teger type, then all arithmetic arguments corresponding to double parameter=
s are effectively cast to double.=E2=80=9D

You could argue this as a library defect, that it should say, =E2=80=9Cif a=
ny arithmetic argument of non-floating-point type is convertible to double,=
 then =E2=80=A6=E2=80=9D The problem is in <cmath> and the SFINAE used to i=
mplement this case, not not in integral_constant.

Either way, it=E2=80=99s surprising that exp2(std::integral_constant<5>()) =
is different from exp2(std::integral_constant<2>()+std::integral_constant<3=
>()), and the same applies to user-defined classes that similarly convert t=
o numeric type. It would be nice to see both operators and <cmath> support.

To avoid breakage, perhaps <cmath> conversions should be enabled via a stan=
dard user-defined type trait, say std::numeric_limits::native_cmath.

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

--Apple-Mail=_6A8ABE04-F730-431E-A5CF-C92C9C4D20C2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9302=
=E2=80=9312, at 10:42 AM, Matheus Izvekov &lt;<a href=3D"mailto:mizvekov@gm=
ail.com" class=3D"">mizvekov@gmail.com</a>&gt; wrote:</div><br class=3D"App=
le-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D""><div cl=
ass=3D"">cmath is problematic here, for example:<br class=3D""><br class=3D=
""><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 class=3D"prettyprint">std<span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">::</span>exp2<span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span>std<span style=3D"color: #660;" =
class=3D"styled-by-prettify">::</span>integral_constant<span style=3D"color=
: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">,</span> <span style=3D"color: #066;" class=3D"sty=
led-by-prettify">5</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&gt;{})</span><br class=3D""></code></div><br class=3D"">The above =
blows up because the overloads are ambiguous.<br class=3D""></div></div></d=
iv></blockquote><div><br class=3D""></div><div>This is because promotion ra=
nk isn=E2=80=99t considered in overload ordering. From the perspective of o=
verload resolution, such programs tend to be underspecified because there=
=E2=80=99s no good way to tell what floating-point precision is suitable fo=
r an integer argument.</div><div><br class=3D""></div><div>On the other han=
d, [c.math] =C2=A726.8/11 requires expressions like&nbsp;<font face=3D"Cour=
ier" class=3D"">exp2(5)</font> to work by defining double precision as the =
default: =E2=80=9Cif any arithmetic argument corresponding to a&nbsp;double=
&nbsp;parameter has type&nbsp;double&nbsp;or an&nbsp;integer type, then all=
&nbsp;arithmetic arguments corresponding to&nbsp;double&nbsp;parameters are=
 effectively cast to&nbsp;double.=E2=80=9D</div><div><br class=3D""></div><=
div>You could argue this as a library defect, that it should say, =E2=80=9C=
if any arithmetic argument&nbsp;<i class=3D"">of non-floating-point type is=
 convertible to</i> double, then =E2=80=A6=E2=80=9D The problem is in <font=
 face=3D"Courier" class=3D"">&lt;cmath&gt;</font> and the SFINAE used to im=
plement this case, not not in <font face=3D"Courier" class=3D"">integral_co=
nstant</font>.</div><div><br class=3D""></div><div>Either way, it=E2=80=99s=
 surprising that <font face=3D"Courier" class=3D"">exp2(std::integral_const=
ant&lt;5&gt;())</font> is different from <font face=3D"Courier" class=3D"">=
exp2(std::integral_constant&lt;2&gt;()+std::integral_constant&lt;3&gt;())</=
font>, and the same applies to user-defined classes that similarly convert =
to numeric type. It would be nice to see both operators and&nbsp;<span styl=
e=3D"font-family: Courier;" class=3D"">&lt;cmath&gt;</span>&nbsp;support.</=
div><div><br class=3D""></div><div><div>To avoid breakage, perhaps&nbsp;<sp=
an style=3D"font-family: Courier;" class=3D"">&lt;cmath&gt;</span>&nbsp;con=
versions should be enabled via a standard user-defined type trait, say&nbsp=
;<font face=3D"Courier" class=3D"">std::numeric_limits::native_cmath</font>=
..</div></div></div></body></html>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--Apple-Mail=_6A8ABE04-F730-431E-A5CF-C92C9C4D20C2--

.

------=_Part_969_1987811027.1423715421242
Content-Type: multipart/alternative;
 boundary="----=_Part_970_736834410.1423715421242"

------=_Part_970_736834410.1423715421242
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, February 12, 2015 at 1:37:40 AM UTC-2, David Krauss wrote:
>
> This is because promotion rank isn=E2=80=99t considered in overload order=
ing. From=20
> the perspective of overload resolution, such programs tend to be=20
> underspecified because there=E2=80=99s no good way to tell what floating-=
point=20
> precision is suitable for an integer argument.
>
> On the other hand, [c.math] =C2=A726.8/11 requires expressions like exp2(=
5) to=20
> work by defining double precision as the default: =E2=80=9Cif any arithme=
tic=20
> argument corresponding to a double parameter has type double or an intege=
r=20
> type, then all arithmetic arguments corresponding to double parameters ar=
e=20
> effectively cast to double.=E2=80=9D
>
> You could argue this as a library defect, that it should say, =E2=80=9Cif=
 any=20
> arithmetic argument *of non-floating-point type is convertible to*=20
> double, then =E2=80=A6=E2=80=9D The problem is in <cmath> and the SFINAE =
used to=20
> implement this case, not not in integral_constant.
>
>
Sure, I agree with that solution.
=20

> Either way, it=E2=80=99s surprising that exp2(std::integral_constant<5>()=
) is=20
> different from=20
> exp2(std::integral_constant<2>()+std::integral_constant<3>()), and the=20
> same applies to user-defined classes that similarly convert to numeric=20
> type. It would be nice to see both operators and <cmath> support.
>
> To avoid breakage, perhaps <cmath> conversions should be enabled via a=20
> standard user-defined type trait, say std::numeric_limits::native_cmath.
>

Though perhaps it should be the case that those conversions are enabled=20
when std::numeric_limits is specialized for the given type at all.

The most convenient way right now for different libraries and the standard=
=20
to 'communicate' that a given type is numeric, without having to coordinate=
=20
among themselves, is by specializing numeric_limits.

--=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_970_736834410.1423715421242
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, February 12, 2015 at 1:37:40 AM UTC-2, David =
Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"wor=
d-wrap:break-word"><div><div>This is because promotion rank isn=E2=80=99t c=
onsidered in overload ordering. From the perspective of overload resolution=
, such programs tend to be underspecified because there=E2=80=99s no good w=
ay to tell what floating-point precision is suitable for an integer argumen=
t.</div><div><br></div><div>On the other hand, [c.math] =C2=A726.8/11 requi=
res expressions like&nbsp;<font face=3D"Courier">exp2(5)</font> to work by =
defining double precision as the default: =E2=80=9Cif any arithmetic argume=
nt corresponding to a&nbsp;double&nbsp;parameter has type&nbsp;double&nbsp;=
or an&nbsp;integer type, then all&nbsp;arithmetic arguments corresponding t=
o&nbsp;double&nbsp;parameters are effectively cast to&nbsp;double.=E2=80=9D=
</div><div><br></div><div>You could argue this as a library defect, that it=
 should say, =E2=80=9Cif any arithmetic argument&nbsp;<i>of non-floating-po=
int type is convertible to</i> double, then =E2=80=A6=E2=80=9D The problem =
is in <font face=3D"Courier">&lt;cmath&gt;</font> and the SFINAE used to im=
plement this case, not not in <font face=3D"Courier">integral_constant</fon=
t>.</div><div><br></div></div></div></blockquote><div><br>Sure, I agree wit=
h that solution.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div style=3D"word-wrap:break-word"><div><div></div><div>Either way, it=
=E2=80=99s surprising that <font face=3D"Courier">exp2(std::integral_consta=
nt&lt;5&gt;<wbr>())</font> is different from <font face=3D"Courier">exp2(st=
d::integral_constant&lt;2&gt;<wbr>()+std::integral_constant&lt;3&gt;()<wbr>=
)</font>, and the same applies to user-defined classes that similarly conve=
rt to numeric type. It would be nice to see both operators and&nbsp;<span s=
tyle=3D"font-family:Courier">&lt;cmath&gt;</span>&nbsp;support.</div><div><=
br></div><div><div>To avoid breakage, perhaps&nbsp;<span style=3D"font-fami=
ly:Courier">&lt;cmath&gt;</span>&nbsp;conversions should be enabled via a s=
tandard user-defined type trait, say&nbsp;<font face=3D"Courier">std::numer=
ic_limits::<wbr>native_cmath</font>.</div></div></div></div></blockquote><d=
iv><br><code>Though perhaps it should be the case that those conversions ar=
e enabled when std::numeric_limits is specialized for the given type at all=
..<br><br>The most convenient way right now for different libraries and the =
standard to 'communicate' that a given type is numeric, without having to c=
oordinate among themselves, is by specializing numeric_limits.<br></code><c=
ode class=3D"prettyprint"><span style=3D"color: #660;" class=3D"styled-by-p=
rettify"></span><span style=3D"color: #660;" class=3D"styled-by-prettify"><=
/span></code></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_970_736834410.1423715421242--
------=_Part_969_1987811027.1423715421242--

.

--Apple-Mail=_D3BDBCC8-ABBF-487E-8E09-8611FD9F0675
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9302=E2=80=9312, at 12:30 PM, Matheus Izvekov <mizvekov@gma=
il.com> wrote:
>=20
> On Thursday, February 12, 2015 at 1:37:40 AM UTC-2, David Krauss wrote:
> To avoid breakage, perhaps <cmath> conversions should be enabled via a st=
andard user-defined type trait, say std::numeric_limits::native_cmath.
>=20
> Though perhaps it should be the case that those conversions are enabled w=
hen std::numeric_limits is specialized for the given type at all.
>=20
> The most convenient way right now for different libraries and the standar=
d to 'communicate' that a given type is numeric, without having to coordina=
te among themselves, is by specializing numeric_limits.

I just suggested a new numeric_limits member because adding cmath overloads=
 (or enabling existing overloads with relaxed SFINAE) might disturb existin=
g numeric classes that already have their own overloads.

If std::exp2 is enabled for all types that convert to double, then the user=
 can=E2=80=99t access some numeric_lib::exp2 by ADL unless it=E2=80=99s mor=
e specialized than the standard one. That=E2=80=99s not really library-frie=
ndly.

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

--Apple-Mail=_D3BDBCC8-ABBF-487E-8E09-8611FD9F0675
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9302=
=E2=80=9312, at 12:30 PM, Matheus Izvekov &lt;<a href=3D"mailto:mizvekov@gm=
ail.com" class=3D"">mizvekov@gmail.com</a>&gt; wrote:</div><br class=3D"App=
le-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">On Thur=
sday, February 12, 2015 at 1:37:40 AM UTC-2, David Krauss wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word" class=
=3D""><div class=3D""><div class=3D"">To avoid breakage, perhaps&nbsp;<span=
 class=3D"" style=3D"font-family: Courier;">&lt;cmath&gt;</span>&nbsp;conve=
rsions should be enabled via a standard user-defined type trait, say&nbsp;<=
font face=3D"Courier" class=3D"">std::numeric_limits::<wbr class=3D"">nativ=
e_cmath</font>.</div></div></div></blockquote><div class=3D""><br class=3D"=
"><font face=3D"Helvetica" class=3D""><code class=3D"">Though perhaps it sh=
ould be the case that those conversions are enabled when std::numeric_limit=
s is specialized for the given type at all.<br class=3D""><br class=3D"">Th=
e most convenient way right now for different libraries and the standard to=
 'communicate' that a given type is numeric, without having to coordinate a=
mong themselves, is by specializing numeric_limits.<br class=3D""></code><c=
ode class=3D"prettyprint"><span style=3D"color: #660;" class=3D"styled-by-p=
rettify"></span><span style=3D"color: #660;" class=3D"styled-by-prettify"><=
/span></code></font></div></div></div></blockquote><br class=3D""></div><di=
v>I just suggested a new numeric_limits member because adding cmath overloa=
ds (or enabling existing overloads with relaxed SFINAE) might disturb exist=
ing numeric classes that already have their own overloads.</div><div><br cl=
ass=3D""></div><div>If <font face=3D"Courier" class=3D"">std::exp2</font> i=
s enabled for all types that convert to double, then the user can=E2=80=99t=
 access some&nbsp;<font face=3D"Courier" class=3D"">numeric_lib::exp2</font=
>&nbsp;by ADL unless it=E2=80=99s more specialized than the standard one. T=
hat=E2=80=99s not really library-friendly.</div></body></html>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--Apple-Mail=_D3BDBCC8-ABBF-487E-8E09-8611FD9F0675--

.

------=_Part_6250_2017234286.1423717646682
Content-Type: multipart/alternative;
 boundary="----=_Part_6251_315678422.1423717646682"

------=_Part_6251_315678422.1423717646682
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, February 12, 2015 at 2:55:45 AM UTC-2, David Krauss wrote:
>
> I just suggested a new numeric_limits member because adding cmath=20
> overloads (or enabling existing overloads with relaxed SFINAE) might=20
> disturb existing numeric classes that already have their own overloads.
>
> If std::exp2 is enabled for all types that convert to double, then the=20
> user can=E2=80=99t access some numeric_lib::exp2 by ADL unless it=E2=80=
=99s more=20
> specialized than the standard one. That=E2=80=99s not really library-frie=
ndly.
>

Yes I had thought of that, but would there be compelling cases where the=20
numeric_lib author would not be able to implement a more specialized exp2?
This would keep things simpler, and such breakage would probably be=20
acceptable when going for a new C++ standard revision.


--=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_6251_315678422.1423717646682
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, February 12, 2015 at 2:55:45 AM UTC-2, David =
Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"wor=
d-wrap:break-word"><div></div><div>I just suggested a new numeric_limits me=
mber because adding cmath overloads (or enabling existing overloads with re=
laxed SFINAE) might disturb existing numeric classes that already have thei=
r own overloads.</div><div><br></div><div>If <font face=3D"Courier">std::ex=
p2</font> is enabled for all types that convert to double, then the user ca=
n=E2=80=99t access some&nbsp;<font face=3D"Courier">numeric_lib::exp2</font=
>&nbsp;by ADL unless it=E2=80=99s more specialized than the standard one. T=
hat=E2=80=99s not really library-friendly.</div></div></blockquote><div><br=
>Yes I had thought of that, but would there be compelling cases where the n=
umeric_lib author would not be able to implement a more specialized exp2?<b=
r>This would keep things simpler, and such breakage would probably be accep=
table when going for a new C++ standard revision.<br><br><br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_6251_315678422.1423717646682--
------=_Part_6250_2017234286.1423717646682--

.

--Apple-Mail=_B44C0A8F-5FFE-4800-BFA0-5B90AC2FB24B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9302=E2=80=9312, at 1:07 PM, Matheus Izvekov <mizvekov@gmai=
l.com> wrote:
>=20
> On Thursday, February 12, 2015 at 2:55:45 AM UTC-2, David Krauss wrote:
> I just suggested a new numeric_limits member because adding cmath overloa=
ds (or enabling existing overloads with relaxed SFINAE) might disturb exist=
ing numeric classes that already have their own overloads.
>=20
> If std::exp2 is enabled for all types that convert to double, then the us=
er can=E2=80=99t access some numeric_lib::exp2 by ADL unless it=E2=80=99s m=
ore specialized than the standard one. That=E2=80=99s not really library-fr=
iendly.
>=20
> Yes I had thought of that, but would there be compelling cases where the =
numeric_lib author would not be able to implement a more specialized exp2?
> This would keep things simpler, and such breakage would probably be accep=
table when going for a new C++ standard revision.

There are two alternatives:

1. Some libraries get extra functionality automatically. They have to verif=
y that this works properly and it=E2=80=99s in line with whatever is the ph=
ilosophy of the library. If not, the alternatives are to provide all the cm=
ath overloads with deleted definitions, or just to document that these func=
tions compile but they=E2=80=99re broken.

Other libraries break with the new standard. Their cmath overloads (potenti=
ally all of them) need to be converted from one undifferentiated SFINAE bas=
ed on internal traits, to one overload per internal template that can gener=
ate an operand. (Not only base templates, which don=E2=80=99t affect specia=
lization.) That=E2=80=99s potentially a ton of bloat.

2. Library authors wanting the new functionality can test and enable it.

I think it=E2=80=99s better to leave the responsibility in the hands of lib=
rary authors. User-facing features shouldn=E2=80=99t be added to old templa=
te libraries except for things that are 100% broken or slam dunks.

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

--Apple-Mail=_B44C0A8F-5FFE-4800-BFA0-5B90AC2FB24B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9302=
=E2=80=9312, at 1:07 PM, Matheus Izvekov &lt;<a href=3D"mailto:mizvekov@gma=
il.com" class=3D"">mizvekov@gmail.com</a>&gt; wrote:</div><br class=3D"Appl=
e-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">On Thurs=
day, February 12, 2015 at 2:55:45 AM UTC-2, David Krauss wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word" class=
=3D""><div class=3D""></div><div class=3D"">I just suggested a new numeric_=
limits member because adding cmath overloads (or enabling existing overload=
s with relaxed SFINAE) might disturb existing numeric classes that already =
have their own overloads.</div><div class=3D""><br class=3D""></div><div cl=
ass=3D"">If <font face=3D"Courier" class=3D"">std::exp2</font> is enabled f=
or all types that convert to double, then the user can=E2=80=99t access som=
e&nbsp;<font face=3D"Courier" class=3D"">numeric_lib::exp2</font>&nbsp;by A=
DL unless it=E2=80=99s more specialized than the standard one. That=E2=80=
=99s not really library-friendly.</div></div></blockquote><div class=3D""><=
br class=3D"">Yes I had thought of that, but would there be compelling case=
s where the numeric_lib author would not be able to implement a more specia=
lized exp2?<br class=3D"">This would keep things simpler, and such breakage=
 would probably be acceptable when going for a new C++ standard revision.<b=
r class=3D""></div></div></div></blockquote><div><br class=3D""></div><div>=
There are two alternatives:</div><div><br class=3D""></div><div>1. Some lib=
raries get extra functionality automatically. They have to verify that this=
 works properly and it=E2=80=99s in line with whatever is the philosophy of=
 the library. If not, the alternatives are to provide all the cmath overloa=
ds with deleted definitions, or just to document that these functions compi=
le but they=E2=80=99re broken.</div><div><br class=3D""></div><div>Other li=
braries break with the new standard. Their cmath overloads (potentially all=
 of them) need to be converted from one undifferentiated SFINAE based on in=
ternal traits, to one overload per internal template that can generate an o=
perand. (Not only base templates, which don=E2=80=99t affect specialization=
..) That=E2=80=99s potentially a ton of bloat.</div><div><br class=3D""></di=
v><div>2. Library authors wanting the new functionality can test and enable=
 it.</div><div><br class=3D""></div><div>I think it=E2=80=99s better to lea=
ve the responsibility in the hands of library authors. User-facing features=
 shouldn=E2=80=99t be added to old template libraries except for things tha=
t are 100% broken or slam dunks.</div></div></body></html>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--Apple-Mail=_B44C0A8F-5FFE-4800-BFA0-5B90AC2FB24B--

.

------=_Part_1184_881404770.1423720426637
Content-Type: multipart/alternative;
 boundary="----=_Part_1185_427772384.1423720426638"

------=_Part_1185_427772384.1423720426638
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, February 12, 2015 at 3:23:07 AM UTC-2, David Krauss wrote:
>
> There are two alternatives:
>
> 1. Some libraries get extra functionality automatically. They have to=20
> verify that this works properly and it=E2=80=99s in line with whatever is=
 the=20
> philosophy of the library. If not, the alternatives are to provide all th=
e=20
> cmath overloads with deleted definitions, or just to document that these=
=20
> functions compile but they=E2=80=99re broken.
>
> Other libraries break with the new standard. Their cmath overloads=20
> (potentially all of them) need to be converted from one undifferentiated=
=20
> SFINAE based on internal traits, to one overload per internal template th=
at=20
> can generate an operand. (Not only base templates, which don=E2=80=99t af=
fect=20
> specialization.) That=E2=80=99s potentially a ton of bloat.
>
> 2. Library authors wanting the new functionality can test and enable it.
>
> I think it=E2=80=99s better to leave the responsibility in the hands of l=
ibrary=20
> authors. User-facing features shouldn=E2=80=99t be added to old template =
libraries=20
> except for things that are 100% broken or slam dunks.
>

Well you make a convincing point, if it would break too much code and it=20
would be too much work to fix, then perhaps disabling it by default is for=
=20
the best.

So, it seems this problem can be tackled right now and in isolation, and it=
=20
looks simple enough that an LEWG issue would be appropriate.

Do you want to submit it yourself? Or should I?

--=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_1185_427772384.1423720426638
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, February 12, 2015 at 3:23:07 AM UTC-2, David =
Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"wor=
d-wrap:break-word"><div><div>There are two alternatives:</div><div><br></di=
v><div>1. Some libraries get extra functionality automatically. They have t=
o verify that this works properly and it=E2=80=99s in line with whatever is=
 the philosophy of the library. If not, the alternatives are to provide all=
 the cmath overloads with deleted definitions, or just to document that the=
se functions compile but they=E2=80=99re broken.</div><div><br></div><div>O=
ther libraries break with the new standard. Their cmath overloads (potentia=
lly all of them) need to be converted from one undifferentiated SFINAE base=
d on internal traits, to one overload per internal template that can genera=
te an operand. (Not only base templates, which don=E2=80=99t affect special=
ization.) That=E2=80=99s potentially a ton of bloat.</div><div><br></div><d=
iv>2. Library authors wanting the new functionality can test and enable it.=
</div><div><br></div><div>I think it=E2=80=99s better to leave the responsi=
bility in the hands of library authors. User-facing features shouldn=E2=80=
=99t be added to old template libraries except for things that are 100% bro=
ken or slam dunks.</div></div></div></blockquote><div><br>Well you make a c=
onvincing point, if it would break too much code and it would be too much w=
ork to fix, then perhaps disabling it by default is for the best.<br><br>So=
, it seems this problem can be tackled right now and in isolation, and it l=
ooks simple enough that an LEWG issue would be appropriate.<br><br>Do you w=
ant to submit it yourself? Or should I?<br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_1185_427772384.1423720426638--
------=_Part_1184_881404770.1423720426637--

.