Topic: int_t template alias and Standardese


Author: Myriachan <myriachan@gmail.com>
Date: Tue, 26 Feb 2019 16:09:19 -0800 (PST)
Raw View
------=_Part_1485_1260557567.1551226159951
Content-Type: multipart/alternative;
 boundary="----=_Part_1486_879498402.1551226159951"

------=_Part_1486_879498402.1551226159951
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'd like to make a proposal for these things:

1. Allowing implementations to define intN_t for values of N other than 8,=
=20
16, 32, 64; reasonable examples could be 24 or 128.  This would make C++=20
<cstdint> match C <stdint.h> in that respect.  Likewise for certain=20
matching definitions in <atomic>.
2. Template aliases int_t<N> and uint_t<N> that are aliases for intN_t and=
=20
uintN_t respectively, when they exist for that N.
3. Template aliases int_least_t<N>, uint_least_t<N>, int_fast_t<N>,=20
uint_fast_t<T> that are similar, except that they will automatically select=
=20
the next size up, if one exists.

But I have some questions about this.


For (1), I was considering changing the wording of the synopsis in=20
[cstdint.syn] to something like this:

// For the following, N is a positive integer written with no leading zeros=
..
using intN_t =3D signed integer type;  // potentially optional
using int_leastN_t =3D signed integer type;  // optional for N =E2=88=89 { =
8, 16, 32,=20
64 }
using int_fastN_t =3D unsigned integer type;  // optional for N =E2=88=89 {=
 8, 16,=20
32, 64 }

With intN_t and uintN_t, for 8, 16, 32, 64, these are mandatory if there=20
exists a type in the implementation that would meet the definition.  This=
=20
rule, however, is defined by C and not by C++.  Other values of N are=20
allowed but are optional.  Would I need to express that detail, or is it=20
implied by referencing C?

For [u]int_leastN_t and [u]int_fastN_t, the comment should be clear=20
enough.  I don't know whether the "not element of" symbol is appropriate in=
=20
the C++ Standard, though.


For (2), the template definition is clear:

template <int N>
using int_t =3D signed integer type;

How should this be worded, though?  The template should be mandatory, but=
=20
int_t<N> should only have a specialization if intN_t exists.  Otherwise, it=
=20
should be the same as an undefined declared template without a=20
specialization so that it's SFINAE-compatible.

This brings up another question: what should happen if the implementation=
=20
defines none of the intN_t types?  Ideally, it would mean that int_t's=20
underlying template has no specializations, and any attempt to use it would=
=20
fail.  Does this run afoul of [temp.res]/8, though, because it's a then a=
=20
template for which no valid specialization exists?


For (3):

template <int N>
using int_least_t =3D signed integer type;
template <int N>
using int_fast_t =3D signed integer type;

These templates are mandatory.  I don't know the right wording, though.  If=
=20
N <=3D 0 or N > M where M is the largest integer such that int_leastN_t is=
=20
defined, it should act like the specialization doesn't exist.  For positive=
=20
integers less than M, it should be alias of int_leastL_t, where L is the=20
least integer such that int_leastL_t exists; likewise for int_fast_t<>.


As final questions: How well would these proposals likely be received? =20
Should the templates be presented as a separate proposal from allowing N=20
values not in 8, 16, 32, 64 to match C?

Thanks,=20

Melissa

--=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/f1eada83-f684-4cd1-969a-d20f79e84d72%40isocpp.or=
g.

------=_Part_1486_879498402.1551226159951
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;d like to make a proposal for these things:<br><div>=
<br></div><div>1. Allowing implementations to define intN_t for values of N=
 other than 8, 16, 32, 64; reasonable examples could be 24 or 128.=C2=A0 Th=
is would make C++ &lt;cstdint&gt; match C &lt;stdint.h&gt; in that respect.=
=C2=A0 Likewise for certain matching definitions in &lt;atomic&gt;.<br></di=
v><div>2. Template aliases int_t&lt;N&gt; and uint_t&lt;N&gt; that are alia=
ses for intN_t and uintN_t respectively, when they exist for that N.</div><=
div>3. Template aliases int_least_t&lt;N&gt;, uint_least_t&lt;N&gt;, int_fa=
st_t&lt;N&gt;, uint_fast_t&lt;T&gt; that are similar, except that they will=
 automatically select the next size up, if one exists.</div><div><br></div>=
