Topic: What header should int_t go to?
Author: Myriachan <myriachan@gmail.com>
Date: Tue, 6 Sep 2016 10:37:21 -0700 (PDT)
Raw View
------=_Part_11102_274957444.1473183441926
Content-Type: multipart/alternative;
boundary="----=_Part_11103_1392317930.1473183441926"
------=_Part_11103_1392317930.1473183441926
Content-Type: text/plain; charset=UTF-8
I wanted to write a formal proposal for the std::int_t<BITS> idea that I
(and others came up with before me), but I don't know a few things.
For those who didn't see it before, std::int_t<BITS> and related templates
(such as std::uint_fast_t<BITS>) are aliases for std::intBITS_t, so that
metaprogramming can select an integer type from the bit count.
First, which header should get this template? It most naturally fits in
<cstdint>, but that breaks the paradigm of <cwhatever> only having what is
in <whatever.h> from C. <cinttypes> similarly. <limits> would work, but
seems awkward.
Second, what is the formal wording for something like "the specialization
shall not exist"? I would think something like "int_t<B> shall be an alias
for intB_t, if it exists, or shall fail to substitute".
Melissa
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7cbe6aa9-da9b-4cb4-90ca-838fb815d1fc%40isocpp.org.
------=_Part_11103_1392317930.1473183441926
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I wanted to write a formal proposal for the std::int_t<=
BITS> idea that I (and others came up with before me), but I don't k=
now a few things.<br><br>For those who didn't see it before, std::int_t=
<BITS> and related templates (such as std::uint_fast_t<BITS>) a=
re aliases for std::intBITS_t, so that metaprogramming can select an intege=
r type from the bit count.<br><br>First, which header should get this templ=
ate?=C2=A0 It most naturally fits in <cstdint>, but that breaks the p=
aradigm of <cwhatever> only having what is in <whatever.h> from=
C.=C2=A0 <cinttypes> similarly.=C2=A0 <limits> would work, but=
seems awkward.<br><br>Second, what is the formal wording for something lik=
e "the specialization shall not exist"?=C2=A0 I would think somet=
hing like "int_t<B> shall be an alias for intB_t, if it exists, =
or shall fail to substitute".<br><br>Melissa<br><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7cbe6aa9-da9b-4cb4-90ca-838fb815d1fc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7cbe6aa9-da9b-4cb4-90ca-838fb815d1fc=
%40isocpp.org</a>.<br />
------=_Part_11103_1392317930.1473183441926--
------=_Part_11102_274957444.1473183441926--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 6 Sep 2016 21:26:58 +0300
Raw View
On 6 September 2016 at 20:37, Myriachan <myriachan@gmail.com> wrote:
> I wanted to write a formal proposal for the std::int_t<BITS> idea that I
> (and others came up with before me), but I don't know a few things.
>
> For those who didn't see it before, std::int_t<BITS> and related templates
> (such as std::uint_fast_t<BITS>) are aliases for std::intBITS_t, so that
> metaprogramming can select an integer type from the bit count.
>
> First, which header should get this template? It most naturally fits in
> <cstdint>, but that breaks the paradigm of <cwhatever> only having what is
> in <whatever.h> from C. <cinttypes> similarly. <limits> would work, but
> seems awkward.
I actually wouldn't find it horrible to put that stuff into <type_traits>.
> Second, what is the formal wording for something like "the specialization
> shall not exist"? I would think something like "int_t<B> shall be an alias
> for intB_t, if it exists, or shall fail to substitute".
"int_t<B> is an alias for intB_t if the implementation provides the
type intB_t, otherwise
a program that uses the specialization int_t<B> is ill-formed."? I
don't know whether we really
say something like that elsewhere, I just pulled that out of my hat.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbgQrdzqUyUyEV94MwvEyBgm3yDuKeQoMuKKaPE7JkP9Q%40mail.gmail.com.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Tue, 06 Sep 2016 15:03:27 -0400
Raw View
I'm not sure whether =C2=A0'uses the specialization' means SFINAE or not.=
=C2=A0
I think the request is for wording that means you can sfinae on int_t<N>.
Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Ville Voutilainen
Sent: Tuesday, September 6, 2016 2:26 PM
To: ISO C++ Standard - Future Proposals
Reply To: std-proposals@isocpp.org
Subject: Re: [std-proposals] What header should int_t go to?
On 6 September 2016 at 20:37, Myriachan <myriachan@gmail.com> wrote:
> I wanted to write a formal proposal for the std::int_t<BITS> idea that I
> (and others came up with before me), but I don't know a few things.
>
> For those who didn't see it before, std::int_t<BITS> and related template=
s
> (such as std::uint_fast_t<BITS>) are aliases for std::intBITS_t, so that
> metaprogramming can select an integer type from the bit count.
>
> First, which header should get this template? It most naturally fits in
> <cstdint>, but that breaks the paradigm of <cwhatever> only having what i=
s
> in <whatever.h> from C. <cinttypes> similarly. <limits> would work, but
> seems awkward.
I actually wouldn't find it horrible to put that stuff into <type_traits>.
> Second, what is the formal wording for something like "the specialization
> shall not exist"? I would think something like "int_t<B> shall be an alia=
s
> for intB_t, if it exists, or shall fail to substitute".
"int_t<B> is an alias for intB_t if the implementation provides the
type intB_t, otherwise
a program that uses the specialization int_t<B> is ill-formed."? I
don't know whether we really
say something like that elsewhere, I just pulled that out of my hat.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUbgQrdzqUyUyEV94MwvEyBgm3yDuKeQoMuKKaPE7Jk=
P9Q%40mail.gmail.com.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20160906190327.4890705.85707.16623%40gmail.com.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 6 Sep 2016 22:32:33 +0300
Raw View
On 6 September 2016 at 22:03, Tony V E <tvaneerd@gmail.com> wrote:
> I'm not sure whether 'uses the specialization' means SFINAE or not.
> I think the request is for wording that means you can sfinae on int_t<N>.
I am unaware of a way to sfinae on mentioning a specialization. I know how
to sfinae on expressions that use the type. As in
http://cplusplus.github.io/LWG/lwg-active.html#2543
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbNn70aSPJJJDTvs-Kyo5d0VPKxBVekm%3D2op6SUBfKi3g%40mail.gmail.com.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 6 Sep 2016 23:18:44 +0300
Raw View
On 6 September 2016 at 22:32, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> I am unaware of a way to sfinae on mentioning a specialization. I know how
> to sfinae on expressions that use the type. As in
> http://cplusplus.github.io/LWG/lwg-active.html#2543
Well, ok, I am actually aware of such a way, given a good enough C++
compiler that implements
a certain Technical Specification:
#include <type_traits>
#include <iostream>
template <class T> requires !std::is_integral_v<T>
struct Wrap
{
Wrap() = default;
};
template <class T> void f(const T&, const Wrap<T>* = 0)
{
std::cout << "wrap" << std::endl;
}
template <class T> void f(...)
{
std::cout << "T" << std::endl;
}
int main()
{
int x = 42;
double y = 0.666;
f<int>(x);
f<double>(y);
}
The code prints
T
wrap
http://melpon.org/wandbox/permlink/zMgN7xgCmDQHwN6a
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUb32Yy2YmySg3saKL%3D656baxfKCVEkvac4_GbzM1mu6rg%40mail.gmail.com.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 6 Sep 2016 23:24:41 +0300
Raw View
On 6 September 2016 at 23:18, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 6 September 2016 at 22:32, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>> I am unaware of a way to sfinae on mentioning a specialization. I know how
>> to sfinae on expressions that use the type. As in
>> http://cplusplus.github.io/LWG/lwg-active.html#2543
>
> Well, ok, I am actually aware of such a way, given a good enough C++
> compiler that implements
> a certain Technical Specification:
A much simpler example (note that without the constraint, the code
would call the wrap-case for both
calls).
#include <type_traits>
#include <iostream>
template <class T> requires !std::is_integral_v<T>
struct Wrap;
template <class T> void f(const T&, const Wrap<T>* = 0)
{
std::cout << "wrap" << std::endl;
}
void f(...)
{
std::cout << "T" << std::endl;
}
int main()
{
int x = 42;
double y = 0.666;
f(x);
f(y);
}
http://melpon.org/wandbox/permlink/j7AH29tKoUAO7ndv
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbg%2BaP1GhxxWo%3DSsqhtmCKNDmxChtAZ2OYo_1ubR3vtVA%40mail.gmail.com.
.
Author: Myriachan <myriachan@gmail.com>
Date: Tue, 6 Sep 2016 13:42:38 -0700 (PDT)
Raw View
------=_Part_16_1067678415.1473194559031
Content-Type: multipart/alternative;
boundary="----=_Part_17_1650542600.1473194559037"
------=_Part_17_1650542600.1473194559037
Content-Type: text/plain; charset=UTF-8
On Tuesday, September 6, 2016 at 1:24:43 PM UTC-7, Ville Voutilainen wrote:
>
> >> I am unaware of a way to sfinae on mentioning a specialization. I know
> how
> >> to sfinae on expressions that use the type. As in
> >> http://cplusplus.github.io/LWG/lwg-active.html#2543
>
>
I mean substitution failure for SFINAE along these lines, where the output
is "1 2 99 4":
#include <climits>
#include <cstdint>
#include <cstdio>
#include <cstring>
#include <type_traits>
namespace meow //std
{
template <int B>
struct _int_t_helper;
template <> struct _int_t_helper<8> { typedef std::int8_t type; };
template <> struct _int_t_helper<16> { typedef std::int16_t type; };
template <> struct _int_t_helper<32> { typedef std::int32_t type; };
template <> struct _int_t_helper<64> { typedef std::int64_t type; };
template <int B>
using int_t = typename _int_t_helper<B>::type;
}
char (&Function(...))[99];
template <int S>
meow::int_t<S * CHAR_BIT> Function(unsigned char (&)[S]);
int main()
{
unsigned char buffer1[1];
unsigned char buffer2[2];
unsigned char buffer3[3];
unsigned char buffer4[4];
std::printf("%zu %zu %zu %zu\n", sizeof(Function(buffer1)), sizeof(
Function(buffer2)),
sizeof(Function(buffer3)), sizeof(Function(buffer4)));
}
Melissa
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f18a15c2-0cca-4b02-a563-b10fedfef531%40isocpp.org.
------=_Part_17_1650542600.1473194559037
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, September 6, 2016 at 1:24:43 PM UTC-7, Ville V=
outilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">>> I am=
unaware of a way to sfinae on mentioning a specialization. I know how
<br>>> to sfinae on expressions that use the type. As in
<br>>> <a href=3D"http://cplusplus.github.io/LWG/lwg-active.html#2543=
" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fcplusplus.github.io%2FLWG%2Flwg-activ=
e.html%232543\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGdNJipBc0C2wvgm9TPUGg=
Wugh6HQ';return true;" onclick=3D"this.href=3D'http://www.google.co=
m/url?q\x3dhttp%3A%2F%2Fcplusplus.github.io%2FLWG%2Flwg-active.html%232543\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGdNJipBc0C2wvgm9TPUGgWugh6HQ';r=
eturn true;">http://cplusplus.github.io/<wbr>LWG/lwg-active.html#2543</a>
<br><br></blockquote><div><br>I mean substitution failure for SFINAE along =
these lines, where the output is "1 2 99 4":<br><br><div class=3D=
"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: =
rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: brea=
k-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span st=
yle=3D"color: #800;" class=3D"styled-by-prettify">#include</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #080;" class=3D"styled-by-prettify"><climits></span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #800;" class=3D"styled-by-prettify">#include</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" cl=
ass=3D"styled-by-prettify"><cstdint></span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" cla=
ss=3D"styled-by-prettify">#include</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"style=
d-by-prettify"><cstdio></span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #800;" class=3D"styled-=
by-prettify">#include</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify=
"><cstring></span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>#include</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #080;" class=3D"styled-by-prettify"><type_t=
raits></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">nam=
espace</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> meo=
w =C2=A0</span><span style=3D"color: #800;" class=3D"styled-by-prettify">//=
std</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">template</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> B</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> _int_t_helper</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br>=C2=A0 =C2=A0 </span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">template</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify"><></span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">struct</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> _int_t_helper</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify"><</span><span style=3D"color: #066;" class=3D"styled-by-p=
rettify">8</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">typedef</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">int8_t type</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">template</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"><=
;></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> _int_t_helper</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><sp=
an style=3D"color: #066;" class=3D"styled-by-prettify">16</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D"co=
lor: #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: #008;" class=3D"style=
d-by-prettify">typedef</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">in=
t16_t type</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: #660;" class=3D"styled-by-prettify">};</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">template</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><></span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> _int_t_helper</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #066=
;" class=3D"styled-by-prettify">32</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">typedef</=
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 sty=
le=3D"color: #000;" class=3D"styled-by-prettify">int32_t type</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">template</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: #008;" class=3D"style=
d-by-prettify">struct</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> _int_t_helper</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify"><</span><span style=3D"color: #066;" class=3D"styled-by-p=
rettify">64</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><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: #008;" class=3D"styled-by-prettify">typedef</span><span style=3D"col=
or: #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">int64_t type</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: #660;" class=3D"styled-by-=
prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">template</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y"><</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int=
</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 s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">using</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> int_t </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> _int_t_helper</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">>::</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">type</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">char</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(&</span><span style=3D=
"color: #606;" class=3D"styled-by-prettify">Function</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(...))[</span><span style=3D"colo=
r: #066;" class=3D"styled-by-prettify">99</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">];</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">template</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> S</span><span style=3D"color: #660;" class=3D"styled-by-prettify">></=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>meow</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">int_t</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">S </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> CHAR_BIT</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-p=
rettify">Function</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">un=
signed</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">char</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">S</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">]);</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> main</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">unsigned</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">char</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> buffer1</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span s=
tyle=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">];</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">unsigned</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">char</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> buffer2</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">[</span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">2</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">];</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">unsigned</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">char<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> buffer3</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span=
style=3D"color: #066;" class=3D"styled-by-prettify">3</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">];</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">unsigned</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">char</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> buffer4</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">[</span><span style=3D"color: #066;" class=3D"styl=
ed-by-prettify">4</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">];</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>=C2=A0 =C2=A0 std</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">printf</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #080;" class=3D"styled-by-prettify">"%zu %=
zu %zu %zu\n"</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">sizeof</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #606;" class=3D"styled-by-prettify">Function</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">buffer1</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: #008;" class=
=3D"styled-by-prettify">sizeof</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #606;" class=3D"styled-by=
-prettify">Function</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
buffer2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)),=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">sizeof</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #606;" cl=
ass=3D"styled-by-prettify">Function</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">buffer3</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">)),</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">siz=
eof</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">Function</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">buffer4</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)));</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span></div></code></div><br>Melissa<br></di=
v></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f18a15c2-0cca-4b02-a563-b10fedfef531%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f18a15c2-0cca-4b02-a563-b10fedfef531=
%40isocpp.org</a>.<br />
------=_Part_17_1650542600.1473194559037--
------=_Part_16_1067678415.1473194559031--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Tue, 6 Sep 2016 16:46:06 -0400
Raw View
--001a114b2af8c42fec053bdce267
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, Sep 6, 2016 at 3:32 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 6 September 2016 at 22:03, Tony V E <tvaneerd@gmail.com> wrote:
> > I'm not sure whether 'uses the specialization' means SFINAE or not.
> > I think the request is for wording that means you can sfinae on int_t<N=
>.
>
> I am unaware of a way to sfinae on mentioning a specialization. I know ho=
w
> to sfinae on expressions that use the type. As in
> http://cplusplus.github.io/LWG/lwg-active.html#2543
Sure, as in LWG2543. Just need to be able to "ask" via sfinae whether
int_t<12> is a usable type or not. Without it going straight to
"ill-formed do not pass sfinae, do not collect 200 dollars".
P.S. the resolution of LWG2543:
-?- For any type T that is not of integral or enumeration type, or for
which neither the library nor the user provides an explicit or partial
specialization of the class template hash, the specialization of hash<T>
has the following properties:
- is_default_constructible_v<hash<T>> is false
- is_copy_constructible_v<hash<T>> is false
- is_move_constructible_v<hash<T>> is false
- is_copy_assignable_v<hash<T>> is false
- is_move_assignable_v<hash<T>> is false
- hash<T> is not a function object type (20.14 [function.objects])
[*Note:* this means that the specialization of hash exists, but any
attempts to use it as a Hash will be ill-formed. =E2=80=94 end note]
basically - including the note - says "if no one (including the library)
specialized hash<T>, then the library specialized hash<T> (with a strange
specialization)".
ie it says that the library didn't specialize it, then it did. Or where
does the specialization - that does exist according to the note - come
from, if not the library?
I understand what it is trying to say, but the wording (or just the note)
might still be a bit off?
--=20
Be seeing you,
Tony
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOHCbiva3E3Lfa9tMTBUYsPxASVpvcO1BhSQSNHNDndW372=
%2BWg%40mail.gmail.com.
--001a114b2af8c42fec053bdce267
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Sep 6, 2016 at 3:32 PM, Ville Voutilainen <span dir=3D"ltr"><=
;<a target=3D"_blank" href=3D"mailto:ville.voutilainen@gmail.com">ville.vou=
tilainen@gmail.com</a>></span> wrote:<br><blockquote style=3D"margin:0px=
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" cla=
ss=3D"gmail_quote"><span class=3D"gmail-">On 6 September 2016 at 22:03, Ton=
y V E <<a href=3D"mailto:tvaneerd@gmail.com">tvaneerd@gmail.com</a>> =
wrote:<br>
> I'm not sure whether=C2=A0 'uses the specialization' means=
SFINAE or not.<br>
> I think the request is for wording that means you can sfinae on int_t&=
lt;N>.<br>
<br>
</span>I am unaware of a way to sfinae on mentioning a specialization. I kn=
ow how<br>
to sfinae on expressions that use the type. As in<br>
<a target=3D"_blank" rel=3D"noreferrer" href=3D"http://cplusplus.github.io/=
LWG/lwg-active.html#2543">http://cplusplus.github.io/<wbr>LWG/lwg-active.ht=
ml#2543</a></blockquote><div><br></div><div>Sure, as in LWG2543.=C2=A0 Just=
need to be able to "ask" via sfinae whether int_t<12> is a=
usable type or not.=C2=A0 Without it going straight to "ill-formed do=
not pass sfinae, do not collect 200 dollars". <br><br></div><div>P.S.=
the resolution of LWG2543:<br><br><p>
<ins>-?- For any type <tt>T</tt> that is not of integral or enumeration typ=
e, or for
which neither the library nor the user provides an explicit or partial spec=
ialization of the class
template hash, the specialization of <tt>hash<T></tt> has the followi=
ng properties:
</ins>
</p>
<ul><li><ins><tt>is_default_constructible_v<hash<T>></tt> is <t=
t>false</tt></ins></li><li><ins><tt>is_copy_constructible_v<hash<T>=
;></tt> is <tt>false</tt></ins></li><li><ins><tt>is_move_constructible_v=
<hash<T>></tt> is <tt>false</tt></ins></li><li><ins><tt>is_copy=
_assignable_v<hash<T>></tt> is <tt>false</tt></ins></li><li><in=
s><tt>is_move_assignable_v<hash<T>></tt> is <tt>false</tt></ins=
></li><li><ins><tt>hash<T></tt> is not a function object type (20.14 =
[function.objects])</ins></li></ul>
<p>
<ins>[<i>Note:</i> this means that the specialization of <tt>hash</tt> exis=
ts, but any
attempts to use it as a <tt>Hash</tt> will be ill-formed. =E2=80=94 end not=
e]</ins>
</p><br></div><div>basically - including the note - says=C2=A0 "if no =
one (including the library) specialized hash<T>, then the library spe=
cialized hash<T> (with a strange specialization)".<br><br></div>=
<div>ie it says that the library didn't specialize it, then it did.=C2=
=A0 Or where does the specialization - that does exist according to the not=
e - come from, if not the library?<br><br></div><div>I understand what it i=
s trying to say, but the wording (or just the note) might still be a bit of=
f?<br><br></div><br clear=3D"all"></div>-- <br><div class=3D"gmail_signatur=
e"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiva3E3Lfa9tMTBUYsPxASVpvcO1BhSQ=
SNHNDndW372%2BWg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiva3E3Lfa=
9tMTBUYsPxASVpvcO1BhSQSNHNDndW372%2BWg%40mail.gmail.com</a>.<br />
--001a114b2af8c42fec053bdce267--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 6 Sep 2016 23:51:49 +0300
Raw View
On 6 September 2016 at 23:42, Myriachan <myriachan@gmail.com> wrote:
> On Tuesday, September 6, 2016 at 1:24:43 PM UTC-7, Ville Voutilainen wrote:
>>
>> >> I am unaware of a way to sfinae on mentioning a specialization. I know
>> >> how
>> >> to sfinae on expressions that use the type. As in
>> >> http://cplusplus.github.io/LWG/lwg-active.html#2543
>>
>
> I mean substitution failure for SFINAE along these lines, where the output
> is "1 2 99 4":
Well, I can give you what you want either with concepts or with a
suitably-enable_if-constrained alias template.
The wording "using the specialization is ill-formed" gives you SFINAE,
since I didn't add ", no diagnostic required".
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUaYdY9NKtHDZL_X0ZcfuRoumcF9msx%2BzGAwmsfFhSfgAA%40mail.gmail.com.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 6 Sep 2016 23:58:20 +0300
Raw View
On 6 September 2016 at 23:46, Tony V E <tvaneerd@gmail.com> wrote:
> P.S. the resolution of LWG2543:
>
> -?- For any type T that is not of integral or enumeration type, or for wh=
ich
> neither the library nor the user provides an explicit or partial
> specialization of the class template hash, the specialization of hash<T> =
has
> the following properties:
>
> is_default_constructible_v<hash<T>> is false
> is_copy_constructible_v<hash<T>> is false
> is_move_constructible_v<hash<T>> is false
> is_copy_assignable_v<hash<T>> is false
> is_move_assignable_v<hash<T>> is false
> hash<T> is not a function object type (20.14 [function.objects])
>
> [Note: this means that the specialization of hash exists, but any attempt=
s
> to use it as a Hash will be ill-formed. =E2=80=94 end note]
>
>
> basically - including the note - says "if no one (including the library)
> specialized hash<T>, then the library specialized hash<T> (with a strange
> specialization)".
>
> ie it says that the library didn't specialize it, then it did. Or where
No, the library didn't specialize it, it achieved the effect of that wordin=
g
with the primary template. The library didn't provide an explicit or
partial specialization
for the type T. The specialization hash<T> for non-integral non-enum
type is a specialization of the primary
template. (Yeah, that P/R has been implemented. I know, I'm annoying
that way, I often
implement the P/Rs I write before sending them to lwgchair).
I suppose the note could say "is a complete type" instead of "exists".
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUbXGDQ6jQm2WrQbsp7DurYiYBXxTDaAUjT8fxA3nD4=
ebw%40mail.gmail.com.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 7 Sep 2016 00:06:59 +0300
Raw View
On 6 September 2016 at 23:58, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> No, the library didn't specialize it, it achieved the effect of that wording
> with the primary template. The library didn't provide an explicit or
> partial specialization
> for the type T. The specialization hash<T> for non-integral non-enum
> type is a specialization of the primary
> template. (Yeah, that P/R has been implemented. I know, I'm annoying
> that way, I often
> implement the P/Rs I write before sending them to lwgchair).
>
> I suppose the note could say "is a complete type" instead of "exists".
And, to answer your question "where did that specialization come from,
if not the library?", I suggest
you look at [temp.inst], which explains how the language conjures that
specialization out of thin air^W^W^W^Wfrom
the primary template when the program you wrote uses the specialization.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbZKSF%3DZW_6qWAbxmLOmzF_rmAps4r2N%3DcAgk%2Ba7mymNA%40mail.gmail.com.
.
Author: Myriachan <myriachan@gmail.com>
Date: Tue, 6 Sep 2016 14:25:44 -0700 (PDT)
Raw View
------=_Part_1902_333515333.1473197144598
Content-Type: multipart/alternative;
boundary="----=_Part_1903_652995835.1473197144598"
------=_Part_1903_652995835.1473197144598
Content-Type: text/plain; charset=UTF-8
On Tuesday, September 6, 2016 at 1:51:52 PM UTC-7, Ville Voutilainen wrote:
>
> On 6 September 2016 at 23:42, Myriachan <myri...@gmail.com <javascript:>>
> wrote:
> > I mean substitution failure for SFINAE along these lines, where the
> output
> > is "1 2 99 4":
>
>
> Well, I can give you what you want either with concepts or with a
> suitably-enable_if-constrained alias template.
> The wording "using the specialization is ill-formed" gives you SFINAE,
> since I didn't add ", no diagnostic required".
>
Does this work?
(int_t, uint_t)
int_t<B> is an alias for intB_t if the implementation provides the type
intB_t; otherwise, using the specialization int_t<B> is ill-formed.
(int_least_t, uint_least_t, int_fast_t, uint_fast_t)
int_least_t<B> is an alias for int_leastN_t, where N is the smallest
integer greater than or equal to B such that the implementation provides
int_leastN_t. If B is less than 1, or if B is greater than the largest
such integer N, using the specialization int_least_t<B> is ill-formed.
Would Standardese repeat those lines for all four variants, or somehow
reword it to apply to all four?
Does this need a "Note:" to make explicit the intent that the ill-formed
cases are meant to cause substitution failure for SFINAE, rather than
"hard" errors?
Melissa
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2323f8aa-64f4-4115-8054-3e9937932916%40isocpp.org.
------=_Part_1903_652995835.1473197144598
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, September 6, 2016 at 1:51:52 PM UTC-7, Ville V=
outilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 6 Septembe=
r 2016 at 23:42, Myriachan <<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"ISSa4O5SFAAJ" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D'javascript:';return true;" onclick=3D"this.href=3D'javas=
cript:';return true;">myri...@gmail.com</a>> wrote:
<br>> I mean substitution failure for SFINAE along these lines, where th=
e output
<br>> is "1 2 99 4":
<br>
<br>
<br>Well, I can give you what you want either with concepts or with a
<br>suitably-enable_if-constrained alias template.
<br>The wording "using the specialization is ill-formed" gives yo=
u SFINAE,
<br>since I didn't add ", no diagnostic required".
<br></blockquote><div><br>Does this work?<br><br>(int_t, uint_t)<br>int_t&l=
t;B> is an alias for intB_t if the implementation provides the type intB=
_t; otherwise, using the specialization int_t<B> is ill-formed.<br><b=
r>(int_least_t, uint_least_t, int_fast_t, uint_fast_t)<br>int_least_t<B&=
gt; is an alias for int_leastN_t, where N is the smallest integer greater t=
han or equal to B such that the implementation provides int_leastN_t.=C2=A0=
If B is less than 1, or if B is greater than the largest such integer N, u=
sing the specialization int_least_t<B> is ill-formed.<br><br>Would St=
andardese repeat those lines for all four variants, or somehow reword it to=
apply to all four?<br><br>Does this need a "Note:" to make expli=
cit the intent that the ill-formed cases are meant to cause substitution fa=
ilure for SFINAE, rather than "hard" errors?<br><br>Melissa<br></=
div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2323f8aa-64f4-4115-8054-3e9937932916%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2323f8aa-64f4-4115-8054-3e9937932916=
%40isocpp.org</a>.<br />
------=_Part_1903_652995835.1473197144598--
------=_Part_1902_333515333.1473197144598--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Tue, 6 Sep 2016 16:16:45 -0700 (PDT)
Raw View
------=_Part_1839_27450633.1473203805134
Content-Type: multipart/alternative;
boundary="----=_Part_1840_1446919085.1473203805147"
------=_Part_1840_1446919085.1473203805147
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, September 6, 2016 at 2:25:44 PM UTC-7, Myriachan wrote:
>
> On Tuesday, September 6, 2016 at 1:51:52 PM UTC-7, Ville Voutilainen wrot=
e:
>>
>> On 6 September 2016 at 23:42, Myriachan <myri...@gmail.com> wrote:=20
>> > I mean substitution failure for SFINAE along these lines, where the=20
>> output=20
>> > is "1 2 99 4":=20
>>
>> Well, I can give you what you want either with concepts or with a=20
>> suitably-enable_if-constrained alias template.=20
>> The wording "using the specialization is ill-formed" gives you SFINAE,=
=20
>> since I didn't add ", no diagnostic required".=20
>>
>
> Does this work?
>
> (int_t, uint_t)
> int_t<B> is an alias for intB_t if the implementation provides the type=
=20
> intB_t; otherwise, using the specialization int_t<B> is ill-formed.
>
I'm not sure it's meaningful to talk about "*using* such-and-such a=20
specialization" (types can't be odr-used, right?).
I also think you're *waaay* overthinking this. The correct legalese will be=
=20
drafted for you by LWG if it gets that far. Your goal should be to=20
communicate your intended semantics as *clearly* as possible. For example,=
=20
I would suggest merely:
The type int_t<B> is a synonym for intB_t if the implementation provides=20
the type intB_t; otherwise, the type does not exist.
int_least_t<B> is a synonym for int_leastN_t, where N is the smallest=20
integer greater than or equal to B such that the implementation provides=20
int_leastN_t; otherwise, the type does not exist.
I copied the wording "is a synonym for" from the definition of=20
std::nullptr_t in 18.2.2 [support.types.nullptr] /1.
I would leave out all mention of "ill-formed" and as much as possible about=
=20
the range of B; for example, I see no reason intleast_t<0> shouldn't be=20
int8_t.
You can implement a type's "not existing" (in a SFINAE-friendly way) via
template<int i> struct _int;
template<> struct _int<8> { using type =3D int8_t; };
template<> struct _int<16> { using type =3D int16_t; };
template<> struct _int<32> { using type =3D int32_t; };
template<int i> using int_t =3D typename _int<i>::type;
int_t<7> expands to _int<7>::type, which requires the implicit=20
instantiation of _int<7>, which yields an incomplete class type; and then=
=20
looking up the 'type' member of that incomplete class type fails. Which is=
=20
certainly SFINAE-friendly (SFINAE itself being explained obliquely in N4606=
=20
section 14.8.2 [temp.deduct] /8, if I understand correctly).
Does this need a "Note:" to make explicit the intent that the ill-formed=20
> cases are meant to cause substitution failure for SFINAE, rather than=20
> "hard" errors?
>
Historically, no, the Standard tends not to mention when SFINAE is the=20
reason for things.
HTH,
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/934aea9d-02ab-406c-99d8-3aa54908470d%40isocpp.or=
g.
------=_Part_1840_1446919085.1473203805147
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, September 6, 2016 at 2:25:44 PM UTC-7, Myriach=
an 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">On T=
uesday, September 6, 2016 at 1:51:52 PM UTC-7, Ville Voutilainen wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">On 6 September 2016 at 23:42, Myriachan=
<<a rel=3D"nofollow">myri...@gmail.com</a>> wrote:
<br>> I mean substitution failure for SFINAE along these lines, where th=
e output
<br>> is "1 2 99 4":
<br>
<br>Well, I can give you what you want either with concepts or with a
<br>suitably-enable_if-constrained alias template.
<br>The wording "using the specialization is ill-formed" gives yo=
u SFINAE,
<br>since I didn't add ", no diagnostic required".
<br></blockquote><div><br>Does this work?<br><br>(int_t, uint_t)<br>int_t&l=
t;B> is an alias for intB_t if the implementation provides the type intB=
_t; otherwise, using the specialization int_t<B> is ill-formed.<br></=
div></div></blockquote><div><br></div><div>I'm not sure it's meanin=
gful to talk about "<i>using</i> such-and-such a specialization" =
(types can't be odr-used, right?).</div><div>I also think you're <i=
>waaay</i> overthinking this. The correct legalese will be drafted for you =
by LWG if it gets that far. Your goal should be to communicate your intende=
d semantics as <i>clearly</i> as possible. =C2=A0For example, I would sugge=
st merely:</div><div><br></div><div>The type int_t<B> is a synonym fo=
r intB_t if the implementation provides the type intB_t; otherwise, the typ=
e does not exist.</div><div>int_least_t<B> is a synonym for int_least=
N_t, where N is the smallest integer greater than or equal to B such that t=
he implementation provides int_leastN_t; otherwise, the type does not exist=
..</div><div><br></div><div>I copied the wording "is a synonym for"=
; from the definition of std::nullptr_t in 18.2.2 [support.types.nullptr] /=
1.</div><div><br></div><div>I would leave out all mention of "ill-form=
ed" and as much as possible about the range of B; for example, I see n=
o reason intleast_t<0> shouldn't be int8_t.</div><div><br></div><=
div>You can implement a type's "not existing" (in a SFINAE-fr=
iendly way) via</div><div><br></div><div>=C2=A0 =C2=A0 template<int i>=
; struct _int;</div><div>=C2=A0 =C2=A0 template<> struct _int<8>=
; { using type =3D int8_t; };</div><div>=C2=A0 =C2=A0 template<> stru=
ct _int<16> { using type =3D int16_t; };</div><div>=C2=A0 =C2=A0 temp=
late<> struct _int<32> { using type =3D int32_t; };</div><div>=
=C2=A0 =C2=A0 template<int i> using int_t =3D typename _int<i>:=
:type;<br></div><div><br></div><div>int_t<7> expands to _int<7>=
::type, which requires the implicit instantiation of _int<7>, which y=
ields an incomplete class type; and then looking up the 'type' memb=
er of that incomplete class type fails. Which is certainly SFINAE-friendly =
(SFINAE itself being explained obliquely in N4606 section 14.8.2 [temp.dedu=
ct] /8, if I understand correctly).</div><div><br></div><div><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Does this ne=
ed a "Note:" to make explicit the intent that the ill-formed case=
s are meant to cause substitution failure for SFINAE, rather than "har=
d" errors?<br></div></div></blockquote><div><br></div><div>Historicall=
y, no, the Standard tends not to mention when SFINAE is the reason for thin=
gs.</div><div><br></div><div>HTH,</div><div>=E2=80=93Arthur</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/934aea9d-02ab-406c-99d8-3aa54908470d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/934aea9d-02ab-406c-99d8-3aa54908470d=
%40isocpp.org</a>.<br />
------=_Part_1840_1446919085.1473203805147--
------=_Part_1839_27450633.1473203805134--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 7 Sep 2016 02:29:41 +0300
Raw View
On 7 September 2016 at 02:16, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:
> I'm not sure it's meaningful to talk about "using such-and-such a
> specialization" (types can't be odr-used, right?).
I wasn't talking about odr-use. We could of course steal wording from
the spec of deleted function definitions,
which says
"A program that refers to a deleted function implicitly or explicitly,
other than to declare it, is ill-formed."
The "use" example is about main, which says
"The function main shall not be used within a program."
It's certainly meaningful to talk about using the specialization, and
it's not all that hard to interpret it
as meaning mentioning the type, because that's what it means for main;
you can't decltype it or do anything
with it, it can't be used, and that's not limited to the narrow world
of odr-use.
> You can implement a type's "not existing" (in a SFINAE-friendly way) via
> template<int i> struct _int;
> template<> struct _int<8> { using type = int8_t; };
> template<> struct _int<16> { using type = int16_t; };
> template<> struct _int<32> { using type = int32_t; };
> template<int i> using int_t = typename _int<i>::type;
> int_t<7> expands to _int<7>::type, which requires the implicit instantiation
> of _int<7>, which yields an incomplete class type; and then looking up the
> 'type' member of that incomplete class type fails. Which is certainly
> SFINAE-friendly (SFINAE itself being explained obliquely in N4606 section
> 14.8.2 [temp.deduct] /8, if I understand correctly).
Well, that part of the idea works, but an implementation of this idea
needs to disable
_int<8> if int8_t isn't provided, so an explicit specialization won't cut it.
>> Does this need a "Note:" to make explicit the intent that the ill-formed
>> cases are meant to cause substitution failure for SFINAE, rather than "hard"
>> errors?
> Historically, no, the Standard tends not to mention when SFINAE is the
> reason for things.
You might want to entertain the idea of adding a note that says that
the unwanted type is
ill-formed in the immediate context. Vague wording on that part will
open the possibility that
implementations will mistakenly static_assert inside a class template
definition, which does not do what
you want.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYN-fQ1AtR%3DauT-kKJCrb%3D6PXP4ghCZnfnC3iLdLGaA5Q%40mail.gmail.com.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Tue, 06 Sep 2016 19:44:43 -0400
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">And to be clear about your intent, just use the words 'sfinae f=
riendly' in the non-wording section, and LWG will know what to do. </d=
iv> =
<div style=3D"=
width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-se=
rif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-c=
olor: rgb(255, 255, 255);"><br style=3D"display:initial"></div> =
=
=
<div style=3D"font-size: initial; font-fam=
ily: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125);=
text-align: initial; background-color: rgb(255, 255, 255);">Sent from=
my BlackBerry portable Babbage Device</div> =
=
=
<table width=3D"100%" style=3D"background-color:white=
;border-spacing:0px;"> <tbody><tr><td colspan=3D"2" style=3D"font-size: ini=
tial; text-align: initial; background-color: rgb(255, 255, 255);"> =
<div style=3D"border-style: solid none none; border-top-c=
olor: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in; font=
-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;"> <div><b>=
From: </b>Arthur O'Dwyer</div><div><b>Sent: </b>Tuesday, September 6, 2016 =
7:16 PM</div><div><b>To: </b>ISO C++ Standard - Future Proposals</div><div>=
<b>Reply To: </b>std-proposals@isocpp.org</div><div><b>Subject: </b>Re: [st=
d-proposals] What header should int_t go to?</div></div></td></tr></tbody><=
/table><div style=3D"border-style: solid none none; border-top-color: rgb(1=
86, 188, 209); border-top-width: 1pt; font-size: initial; text-align: initi=
al; background-color: rgb(255, 255, 255);"></div><br><div id=3D"_originalCo=
ntent" style=3D""><div dir=3D"ltr">On Tuesday, September 6, 2016 at 2:25:44=
PM UTC-7, Myriachan wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">On Tuesday, September 6, 2016 at 1:51:52 PM UTC-7, Ville Vout=
ilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 6 September 2016 a=
t 23:42, Myriachan <<a rel=3D"nofollow">myri...@gmail.com</a>> wrote:
<br>> I mean substitution failure for SFINAE along these lines, where th=
e output
<br>> is "1 2 99 4":
<br>
<br>Well, I can give you what you want either with concepts or with a
<br>suitably-enable_if-constrained alias template.
<br>The wording "using the specialization is ill-formed" gives you SFINAE,
<br>since I didn't add ", no diagnostic required".
<br></blockquote><div><br>Does this work?<br><br>(int_t, uint_t)<br>int_t&l=
t;B> is an alias for intB_t if the implementation provides the type intB=
_t; otherwise, using the specialization int_t<B> is ill-formed.<br></=
div></div></blockquote><div><br></div><div>I'm not sure it's meaningful to =
talk about "<i>using</i> such-and-such a specialization" (types can't be od=
r-used, right?).</div><div>I also think you're <i>waaay</i> overthinking th=
is. The correct legalese will be drafted for you by LWG if it gets that far=
.. Your goal should be to communicate your intended semantics as <i>clearly<=
/i> as possible. For example, I would suggest merely:</div><div><br><=
/div><div>The type int_t<B> is a synonym for intB_t if the implementa=
tion provides the type intB_t; otherwise, the type does not exist.</div><di=
v>int_least_t<B> is a synonym for int_leastN_t, where N is the smalle=
st integer greater than or equal to B such that the implementation provides=
int_leastN_t; otherwise, the type does not exist.</div><div><br></div><div=
>I copied the wording "is a synonym for" from the definition of std::nullpt=
r_t in 18.2.2 [support.types.nullptr] /1.</div><div><br></div><div>I would =
leave out all mention of "ill-formed" and as much as possible about the ran=
ge of B; for example, I see no reason intleast_t<0> shouldn't be int8=
_t.</div><div><br></div><div>You can implement a type's "not existing" (in =
a SFINAE-friendly way) via</div><div><br></div><div> template&=
lt;int i> struct _int;</div><div> template<> struct _=
int<8> { using type =3D int8_t; };</div><div> template&l=
t;> struct _int<16> { using type =3D int16_t; };</div><div> =
template<> struct _int<32> { using type =3D int32_t; };<=
/div><div> template<int i> using int_t =3D typename _int=
<i>::type;<br></div><div><br></div><div>int_t<7> expands to _in=
t<7>::type, which requires the implicit instantiation of _int<7>=
;, which yields an incomplete class type; and then looking up the 'type' me=
mber of that incomplete class type fails. Which is certainly SFINAE-friendl=
y (SFINAE itself being explained obliquely in N4606 section 14.8.2 [temp.de=
duct] /8, if I understand correctly).</div><div><br></div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Does this =
need a "Note:" to make explicit the intent that the ill-formed cases are me=
ant to cause substitution failure for SFINAE, rather than "hard" errors?<br=
></div></div></blockquote><div><br></div><div>Historically, no, the Standar=
d tends not to mention when SFINAE is the reason for things.</div><div><br>=
</div><div>HTH,</div><div>=E2=80=93Arthur</div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/934aea9d-02ab-406c-99d8-3aa54908470d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/934aea9d-02ab-406c-99d8-3aa54908=
470d%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20160906234443.4890705.65115.16638%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20160906234443.4890705.65115.16638%40gm=
ail.com</a>.<br />
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 6 Sep 2016 18:45:42 -0700
Raw View
--001a1146cf463b773e053be11251
Content-Type: text/plain; charset=UTF-8
On Tue, Sep 6, 2016 at 2:25 PM, Myriachan <myriachan@gmail.com> wrote:
> On Tuesday, September 6, 2016 at 1:51:52 PM UTC-7, Ville Voutilainen wrote:
>>
>> On 6 September 2016 at 23:42, Myriachan <myri...@gmail.com> wrote:
>> > I mean substitution failure for SFINAE along these lines, where the
>> output
>> > is "1 2 99 4":
>>
>>
>> Well, I can give you what you want either with concepts or with a
>> suitably-enable_if-constrained alias template.
>> The wording "using the specialization is ill-formed" gives you SFINAE,
>> since I didn't add ", no diagnostic required".
>>
>
> Does this work?
>
> (int_t, uint_t)
> int_t<B> is an alias for intB_t if the implementation provides the type
> intB_t; otherwise, using the specialization int_t<B> is ill-formed.
>
I think this is overly restrictive; if an implementation can provide
int_t<N> for other values of N, I don't see why that should be disallowed.
(int_least_t, uint_least_t, int_fast_t, uint_fast_t)
> int_least_t<B> is an alias for int_leastN_t, where N is the smallest
> integer greater than or equal to B such that the implementation provides
> int_leastN_t. If B is less than 1, or if B is greater than the largest
> such integer N, using the specialization int_least_t<B> is ill-formed.
>
> Would Standardese repeat those lines for all four variants, or somehow
> reword it to apply to all four?
>
> Does this need a "Note:" to make explicit the intent that the ill-formed
> cases are meant to cause substitution failure for SFINAE, rather than
> "hard" errors?
>
> Melissa
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/2323f8aa-64f4-4115-
> 8054-3e9937932916%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2323f8aa-64f4-4115-8054-3e9937932916%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnSNEjDhXw7jcduNMEWzU5maJk8%2BK__XbD6qPy494ZgMg%40mail.gmail.com.
--001a1146cf463b773e053be11251
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Sep 6, 2016 at 2:25 PM, Myriachan <span dir=3D"ltr"><<a href=3D"mail=
to:myriachan@gmail.com" target=3D"_blank">myriachan@gmail.com</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, Sep=
tember 6, 2016 at 1:51:52 PM UTC-7, Ville Voutilainen wrote:<span class=3D"=
"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">On 6 September 2016 at 23:42, Myr=
iachan <<a rel=3D"nofollow">myri...@gmail.com</a>> wrote:
<br>> I mean substitution failure for SFINAE along these lines, where th=
e output
<br>> is "1 2 99 4":
<br>
<br>
<br>Well, I can give you what you want either with concepts or with a
<br>suitably-enable_if-constrained alias template.
<br>The wording "using the specialization is ill-formed" gives yo=
u SFINAE,
<br>since I didn't add ", no diagnostic required".
<br></blockquote></span><div><br>Does this work?<br><br>(int_t, uint_t)<br>=
int_t<B> is an alias for intB_t if the implementation provides the ty=
pe intB_t; otherwise, using the specialization int_t<B> is ill-formed=
..<br></div></div></blockquote><div><br></div><div>I think this is overly re=
strictive; if an implementation can provide int_t<N> for other values=
of N, I don't see why that should be disallowed.</div><div><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>(int_least_t, uint_leas=
t_t, int_fast_t, uint_fast_t)<br>int_least_t<B> is an alias for int_l=
eastN_t, where N is the smallest integer greater than or equal to B such th=
at the implementation provides int_leastN_t.=C2=A0 If B is less than 1, or =
if B is greater than the largest such integer N, using the specialization i=
nt_least_t<B> is ill-formed.<br><br>Would Standardese repeat those li=
nes for all four variants, or somehow reword it to apply to all four?<br><b=
r>Does this need a "Note:" to make explicit the intent that the i=
ll-formed cases are meant to cause substitution failure for SFINAE, rather =
than "hard" errors?<br><br>Melissa<br></div></div><span class=3D"=
">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2323f8aa-64f4-4115-8054-3e9937932916%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/2323=
f8aa-64f4-4115-<wbr>8054-3e9937932916%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnSNEjDhXw7jcduNMEWzU5maJk8%2BK=
__XbD6qPy494ZgMg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnSNEjDhX=
w7jcduNMEWzU5maJk8%2BK__XbD6qPy494ZgMg%40mail.gmail.com</a>.<br />
--001a1146cf463b773e053be11251--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Tue, 6 Sep 2016 21:56:53 -0400
Raw View
--001a114476f240c6a7053be13ae7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
As far as the original question went, my spontaneous answer was =C2=ABwell,
let's have a <stdint> (probably bikeshed) counterpart to <cstdint>, just
like we have a <limits> counterpart to <climits> where we provide templated
services akin to the C macros=C2=BB.
I started writing this and stopped. Would it be too small a header? Could
it be a nice destination for an eventual bigint (name to be defined; there
are proposals but I'm not totally up to date here) type? It seemed natural
to me, but I'm not sure I've thought this through.
So there: it's out in the open, and let's kill it if it doesn't make sense
:)
2016-09-06 21:45 GMT-04:00 Richard Smith <richard@metafoo.co.uk>:
> On Tue, Sep 6, 2016 at 2:25 PM, Myriachan <myriachan@gmail.com> wrote:
>
>> On Tuesday, September 6, 2016 at 1:51:52 PM UTC-7, Ville Voutilainen
>> wrote:
>>>
>>> On 6 September 2016 at 23:42, Myriachan <myri...@gmail.com> wrote:
>>> > I mean substitution failure for SFINAE along these lines, where the
>>> output
>>> > is "1 2 99 4":
>>>
>>>
>>> Well, I can give you what you want either with concepts or with a
>>> suitably-enable_if-constrained alias template.
>>> The wording "using the specialization is ill-formed" gives you SFINAE,
>>> since I didn't add ", no diagnostic required".
>>>
>>
>> Does this work?
>>
>> (int_t, uint_t)
>> int_t<B> is an alias for intB_t if the implementation provides the type
>> intB_t; otherwise, using the specialization int_t<B> is ill-formed.
>>
>
> I think this is overly restrictive; if an implementation can provide
> int_t<N> for other values of N, I don't see why that should be disallowed=
..
>
> (int_least_t, uint_least_t, int_fast_t, uint_fast_t)
>> int_least_t<B> is an alias for int_leastN_t, where N is the smallest
>> integer greater than or equal to B such that the implementation provides
>> int_leastN_t. If B is less than 1, or if B is greater than the largest
>> such integer N, using the specialization int_least_t<B> is ill-formed.
>>
>> Would Standardese repeat those lines for all four variants, or somehow
>> reword it to apply to all four?
>>
>> Does this need a "Note:" to make explicit the intent that the ill-formed
>> cases are meant to cause substitution failure for SFINAE, rather than
>> "hard" errors?
>>
>> Melissa
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/2323f8aa-64f4-4115-8054-
>> 3e9937932916%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2323f8aa-6=
4f4-4115-8054-3e9937932916%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAOfiQqnSNEjDhXw7jcduNMEWzU5ma
> Jk8%2BK__XbD6qPy494ZgMg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnSNE=
jDhXw7jcduNMEWzU5maJk8%2BK__XbD6qPy494ZgMg%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAKiZDp31yNhmXQ8aR%2B381yp3FtJaisWR22R%2BrZNkoxm=
abxLffw%40mail.gmail.com.
--001a114476f240c6a7053be13ae7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">As far as the original question went, my spontaneous answe=
r was =C2=ABwell, let's have a <stdint> (probably bikeshed) count=
erpart to <cstdint>, just like we have a <limits> counterpart t=
o <climits> where we provide templated services akin to the C macros=
=C2=BB.<br><br>I started writing this and stopped. Would it be too small a =
header? Could it be a nice destination for an eventual bigint (name to be d=
efined; there are proposals but I'm not totally up to date here) type? =
It seemed natural to me, but I'm not sure I've thought this through=
..<br><br>So there: it's out in the open, and let's kill it if it do=
esn't make sense :)<br></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">2016-09-06 21:45 GMT-04:00 Richard Smith <span dir=3D"ltr"=
><<a href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@met=
afoo.co.uk</a>></span>:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">O=
n Tue, Sep 6, 2016 at 2:25 PM, Myriachan <span dir=3D"ltr"><<a href=3D"m=
ailto:myriachan@gmail.com" target=3D"_blank">myriachan@gmail.com</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, =
September 6, 2016 at 1:51:52 PM UTC-7, Ville Voutilainen wrote:<span><block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex">On 6 September 2016 at 23:42, Myriachan &=
lt;<a rel=3D"nofollow">myri...@gmail.com</a>> wrote:
<br>> I mean substitution failure for SFINAE along these lines, where th=
e output
<br>> is "1 2 99 4":
<br>
<br>
<br>Well, I can give you what you want either with concepts or with a
<br>suitably-enable_if-constrained alias template.
<br>The wording "using the specialization is ill-formed" gives yo=
u SFINAE,
<br>since I didn't add ", no diagnostic required".
<br></blockquote></span><div><br>Does this work?<br><br>(int_t, uint_t)<br>=
int_t<B> is an alias for intB_t if the implementation provides the ty=
pe intB_t; otherwise, using the specialization int_t<B> is ill-formed=
..<br></div></div></blockquote><div><br></div></span><div>I think this is ov=
erly restrictive; if an implementation can provide int_t<N> for other=
values of N, I don't see why that should be disallowed.</div><span cla=
ss=3D""><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
>(int_least_t, uint_least_t, int_fast_t, uint_fast_t)<br>int_least_t<B&g=
t; is an alias for int_leastN_t, where N is the smallest integer greater th=
an or equal to B such that the implementation provides int_leastN_t.=C2=A0 =
If B is less than 1, or if B is greater than the largest such integer N, us=
ing the specialization int_least_t<B> is ill-formed.<br><br>Would Sta=
ndardese repeat those lines for all four variants, or somehow reword it to =
apply to all four?<br><br>Does this need a "Note:" to make explic=
it the intent that the ill-formed cases are meant to cause substitution fai=
lure for SFINAE, rather than "hard" errors?<br><br>Melissa<br></d=
iv></div><span>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2323f8aa-64f4-4115-8054-3e9937932916%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/2323=
f8aa-64f4-4115-8054-<wbr>3e9937932916%40isocpp.org</a>.<br>
</blockquote></span></div><br></div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnSNEjDhXw7jcduNMEWzU5maJk8%2BK=
__XbD6qPy494ZgMg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/<wbr>CAOfiQqnSNEjDhXw7jcduNMEWzU5ma<wbr>Jk8%2BK__XbD6qPy49=
4ZgMg%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp31yNhmXQ8aR%2B381yp3FtJaisWR22=
R%2BrZNkoxmabxLffw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp31yNhm=
XQ8aR%2B381yp3FtJaisWR22R%2BrZNkoxmabxLffw%40mail.gmail.com</a>.<br />
--001a114476f240c6a7053be13ae7--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Tue, 06 Sep 2016 23:31:08 -0400
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">I have no problems with small headers. YMMV. </div><div st=
yle=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', =
sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backg=
round-color: rgb(255, 255, 255);"><br></div><div style=3D"width: 100%; font=
-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; =
color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 25=
5, 255);">I think BigInt will be expensive relative to int_t<>, so I'=
d prefer it to be in a separate header.</div><div style=3D"width: 100%; fon=
t-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif;=
color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 2=
55, 255);"><br></div><div style=3D"width: 100%; font-size: initial; font-fa=
mily: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125)=
; text-align: initial; background-color: rgb(255, 255, 255);">Although mayb=
e when modules show up gaging 'expensive' and headers etc might all change?=
</div><div style=3D"width: 100%; font-size: initial; font-family: Calibri, =
'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: i=
nitial; background-color: rgb(255, 255, 255);"><br></div> =
=
<div style=3D"width: 100%; font-siz=
e: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; colo=
r: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 2=
55);"><br style=3D"display:initial"></div> =
=
=
<div style=3D"font-size: initial; font-family: Calibri, 'Slate =
Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial;=
background-color: rgb(255, 255, 255);">Sent from my BlackBe=
rry portable Babbage Device</div> =
=
=
<table width=3D"100%" style=3D"background-color:white;border-spacing:0px;"=
> <tbody><tr><td colspan=3D"2" style=3D"font-size: initial; text-align: ini=
tial; background-color: rgb(255, 255, 255);"> <di=
v style=3D"border-style: solid none none; border-top-color: rgb(181, 196, 2=
23); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB =
Alpha Sans', 'Slate Pro'; font-size: 10pt;"> <div><b>From: </b>Patrice Roy=
</div><div><b>Sent: </b>Tuesday, September 6, 2016 9:56 PM</div><div><b>To:=
</b>std-proposals@isocpp.org</div><div><b>Reply To: </b>std-proposals@isoc=
pp.org</div><div><b>Subject: </b>Re: [std-proposals] What header should int=
_t go to?</div></div></td></tr></tbody></table><div style=3D"border-style: =
solid none none; border-top-color: rgb(186, 188, 209); border-top-width: 1p=
t; font-size: initial; text-align: initial; background-color: rgb(255, 255,=
255);"></div><br><div id=3D"_originalContent" style=3D""><div dir=3D"ltr">=
As far as the original question went, my spontaneous answer was =C2=ABwell,=
let's have a <stdint> (probably bikeshed) counterpart to <cstdint=
>, just like we have a <limits> counterpart to <climits> whe=
re we provide templated services akin to the C macros=C2=BB.<br><br>I start=
ed writing this and stopped. Would it be too small a header? Could it be a =
nice destination for an eventual bigint (name to be defined; there are prop=
osals but I'm not totally up to date here) type? It seemed natural to me, b=
ut I'm not sure I've thought this through.<br><br>So there: it's out in the=
open, and let's kill it if it doesn't make sense :)<br></div><div class=3D=
"gmail_extra"><br><div class=3D"gmail_quote">2016-09-06 21:45 GMT-04:00 Ric=
hard Smith <span dir=3D"ltr"><<a href=3D"mailto:richard@metafoo.co.uk" t=
arget=3D"_blank">richard@metafoo.co.uk</a>></span>:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><span class=3D"">On Tue, Sep 6, 2016 at 2:25 PM, Myriachan <span =
dir=3D"ltr"><<a href=3D"mailto:myriachan@gmail.com" target=3D"_blank">my=
riachan@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr">On Tuesday, September 6, 2016 at 1:51:52 PM UTC-7, Ville Vo=
utilainen wrote:<span><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 6 Septembe=
r 2016 at 23:42, Myriachan <<a rel=3D"nofollow">myri...@gmail.com</a>>=
; wrote:
<br>> I mean substitution failure for SFINAE along these lines, where th=
e output
<br>> is "1 2 99 4":
<br>
<br>
<br>Well, I can give you what you want either with concepts or with a
<br>suitably-enable_if-constrained alias template.
<br>The wording "using the specialization is ill-formed" gives you SFINAE,
<br>since I didn't add ", no diagnostic required".
<br></blockquote></span><div><br>Does this work?<br><br>(int_t, uint_t)<br>=
int_t<B> is an alias for intB_t if the implementation provides the ty=
pe intB_t; otherwise, using the specialization int_t<B> is ill-formed=
..<br></div></div></blockquote><div><br></div></span><div>I think this is ov=
erly restrictive; if an implementation can provide int_t<N> for other=
values of N, I don't see why that should be disallowed.</div><span class=
=3D""><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>(=
int_least_t, uint_least_t, int_fast_t, uint_fast_t)<br>int_least_t<B>=
is an alias for int_leastN_t, where N is the smallest integer greater than=
or equal to B such that the implementation provides int_leastN_t. If=
B is less than 1, or if B is greater than the largest such integer N, usin=
g the specialization int_least_t<B> is ill-formed.<br><br>Would Stand=
ardese repeat those lines for all four variants, or somehow reword it to ap=
ply to all four?<br><br>Does this need a "Note:" to make explicit the inten=
t that the ill-formed cases are meant to cause substitution failure for SFI=
NAE, rather than "hard" errors?<br><br>Melissa<br></div></div><span>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2323f8aa-64f4-4115-8054-3e9937932916%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/2323=
f8aa-64f4-4115-8054-<wbr>3e9937932916%40isocpp.org</a>.<br>
</blockquote></span></div><br></div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnSNEjDhXw7jcduNMEWzU5maJk8%2BK=
__XbD6qPy494ZgMg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/<wbr>CAOfiQqnSNEjDhXw7jcduNMEWzU5ma<wbr>Jk8%2BK__XbD6qPy49=
4ZgMg%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp31yNhmXQ8aR%2B381yp3FtJaisWR22=
R%2BrZNkoxmabxLffw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp31=
yNhmXQ8aR%2B381yp3FtJaisWR22R%2BrZNkoxmabxLffw%40mail.gmail.com</a>.<br>
<br><!--end of _originalContent --></div></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20160907033108.4890705.64740.16645%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20160907033108.4890705.64740.16645%40gm=
ail.com</a>.<br />
.
Author: Myriachan <myriachan@gmail.com>
Date: Wed, 7 Sep 2016 13:41:37 -0700 (PDT)
Raw View
------=_Part_10775_1945868849.1473280897286
Content-Type: multipart/alternative;
boundary="----=_Part_10776_1531733932.1473280897287"
------=_Part_10776_1531733932.1473280897287
Content-Type: text/plain; charset=UTF-8
On Tuesday, September 6, 2016 at 6:45:44 PM UTC-7, Richard Smith wrote:
>
>
> I think this is overly restrictive; if an implementation can provide
> int_t<N> for other values of N, I don't see why that should be disallowed.
>
>
Yeah, you're right. I would say that whatever types exist in cstdint ought
to exist in the templates, though. (C++ doesn't state that an
implementation can have these types in <cstdint> for numbers except 8, 16,
32 and 64, but C does state this. I think that this should be corrected,
with an implementation being allowed to define a std::int28_t.)
I did come up with another issue, though. This rule is in [temp.res]/8:
"If no valid specialization can be generated for a template, and that
template is not instantiated, the template is ill-formed, no diagnostic
required."
int_t<B> as I wanted to define it would potentially violate this rule. If
an implementation has no types that meet the requirements of int_t<B> for
any B, then an implementation would need an int_t somewhat like this:
template <int B> struct _undefined_struct;
template <int B> using int_t = typename _undefined_struct<B>::_type;
But then no valid template instantiation would exist, violating the rule,
even though it's actually a desirable outcome here (SFINAE could detect
that int_t<B> doesn't exist for some B).
Melissa
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cf1ed39f-e636-42ad-835b-9c6fd17112fe%40isocpp.org.
------=_Part_10776_1531733932.1473280897287
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, September 6, 2016 at 6:45:44 PM UTC-7, Richard=
Smith wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote"><br><div>I think this is overly restrictive=
; if an implementation can provide int_t<N> for other values of N, I =
don't see why that should be disallowed.</div><br></div></div></div></b=
lockquote><div><br>Yeah, you're right.=C2=A0 I would say that whatever =
types exist in cstdint ought to exist in the templates, though.=C2=A0 (C++ =
doesn't state that an implementation can have these types in <cstdin=
t> for numbers except 8, 16, 32 and 64, but C does state this.=C2=A0 I t=
hink that this should be corrected, with an implementation being allowed to=
define a std::int28_t.)<br><br>I did come up with another issue, though.=
=C2=A0 This rule is in [temp.res]/8:<br><br>"If no valid specializatio=
n can be generated for a template, and that template is not instantiated, t=
he template is ill-formed, no diagnostic required."<br><br>int_t<B&=
gt; as I wanted to define it would potentially violate this rule.=C2=A0 If =
an implementation has no types that meet the requirements of int_t<B>=
for any B, then an implementation would need an int_t somewhat like this:<=
br><br>=C2=A0=C2=A0=C2=A0 template <int B> struct _undefined_struct;<=
br>=C2=A0=C2=A0=C2=A0 template <int B> using int_t =3D typename _unde=
fined_struct<B>::_type;<br><br>But then no valid template instantiati=
on would exist, violating the rule, even though it's actually a desirab=
le outcome here (SFINAE could detect that int_t<B> doesn't exist =
for some B).<br><br>Melissa<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cf1ed39f-e636-42ad-835b-9c6fd17112fe%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cf1ed39f-e636-42ad-835b-9c6fd17112fe=
%40isocpp.org</a>.<br />
------=_Part_10776_1531733932.1473280897287--
------=_Part_10775_1945868849.1473280897286--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 7 Sep 2016 14:56:57 -0700
Raw View
--001a113fdc42fda003053bf1fd1d
Content-Type: text/plain; charset=UTF-8
On Wed, Sep 7, 2016 at 1:41 PM, Myriachan <myriachan@gmail.com> wrote:
> On Tuesday, September 6, 2016 at 6:45:44 PM UTC-7, Richard Smith wrote:
>>
>>
>> I think this is overly restrictive; if an implementation can provide
>> int_t<N> for other values of N, I don't see why that should be disallowed.
>>
>>
> Yeah, you're right. I would say that whatever types exist in cstdint
> ought to exist in the templates, though. (C++ doesn't state that an
> implementation can have these types in <cstdint> for numbers except 8, 16,
> 32 and 64, but C does state this. I think that this should be corrected,
> with an implementation being allowed to define a std::int28_t.)
>
Yes, Thomas and I noticed that when working on p0175r1. It seemed odd to us
too, and probably a defect. It was also not completely clear whether the
_MIN/_MAX macros were supposed to be optional in C++. I don't know of a
reason for C++ to diverge from C here.
I think we can go further than <cstdint> does: we could require that
int_t<B> works at least for every B where the implementation provides at
least one (standard or extended) signed integer type that is 2's complement
and B bits wide. (I'm somewhat on the fence on C's "no padding bits"
requirement, but perhaps we should include that too for consistency.)
<cstdint> only requires this for the cases where B is 8, 16, 32, or 64, and
in other cases the implementation is permitted but not required to provide
the type.
I did come up with another issue, though. This rule is in [temp.res]/8:
>
> "If no valid specialization can be generated for a template, and that
> template is not instantiated, the template is ill-formed, no diagnostic
> required."
>
> int_t<B> as I wanted to define it would potentially violate this rule. If
> an implementation has no types that meet the requirements of int_t<B> for
> any B, then an implementation would need an int_t somewhat like this:
>
> template <int B> struct _undefined_struct;
> template <int B> using int_t = typename _undefined_struct<B>::_type;
>
> But then no valid template instantiation would exist, violating the rule,
> even though it's actually a desirable outcome here (SFINAE could detect
> that int_t<B> doesn't exist for some B).
>
Someone should write a paper proposing that we drop support for
non-2s'-complement integer representations...
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DqRi1MHmx8GNr%2BKwSnLYac92yr9-iwSdCvxOz5JPit_w%40mail.gmail.com.
--001a113fdc42fda003053bf1fd1d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Sep 7, 2016 at 1:41 PM, Myriachan <span dir=3D"ltr"><<a href=3D"mail=
to:myriachan@gmail.com" target=3D"_blank">myriachan@gmail.com</a>></span=
> wrote:<br><blockquote class=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"l=
tr"><span class=3D"gmail-">On Tuesday, September 6, 2016 at 6:45:44 PM UTC-=
7, Richard Smith wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"ltr"><div><div class=3D"gmail_quote"><br><div>I think this is ove=
rly restrictive; if an implementation can provide int_t<N> for other =
values of N, I don't see why that should be disallowed.</div><br></div>=
</div></div></blockquote></span><div><br>Yeah, you're right.=C2=A0 I wo=
uld say that whatever types exist in cstdint ought to exist in the template=
s, though.=C2=A0 (C++ doesn't state that an implementation can have the=
se types in <cstdint> for numbers except 8, 16, 32 and 64, but C does=
state this.=C2=A0 I think that this should be corrected, with an implement=
ation being allowed to define a std::int28_t.)<br></div></div></blockquote>=
<div><br></div><div>Yes, Thomas and I noticed that when working on=C2=A0p01=
75r1. It seemed odd to us too, and probably a defect. It was also not compl=
etely clear whether the _MIN/_MAX macros were supposed to be optional in C+=
+. I don't know of a reason for C++ to diverge from C here.</div><div><=
br></div><div>I think we can go further than <cstdint> does: we could=
require that int_t<B> works at least for every B where the implement=
ation provides at least one (standard or extended) signed integer type that=
is 2's complement and B bits wide. (I'm somewhat on the fence on C=
's "no padding bits" requirement, but perhaps we should inclu=
de that too for consistency.) <cstdint> only requires this for the ca=
ses where B is 8, 16, 32, or 64, and in other cases the implementation is p=
ermitted but not required to provide the type.</div><div><br></div><blockqu=
ote class=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>I did come =
up with another issue, though.=C2=A0 This rule is in [temp.res]/8:<br><br>&=
quot;If no valid specialization can be generated for a template, and that t=
emplate is not instantiated, the template is ill-formed, no diagnostic requ=
ired."<br><br>int_t<B> as I wanted to define it would potentiall=
y violate this rule.=C2=A0 If an implementation has no types that meet the =
requirements of int_t<B> for any B, then an implementation would need=
an int_t somewhat like this:<br><br>=C2=A0=C2=A0=C2=A0 template <int B&=
gt; struct _undefined_struct;<br>=C2=A0=C2=A0=C2=A0 template <int B> =
using int_t =3D typename _undefined_struct<B>::_type;<br><br>But then=
no valid template instantiation would exist, violating the rule, even thou=
gh it's actually a desirable outcome here (SFINAE could detect that int=
_t<B> doesn't exist for some B).</div></div></blockquote><div><br=
></div><div>Someone should write a paper proposing that we drop support for=
non-2s'-complement integer representations...</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DqRi1MHmx8GNr%2BKwSnLYac92yr=
9-iwSdCvxOz5JPit_w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DqRi=
1MHmx8GNr%2BKwSnLYac92yr9-iwSdCvxOz5JPit_w%40mail.gmail.com</a>.<br />
--001a113fdc42fda003053bf1fd1d--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Thu, 8 Sep 2016 14:37:34 -0700
Raw View
--001a113ed97a88e62f053c05d61c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Sep 7, 2016 at 1:41 PM, Myriachan <myriachan@gmail.com> wrote:
> On Tuesday, September 6, 2016 at 6:45:44 PM UTC-7, Richard Smith wrote:
>>
>>
>> I think this is overly restrictive; if an implementation can provide
>> int_t<N> for other values of N, I don't see why that should be disallowe=
d.
>>
>
> Yeah, you're right. I would say that whatever types exist in cstdint
> ought to exist in the templates, though. (C++ doesn't state that an
> implementation can have these types in <cstdint> for numbers except 8, 16=
,
> 32 and 64, but C does state this. I think that this should be corrected,
> with an implementation being allowed to define a std::int28_t.)
>
Right. I think drawing an equivalence between intN_t and int_t<N> is
unobjectionable.
Any implementation that provides either int128_t or int_t<128> is already
dealing in vendor-specific extensions; it's totally fine for the standard
to require that any such extensions be internally consistent.
I did come up with another issue, though. This rule is in [temp.res]/8:
>
> "If no valid specialization can be generated for a template, and that
> template is not instantiated, the template is ill-formed, no diagnostic
> required."
>
> int_t<B> as I wanted to define it would potentially violate this rule. I=
f
> an implementation has no types that meet the requirements of int_t<B> for
> any B, then an implementation would need an int_t somewhat like this:
>
> template <int B> struct _undefined_struct;
> template <int B> using int_t =3D typename _undefined_struct<B>::_type=
;
>
The trick is, "somewhat" like this. Perhaps you're right that it couldn't
be *exactly* this; but in that case, it would be up to the implementation
to provide an int_t that worked. For example, on such a hypothetical
compiler, I'm pretty sure that this would work:
template <int B> struct _undefined_struct;
template<> struct _undefined_struct<-1>;
template <int B> using int_t =3D typename _undefined_struct<B>::_type;
Anyway, [temp.res]/8 has a bad habit of coming up as a stumbling block for
writing code that works on Sufficiently Smart Compilers (none of which
exist today); it probably needs some committee attention, but it shouldn't
get in the way of standardizing some random integer types. :P
HTH,
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0LyKr%2BoVsxQhOe%3D76XGk8%2Bai0F9U4Jd8GzVz=
N8X3k5m8w%40mail.gmail.com.
--001a113ed97a88e62f053c05d61c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Sep 7, 2016 at 1:41 PM, Myriachan <span dir=3D"ltr=
"><<a href=3D"mailto:myriachan@gmail.com" target=3D"_blank">myriachan@gm=
ail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, September 6, 2016=
at 6:45:44 PM UTC-7, Richard Smith wrote:<blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:=
rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote"><br><div>I think this is overly restrictiv=
e; if an implementation can provide int_t<N> for other values of N, I=
don't see why that should be disallowed.</div></div></div></div></bloc=
kquote><div><br>Yeah, you're right.=C2=A0 I would say that whatever typ=
es exist in cstdint ought to exist in the templates, though.=C2=A0 (C++ doe=
sn't state that an implementation can have these types in <cstdint&g=
t; for numbers except 8, 16, 32 and 64, but C does state this.=C2=A0 I thin=
k that this should be corrected, with an implementation being allowed to de=
fine a std::int28_t.)<br></div></div></blockquote><div><br></div><div>Right=
.. I think drawing an equivalence between intN_t and int_t<N> is unobj=
ectionable.</div><div>Any implementation that provides either int128_t or i=
nt_t<128> is already dealing in vendor-specific extensions; it's =
totally fine for the standard to require that any such extensions be intern=
ally consistent.</div><div><br></div><div><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div d=
ir=3D"ltr"><div>I did come up with another issue, though.=C2=A0 This rule i=
s in [temp.res]/8:<br><br>"If no valid specialization can be generated=
for a template, and that template is not instantiated, the template is ill=
-formed, no diagnostic required."<br><br>int_t<B> as I wanted to=
define it would potentially violate this rule.=C2=A0 If an implementation =
has no types that meet the requirements of int_t<B> for any B, then a=
n implementation would need an int_t somewhat like this:<br><br>=C2=A0=C2=
=A0=C2=A0 template <int B> struct _undefined_struct;<br>=C2=A0=C2=A0=
=C2=A0 template <int B> using int_t =3D typename _undefined_struct<=
;B>::_type;<br></div></div></blockquote><div><br></div><div>The trick is=
, "somewhat" like this. Perhaps you're right that it couldn&#=
39;t be *exactly* this; but in that case, it would be up to the implementat=
ion to provide an int_t that worked.=C2=A0 For example, on such a hypotheti=
cal compiler, I'm pretty sure that this would work:</div><div><br></div=
><div>=C2=A0 =C2=A0 template <int B> struct _undefined_struct;<br></d=
iv><div>=C2=A0 =C2=A0 template<> struct _undefined_struct<-1>;<=
/div><div>=C2=A0 =C2=A0 template <int B> using int_t =3D typename _un=
defined_struct<B>::_type;</div><div><br></div><div>Anyway, [temp.res]=
/8 has a bad habit of coming up as a stumbling block for writing code that =
works on Sufficiently Smart Compilers (none of which exist today); it proba=
bly needs some committee attention, but it shouldn't get in the way of =
standardizing some random integer types. :P</div><div><br></div><div>HTH,</=
div><div>=E2=80=93Arthur</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0LyKr%2BoVsxQhOe%3D76XGk8%2Bai0=
F9U4Jd8GzVzN8X3k5m8w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0LyKr=
%2BoVsxQhOe%3D76XGk8%2Bai0F9U4Jd8GzVzN8X3k5m8w%40mail.gmail.com</a>.<br />
--001a113ed97a88e62f053c05d61c--
.
Author: John McFarlane <mcfarlane.john@gmail.com>
Date: Thu, 22 Sep 2016 09:28:48 -0700 (PDT)
Raw View
------=_Part_1274_1428595992.1474561728354
Content-Type: multipart/alternative;
boundary="----=_Part_1275_438894037.1474561728354"
------=_Part_1275_438894037.1474561728354
Content-Type: text/plain; charset=UTF-8
Arthur just brought this proposal to my attention. I have submitted a
similar proposal:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0381r0.html
In it, the equivalent to *std::int_t<BITS>* would be *set_width_t<int,
BITS>*. This type could be user-specialized for non-built-in integral types.
Note that that name is certainly going to change (perhaps *make_int_t* or
*make_bitwidth_t*) and that I suggest *fast* and *least* variants.
On Tuesday, September 6, 2016 at 10:37:22 AM UTC-7, Myriachan wrote:
>
> I wanted to write a formal proposal for the std::int_t<BITS> idea that I
> (and others came up with before me), but I don't know a few things.
>
> For those who didn't see it before, std::int_t<BITS> and related templates
> (such as std::uint_fast_t<BITS>) are aliases for std::intBITS_t, so that
> metaprogramming can select an integer type from the bit count.
>
> First, which header should get this template? It most naturally fits in
> <cstdint>, but that breaks the paradigm of <cwhatever> only having what is
> in <whatever.h> from C. <cinttypes> similarly. <limits> would work, but
> seems awkward.
>
> Second, what is the formal wording for something like "the specialization
> shall not exist"? I would think something like "int_t<B> shall be an alias
> for intB_t, if it exists, or shall fail to substitute".
>
> Melissa
>
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5448fb43-50eb-4aac-9aff-1cd6d6ecf72d%40isocpp.org.
------=_Part_1275_438894037.1474561728354
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Arthur just brought this proposal to my attention. I have =
submitted a similar proposal:<br><br>http://www.open-std.org/jtc1/sc22/wg21=
/docs/papers/2016/p0381r0.html<br><br>In it, the equivalent to <i>std::int_=
t<BITS></i> would be <i>set_width_t<int, BITS></i>. This type c=
ould be user-specialized for non-built-in integral types.<br><br>Note that =
that name is certainly going to change (perhaps <i>make_int_t</i> or <i>mak=
e_bitwidth_t</i>) and that I suggest <i>fast</i> and <i>least</i> variants.=
<br><br>On Tuesday, September 6, 2016 at 10:37:22 AM UTC-7, Myriachan wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I wanted to =
write a formal proposal for the std::int_t<BITS> idea that I (and oth=
ers came up with before me), but I don't know a few things.<br><br>For =
those who didn't see it before, std::int_t<BITS> and related temp=
lates (such as std::uint_fast_t<BITS>) are aliases for std::intBITS_t=
, so that metaprogramming can select an integer type from the bit count.<br=
><br>First, which header should get this template?=C2=A0 It most naturally =
fits in <cstdint>, but that breaks the paradigm of <cwhatever> =
only having what is in <whatever.h> from C.=C2=A0 <cinttypes> s=
imilarly.=C2=A0 <limits> would work, but seems awkward.<br><br>Second=
, what is the formal wording for something like "the specialization sh=
all not exist"?=C2=A0 I would think something like "int_t<B>=
; shall be an alias for intB_t, if it exists, or shall fail to substitute&q=
uot;.<br><br>Melissa<br><br></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5448fb43-50eb-4aac-9aff-1cd6d6ecf72d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5448fb43-50eb-4aac-9aff-1cd6d6ecf72d=
%40isocpp.org</a>.<br />
------=_Part_1275_438894037.1474561728354--
------=_Part_1274_1428595992.1474561728354--
.
Author: "D. B." <db0451@gmail.com>
Date: Thu, 22 Sep 2016 19:43:43 +0100
Raw View
--089e013c646a8eaa5f053d1d0a8a
Content-Type: text/plain; charset=UTF-8
On Thu, Sep 22, 2016 at 5:28 PM, John McFarlane <mcfarlane.john@gmail.com>
wrote:
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0381r0.html>
>
> In it, the equivalent to *std::int_t<BITS>* would be *set_width_t<int,
> BITS>*. This type could be user-specialized for non-built-in integral
> types.
>
> Note that that name is certainly going to change (perhaps *make_int_t* or
> *make_bitwidth_t*) and that I suggest *fast* and *least* variants.
>
> --
>
make_ isn't any better though, is it? as a prefix for types, that too seems
both redunant (vs the _t suffix) and a recipe for confusion (wrt make_*()
functions)
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhE1np8gzhyE-%2B9kXLJdoRUE9Smo2Jh9CYq-KWyz9ZYTQA%40mail.gmail.com.
--089e013c646a8eaa5f053d1d0a8a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Sep 22, 2016 at 5:28 PM, John McFarlane <span dir=3D"ltr"><<a href=
=3D"mailto:mcfarlane.john@gmail.com" target=3D"_blank">mcfarlane.john@gmail=
..com</a>></span> wrote:<a href=3D"http://www.open-std.org/jtc1/sc22/wg21=
/docs/papers/2016/p0381r0.html" target=3D"_blank"></a><br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><br>In it, the equivalent to <i>std::int_t&l=
t;BITS></i> would be <i>set_width_t<int, BITS></i>. This type coul=
d be user-specialized for non-built-in integral types.<br><br>Note that tha=
t name is certainly going to change (perhaps <i>make_int_t</i> or <i>make_b=
itwidth_t</i>) and that I suggest <i>fast</i> and <i>least</i> variants.<sp=
an class=3D""></span><br><span class=3D""></span></div><span class=3D"">
<p></p>
-- </span><br></blockquote><div><br></div><div>make_ isn't any better t=
hough, is it? as a prefix for types, that too seems both redunant (vs the _=
t suffix) and a recipe for confusion (wrt make_*() functions)<br><br>=C2=A0=
<br></div></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhE1np8gzhyE-%2B9kXLJdoRUE9Smo2J=
h9CYq-KWyz9ZYTQA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhE1np8gzh=
yE-%2B9kXLJdoRUE9Smo2Jh9CYq-KWyz9ZYTQA%40mail.gmail.com</a>.<br />
--089e013c646a8eaa5f053d1d0a8a--
.
Author: John McFarlane <john@mcfarlane.name>
Date: Thu, 22 Sep 2016 19:23:51 -0700
Raw View
--001a1144b420169429053d237857
Content-Type: text/plain; charset=UTF-8
The appeal of `make_` is that there is already `make_signed` which is
closely related: it takes one type and changes a single attribute about it,
yielding another type.
The `_t` variants are a convenience types; they're another matter
altogether. For example, `make_signed_t<T>` which is shorthand for
`typename make_signed<T>::type`.
On Thu, Sep 22, 2016 at 11:43 AM, D. B. <db0451@gmail.com> wrote:
> On Thu, Sep 22, 2016 at 5:28 PM, John McFarlane <mcfarlane.john@gmail.com>
> wrote:
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0381r0.html>
>
>>
>> In it, the equivalent to *std::int_t<BITS>* would be *set_width_t<int,
>> BITS>*. This type could be user-specialized for non-built-in integral
>> types.
>>
>> Note that that name is certainly going to change (perhaps *make_int_t*
>> or *make_bitwidth_t*) and that I suggest *fast* and *least* variants.
>>
>> --
>>
>
> make_ isn't any better though, is it? as a prefix for types, that too
> seems both redunant (vs the _t suffix) and a recipe for confusion (wrt
> make_*() functions)
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CACGiwhE1np8gzhyE-%
> 2B9kXLJdoRUE9Smo2Jh9CYq-KWyz9ZYTQA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhE1np8gzhyE-%2B9kXLJdoRUE9Smo2Jh9CYq-KWyz9ZYTQA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnTBgJuHEPitfYp34zgjfkW8KE8LdOdeLYSmGouccFmkTQ%40mail.gmail.com.
--001a1144b420169429053d237857
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>The appeal of `make_` is that there is already `make_=
signed` which is closely related: it takes one type and changes a single at=
tribute about it, yielding another type.<br><br></div>The `_t` variants are=
a convenience types; they're another matter altogether. For example, `=
make_signed_t<T>` which is shorthand for `typename make_signed<T&g=
t;::type`.<br><div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">On Thu, Sep 22, 2016 at 11:43 AM, D. B. <span dir=3D"ltr"><<a target=
=3D"_blank" href=3D"mailto:db0451@gmail.com">db0451@gmail.com</a>></span=
> wrote:<br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><div dir=3D"l=
tr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"gm=
ail-">On Thu, Sep 22, 2016 at 5:28 PM, John McFarlane <span dir=3D"ltr"><=
;<a target=3D"_blank" href=3D"mailto:mcfarlane.john@gmail.com">mcfarlane.jo=
hn@gmail.com</a>></span> wrote:<a target=3D"_blank" href=3D"http://www.o=
pen-std.org/jtc1/sc22/wg21/docs/papers/2016/p0381r0.html"></a><br></span><b=
lockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex" class=3D"gmail_quote"><span class=3D"gmail-"><div=
dir=3D"ltr"><br>In it, the equivalent to <i>std::int_t<BITS></i> wou=
ld be <i>set_width_t<int, BITS></i>. This type could be user-speciali=
zed for non-built-in integral types.<br><br>Note that that name is certainl=
y going to change (perhaps <i>make_int_t</i> or <i>make_bitwidth_t</i>) and=
that I suggest <i>fast</i> and <i>least</i> variants.<span></span><br><spa=
n></span></div></span><span>
<p></p>
-- </span><br></blockquote><div><br></div><div>make_ isn't any better t=
hough, is it? as a prefix for types, that too seems both redunant (vs the _=
t suffix) and a recipe for confusion (wrt make_*() functions)<br><br>=C2=A0=
<br></div></div><br></div></div><span class=3D"gmail-">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a target=3D"_blank" href=3D"mailto:std-proposals+unsubscribe@isocp=
p.org">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a target=3D"_blank" href=3D"mailto:st=
d-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a target=3D"_blank" href=3D"https=
://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhE1np8gzhyE-%=
2B9kXLJdoRUE9Smo2Jh9CYq-KWyz9ZYTQA%40mail.gmail.com?utm_medium=3Demail&=
utm_source=3Dfooter">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/CACGiwhE1np8gzhyE-%<wbr>2B9kXLJdoRUE9Smo2Jh9CYq-<wbr>KWyz9=
ZYTQA%40mail.gmail.com</a>.<br>
</blockquote></div><br></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CABPJVnTBgJuHEPitfYp34zgjfkW8KE8LdOde=
LYSmGouccFmkTQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnTBgJuHEPit=
fYp34zgjfkW8KE8LdOdeLYSmGouccFmkTQ%40mail.gmail.com</a>.<br />
--001a1144b420169429053d237857--
.
Author: "D. B." <db0451@gmail.com>
Date: Fri, 23 Sep 2016 08:20:49 +0100
Raw View
--001a114d3c842bb975053d279ee1
Content-Type: text/plain; charset=UTF-8
On Fri, Sep 23, 2016 at 3:23 AM, John McFarlane <john@mcfarlane.name> wrote:
> The appeal of `make_` is that there is already `make_signed` which is
> closely related: it takes one type and changes a single attribute about it,
> yielding another type.
>
> The `_t` variants are a convenience types; they're another matter
> altogether. For example, `make_signed_t<T>` which is shorthand for
> `typename make_signed<T>::type`.
>
make_signed, of course! I forgot about that one (despite having just used
it a few weeks ago). In retrospect I would have to apply the same
scepticism to it too, although it didn't cross my mind at the time. :D But
that aside, you have a fair basis for choosing the name.
As an aside, I wonder, will the stdlib ever start putting its type helper
structs in detail namespaces (as they are effectively just boilerplate) and
only expose the related using alias - as I do with some of my template
stuff - or is there a reason to keep both available as part of the
interface?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhE4OSprn3NtmWmhMeCEDuMtcdp6qK9RsDodOsH_hkFtqA%40mail.gmail.com.
--001a114d3c842bb975053d279ee1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Sep 23, 2016 at 3:23 AM, John McFarlane <span dir=3D"ltr"><<a href=
=3D"mailto:john@mcfarlane.name" target=3D"_blank">john@mcfarlane.name</a>&g=
t;</span> wrote:<br><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>Th=
e appeal of `make_` is that there is already `make_signed` which is closely=
related: it takes one type and changes a single attribute about it, yieldi=
ng another type.<br><br></div>The `_t` variants are a convenience types; th=
ey're another matter altogether. For example, `make_signed_t<T>` =
which is shorthand for `typename make_signed<T>::type`.<br></div></bl=
ockquote><div><br></div><div><br></div><div>make_signed, of course! I forgo=
t about that one (despite having just used it a few weeks ago). In retrospe=
ct I would have to apply the same scepticism to it too, although it didn=
9;t cross my mind at the time. :D But that aside, you have a fair basis for=
choosing the name.<br><br>As an aside, I wonder, will the stdlib ever star=
t putting its type helper structs in detail namespaces (as they are effecti=
vely just boilerplate) and only expose the related using alias - as I do wi=
th some of my template stuff - or is there a reason to keep both available =
as part of the interface?<br><br></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhE4OSprn3NtmWmhMeCEDuMtcdp6qK9R=
sDodOsH_hkFtqA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhE4OSprn3Nt=
mWmhMeCEDuMtcdp6qK9RsDodOsH_hkFtqA%40mail.gmail.com</a>.<br />
--001a114d3c842bb975053d279ee1--
.
Author: John McFarlane <mcfarlane.john@gmail.com>
Date: Fri, 23 Sep 2016 13:48:00 -0700 (PDT)
Raw View
------=_Part_4460_1084331701.1474663681110
Content-Type: multipart/alternative;
boundary="----=_Part_4461_688992549.1474663681110"
------=_Part_4461_688992549.1474663681110
Content-Type: text/plain; charset=UTF-8
On Friday, September 23, 2016 at 12:20:52 AM UTC-7, D. B. wrote:
>
>
> As an aside, I wonder, will the stdlib ever start putting its type helper
> structs in detail namespaces (as they are effectively just boilerplate) and
> only expose the related using alias - as I do with some of my template
> stuff - or is there a reason to keep both available as part of the
> interface?
>
> If there were any reason (perhaps a map of type transforms which required
all elements to have a `::type` member), one could write their own `::type`
variant from the `_t` definition.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/95d1dd3c-3326-4876-b9d1-3d6f07b4a449%40isocpp.org.
------=_Part_4461_688992549.1474663681110
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, September 23, 2016 at 12:20:52 AM UTC-7, D. B. =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><d=
iv class=3D"gmail_quote"><br><div>As an aside, I wonder, will the stdlib ev=
er start putting its type helper structs in detail namespaces (as they are =
effectively just boilerplate) and only expose the related using alias - as =
I do with some of my template stuff - or is there a reason to keep both ava=
ilable as part of the interface?<br><br></div></div></div></div></blockquot=
e>If there were any reason (perhaps a map of type transforms which required=
all elements to have a `::type` member), one could write their own `::type=
` variant from the `_t` definition.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/95d1dd3c-3326-4876-b9d1-3d6f07b4a449%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/95d1dd3c-3326-4876-b9d1-3d6f07b4a449=
%40isocpp.org</a>.<br />
------=_Part_4461_688992549.1474663681110--
------=_Part_4460_1084331701.1474663681110--
.