<div>But I have some questions about this.<br></div><div><br></div><div><br=
></div><div>For (1), I was considering changing the wording of the synopsis=
 in [cstdint.syn] to something like this:</div><div><br></div><div>// For t=
he following, N is a positive integer written with no leading zeros.</div><=
div></div><div>using intN_t =3D signed integer type;=C2=A0 // potentially o=
ptional</div><div>using int_leastN_t =3D signed integer type;=C2=A0 // opti=
onal for N =E2=88=89 { 8, 16, 32, 64 }<br></div><div>using int_fastN_t =3D =
unsigned integer type;=C2=A0 // optional for N =E2=88=89 { 8, 16, 32, 64 }<=
/div><div><br></div><div>With intN_t and uintN_t, for 8, 16, 32, 64, these =
are mandatory if there exists a type in the implementation that would meet =
the definition.=C2=A0 This rule, however, is defined by C and not by C++.=
=C2=A0 Other values of N are allowed but are optional.=C2=A0 Would I need t=
o express that detail, or is it implied by referencing C?</div><div><br></d=
iv><div>For [u]int_leastN_t and [u]int_fastN_t, the comment should be clear=
 enough.=C2=A0 I don&#39;t know whether the &quot;not element of&quot; symb=
ol is appropriate in the C++ Standard, though.<br></div><div><br></div><div=
><br></div><div>For (2), the template definition is clear:<br></div><div></=
div><div><br></div><div><div>template &lt;int N&gt;</div><div>using int_t =
=3D signed integer type;</div><div><br></div><div>How should this be worded=
, though?=C2=A0 The template should be mandatory, but int_t&lt;N&gt; should=
 only have a specialization if intN_t exists.=C2=A0 Otherwise, it should be=
 the same as an undefined declared template without a specialization so tha=
t it&#39;s SFINAE-compatible.</div><div><br></div><div>This brings up anoth=
er question: what should happen if the implementation defines none of the i=
ntN_t types?=C2=A0 Ideally, it would mean that int_t&#39;s underlying templ=
ate has no specializations, and any attempt to use it would fail.=C2=A0 Doe=
s this run afoul of [temp.res]/8, though, because it&#39;s a then a templat=
e for which no valid specialization exists?<br></div><div><br></div><div><b=
r></div><div>For (3):<br></div><div><br></div><div><div>template &lt;int N&=
gt;</div><div>using int_least_t =3D signed integer type;<br></div><div><div=
>template &lt;int N&gt;</div><div>using int_fast_t =3D signed integer type;=
<br></div><div><br></div><div>These templates are mandatory.=C2=A0 I don&#3=
9;t know the right wording, though.=C2=A0 If N &lt;=3D 0 or N &gt; M where =
M is the largest integer such that int_leastN_t is defined, it should act l=
ike the specialization doesn&#39;t exist.=C2=A0 For positive integers less =
than M, it should be alias of int_leastL_t, where L is the least integer su=
ch that int_leastL_t exists; likewise for int_fast_t&lt;&gt;.</div><div><br=
></div><div><br></div><div>As final questions: How well would these proposa=
ls likely be received?=C2=A0 Should the templates be presented as a separat=
e proposal from allowing N values not in 8, 16, 32, 64 to match C?</div><di=
v><br></div><div>Thanks, <br></div><div><br></div><div>Melissa<br></div></d=
iv></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f1eada83-f684-4cd1-969a-d20f79e84d72%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f1eada83-f684-4cd1-969a-d20f79e84d72=
%40isocpp.org</a>.<br />

------=_Part_1486_879498402.1551226159951--

------=_Part_1485_1260557567.1551226159951--

.


Author: John McFarlane <john@mcfarlane.name>
Date: Fri, 1 Mar 2019 19:33:37 +0000
Raw View
--0000000000003ca8e705830d7cbf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 27 Feb 2019 at 00:09 Myriachan <myriachan@gmail.com> wrote:

> I'd like to make a proposal for these things:
>
> 1. Allowing implementations to define intN_t for values of N other than 8=
,
> 16, 32, 64; reasonable examples could be 24 or 128.  This would make C++
> <cstdint> match C <stdint.h> in that respect.  Likewise for certain
> matching definitions in <atomic>.
> 2. Template aliases int_t<N> and uint_t<N> that are aliases for intN_t an=
d
> uintN_t respectively, when they exist for that N.
> 3. Template aliases int_least_t<N>, uint_least_t<N>, int_fast_t<N>,
> uint_fast_t<T> that are similar, except that they will automatically sele=
ct
> the next size up, if one exists.
>
> But I have some questions about this.
>
>
> For (1), I was considering changing the wording of the synopsis in
> [cstdint.syn] to something like this:
>
> // For the following, N is a positive integer written with no leading
> zeros.
> using intN_t =3D signed integer type;  // potentially optional
> using int_leastN_t =3D signed integer type;  // optional for N =E2=88=89 =
{ 8, 16,
> 32, 64 }
> using int_fastN_t =3D unsigned integer type;  // optional for N =E2=88=89=
 { 8, 16,
> 32, 64 }
>
> With intN_t and uintN_t, for 8, 16, 32, 64, these are mandatory if there
> exists a type in the implementation that would meet the definition.  This
> rule, however, is defined by C and not by C++.  Other values of N are
> allowed but are optional.  Would I need to express that detail, or is it
> implied by referencing C?
>
> For [u]int_leastN_t and [u]int_fastN_t, the comment should be clear
> enough.  I don't know whether the "not element of" symbol is appropriate =
in
> the C++ Standard, though.
>
>
> For (2), the template definition is clear:
>
> template <int N>
> using int_t =3D signed integer type;
>
> How should this be worded, though?  The template should be mandatory, but
> int_t<N> should only have a specialization if intN_t exists.  Otherwise, =
it
> should be the same as an undefined declared template without a
> specialization so that it's SFINAE-compatible.
>
> This brings up another question: what should happen if the implementation
> defines none of the intN_t types?  Ideally, it would mean that int_t's
> underlying template has no specializations, and any attempt to use it wou=
ld
> fail.  Does this run afoul of [temp.res]/8, though, because it's a then a
> template for which no valid specialization exists?
>
>
> For (3):
>
> template <int N>
> using int_least_t =3D signed integer type;
> template <int N>
> using int_fast_t =3D signed integer type;
>
> These templates are mandatory.  I don't know the right wording, though.
> If N <=3D 0 or N > M where M is the largest integer such that int_leastN_=
t is
> defined, it should act like the specialization doesn't exist.  For positi=
ve
> integers less than M, it should be alias of int_leastL_t, where L is the
> least integer such that int_leastL_t exists; likewise for int_fast_t<>.
>
>
> As final questions: How well would these proposals likely be received?
> Should the templates be presented as a separate proposal from allowing N
> values not in 8, 16, 32, 64 to match C?
>

There is definitely a desire for such things. P0102 <http://wg21.link/p0102=
> is
one example of a similar proposal.

In addition, I'd like to see a more general purpose solution which the user
can customise (P0675 <http://wg21.link/P0675>).

John

Thanks,
>
> 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/f1eada83-f68=
4-4cd1-969a-d20f79e84d72%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f1eada83-f6=
84-4cd1-969a-d20f79e84d72%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=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/CABPJVnRdh-da3enVO7CEQJjmsj_Ze29vGV2GwJpg7tUxVP4=
PgQ%40mail.gmail.com.

--0000000000003ca8e705830d7cbf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Wed, 27 Feb 2019 at 00:09 Myriachan &lt;<a href=3D"mailto:myriach=
an@gmail.com" target=3D"_blank">myriachan@gmail.com</a>&gt; wrote:<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I&#39;d like to make a pro=
posal for these things:<br><div><br></div><div>1. Allowing implementations =
to define intN_t for values of N other than 8, 16, 32, 64; reasonable examp=
les could be 24 or 128.=C2=A0 This would make C++ &lt;cstdint&gt; match C &=
lt;stdint.h&gt; in that respect.=C2=A0 Likewise for certain matching defini=
tions in &lt;atomic&gt;.<br></div><div>2. Template aliases int_t&lt;N&gt; a=
nd uint_t&lt;N&gt; that are aliases for intN_t and uintN_t respectively, wh=
en they exist for that N.</div><div>3. Template aliases int_least_t&lt;N&gt=
;, uint_least_t&lt;N&gt;, int_fast_t&lt;N&gt;, uint_fast_t&lt;T&gt; that ar=
e similar, except that they will automatically select the next size up, if =
one exists.</div><div><br></div><div>But I have some questions about this.<=
br></div><div><br></div><div><br></div><div>For (1), I was considering chan=
ging the wording of the synopsis in [cstdint.syn] to something like this:</=
div><div><br></div><div>// For the following, N is a positive integer writt=
en with no leading zeros.</div><div></div><div>using intN_t =3D signed inte=
ger type;=C2=A0 // potentially optional</div><div>using int_leastN_t =3D si=
gned integer type;=C2=A0 // optional for N =E2=88=89 { 8, 16, 32, 64 }<br><=
/div><div>using int_fastN_t =3D unsigned integer type;=C2=A0 // optional fo=
r N =E2=88=89 { 8, 16, 32, 64 }</div><div><br></div><div>With intN_t and ui=
ntN_t, for 8, 16, 32, 64, these are mandatory if there exists a type in the=
 implementation that would meet the definition.=C2=A0 This rule, however, i=
s defined by C and not by C++.=C2=A0 Other values of N are allowed but are =
optional.=C2=A0 Would I need to express that detail, or is it implied by re=
ferencing C?</div><div><br></div><div>For [u]int_leastN_t and [u]int_fastN_=
t, the comment should be clear enough.=C2=A0 I don&#39;t know whether the &=
quot;not element of&quot; symbol is appropriate in the C++ Standard, though=
..<br></div><div><br></div><div><br></div><div>For (2), the template definit=
ion is clear:<br></div><div></div><div><br></div><div><div>template &lt;int=
 N&gt;</div><div>using int_t =3D signed integer type;</div><div><br></div><=
div>How should this be worded, though?=C2=A0 The template should be mandato=
ry, but int_t&lt;N&gt; should only have a specialization if intN_t exists.=
=C2=A0 Otherwise, it should be the same as an undefined declared template w=
ithout a specialization so that it&#39;s SFINAE-compatible.</div><div><br><=
/div><div>This brings up another question: what should happen if the implem=
entation defines none of the intN_t types?=C2=A0 Ideally, it would mean tha=
t int_t&#39;s underlying template has no specializations, and any attempt t=
o use it would fail.=C2=A0 Does this run afoul of [temp.res]/8, though, bec=
ause it&#39;s a then a template for which no valid specialization exists?<b=
r></div><div><br></div><div><br></div><div>For (3):<br></div><div><br></div=
><div><div>template &lt;int N&gt;</div><div>using int_least_t =3D signed in=
teger type;<br></div><div><div>template &lt;int N&gt;</div><div>using int_f=
ast_t =3D signed integer type;<br></div><div><br></div><div>These templates=
 are mandatory.=C2=A0 I don&#39;t know the right wording, though.=C2=A0 If =
N &lt;=3D 0 or N &gt; M where M is the largest integer such that int_leastN=
_t is defined, it should act like the specialization doesn&#39;t exist.=C2=
=A0 For positive integers less than M, it should be alias of int_leastL_t, =
where L is the least integer such that int_leastL_t exists; likewise for in=
t_fast_t&lt;&gt;.</div><div><br></div><div><br></div><div>As final question=
s: How well would these proposals likely be received?=C2=A0 Should the temp=
lates be presented as a separate proposal from allowing N values not in 8, =
16, 32, 64 to match C?</div></div></div></div></div></blockquote><div><br><=
/div></div><div dir=3D"ltr"><div class=3D"gmail_quote"><div>There is defini=
tely a desire for such things. <a href=3D"http://wg21.link/p0102" target=3D=
"_blank">P0102</a>=C2=A0is one example of a similar proposal. <br></div><di=
v><br></div><div>In addition, I&#39;d like to see a more general purpose so=
lution which the user can customise (<a href=3D"http://wg21.link/P0675">P06=
75</a>).<br></div></div><div class=3D"gmail_quote"><br></div><div class=3D"=
gmail_quote">John</div><div class=3D"gmail_quote"><br></div></div><div dir=
=3D"ltr"><div class=3D"gmail_quote"><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><div><div><div>Thanks, <br></div><div><br></div><div>Melissa<=
br></div></div></div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f1eada83-f684-4cd1-969a-d20f79e84d72%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f1eada83-f684-=
4cd1-969a-d20f79e84d72%40isocpp.org</a>.<br>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CABPJVnRdh-da3enVO7CEQJjmsj_Ze29vGV2G=
wJpg7tUxVP4PgQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnRdh-da3enV=
O7CEQJjmsj_Ze29vGV2GwJpg7tUxVP4PgQ%40mail.gmail.com</a>.<br />

--0000000000003ca8e705830d7cbf--

.