Topic: Champion for N4254 (UDL for size_t)?
Author: rhalbersma@gmail.com
Date: Wed, 14 Oct 2015 12:10:37 -0700 (PDT)
Raw View
------=_Part_904_128117482.1444849837622
Content-Type: multipart/alternative;
boundary="----=_Part_905_1780221229.1444849837622"
------=_Part_905_1780221229.1444849837622
Content-Type: text/plain; charset=UTF-8
I'd like to inquire whether anyone who's attending the upcoming Kona
meeting (LEWG in particular) would be willing to champion my paper N4254
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4254.html>("User-Defined
Literals for size_t (and ptrdiff_t)"?
As for its status: I've been unable to attend any meetings, but I've had
some feedback from a national body on it, mainly expressing the wish to
discuss the claims to single digit suffices in a broader context, and also
to reconsider the actual letters for the proposed suffices _z and _t.
Please contact me and I'll forward the NB comment.
For what it's worth, there has been mildly positive feedback from several
places on the web (two comments linking to the proposal on Herb Sutter's
blog gathered 14 upvotes and no downvotes, and similar results on Reddit).
Eric Niebler also has a _z suffix for size_t literals in his Meta support
library for ranges-v3 (though using a literatal operator template to
generate integral_contant<size_t, N> literals that implicitly convert to
size_t).
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_905_1780221229.1444849837622
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'd like to inquire whether anyone who's attending=
the upcoming Kona meeting (LEWG in particular) would be willing to champio=
n my paper <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/20=
14/n4254.html">N4254 </a>("User-Defined Literals for size_t (and ptrdi=
ff_t)"?<div><br></div><div>As for its status: I've been unable to =
attend any meetings, but I've had some feedback from a national body on=
it, mainly expressing the wish to discuss the claims to single digit suffi=
ces in a broader context, and also to reconsider the actual letters for the=
proposed suffices _z and _t. Please contact me and I'll forward the NB=
comment.</div><div><br></div><div>For what it's worth, there has been =
mildly positive feedback from several places on the web (two comments linki=
ng to the proposal on Herb Sutter's blog gathered 14 upvotes and no dow=
nvotes, and similar results on Reddit). Eric Niebler also has a _z suffix f=
or size_t literals in his Meta support library for ranges-v3 (though using =
a literatal operator template to generate integral_contant<size_t, N>=
literals that implicitly convert to size_t).</div><div><br></div><div><br>=
<div><br></div><div><br></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_905_1780221229.1444849837622--
------=_Part_904_128117482.1444849837622--
.
Author: Myriachan <myriachan@gmail.com>
Date: Wed, 14 Oct 2015 14:34:31 -0700 (PDT)
Raw View
------=_Part_30_1877354777.1444858471517
Content-Type: multipart/alternative;
boundary="----=_Part_31_1542429074.1444858471517"
------=_Part_31_1542429074.1444858471517
Content-Type: text/plain; charset=UTF-8
This sentence doesn't feel correct:
However, the above might entail undefined behavior (with no diagnostic
> required!) whenever v.size() is beyond the range of an unsigned (e.g.
> more than 2^32 elements on most 64-bit systems) since then the loop
> variable i will wrap-around, never actually reaching the bound.
>
This isn't undefined behavior. i will wrap, which is defined behavior with
unsigned integer types. You'll then be accessing the beginning of the
vector again, which is defined behavior. An infinite loop here is a bug,
but it's a well-defined infinite loop.
Melissa
On Wednesday, October 14, 2015 at 12:10:37 PM UTC-7, rhalb...@gmail.com
wrote:
>
> I'd like to inquire whether anyone who's attending the upcoming Kona
> meeting (LEWG in particular) would be willing to champion my paper N4254
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4254.html>("User-Defined
> Literals for size_t (and ptrdiff_t)"?
>
> As for its status: I've been unable to attend any meetings, but I've had
> some feedback from a national body on it, mainly expressing the wish to
> discuss the claims to single digit suffices in a broader context, and also
> to reconsider the actual letters for the proposed suffices _z and _t.
> Please contact me and I'll forward the NB comment.
>
> For what it's worth, there has been mildly positive feedback from several
> places on the web (two comments linking to the proposal on Herb Sutter's
> blog gathered 14 upvotes and no downvotes, and similar results on Reddit).
> Eric Niebler also has a _z suffix for size_t literals in his Meta support
> library for ranges-v3 (though using a literatal operator template to
> generate integral_contant<size_t, N> literals that implicitly convert to
> size_t).
>
>
>
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_31_1542429074.1444858471517
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This sentence doesn't feel correct:<br><br><blockquote=
style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 2=
04); padding-left: 1ex;" class=3D"gmail_quote"> However, the above might en=
tail undefined behavior (with no diagnostic required!) whenever <code>v.siz=
e()</code> is beyond the range of an <code>unsigned</code> (e.g. more than =
<code>2^32</code> elements on most 64-bit systems) since then the loop vari=
able <code>i</code> will wrap-around, never actually reaching the bound.<br=
></blockquote><br>This isn't undefined behavior.=C2=A0 <span style=3D"f=
ont-family: courier new,monospace;">i</span> will wrap, which is defined be=
havior with unsigned integer types.=C2=A0 You'll then be accessing the =
beginning of the vector again, which is defined behavior.=C2=A0 An infinite=
loop here is a bug, but it's a well-defined infinite loop.<br><br>Meli=
ssa<br><br>On Wednesday, October 14, 2015 at 12:10:37 PM UTC-7, rhalb...@gm=
ail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>I'd like to inquire whether anyone who's attending the upcoming Ko=
na meeting (LEWG in particular) would be willing to champion my paper <a hr=
ef=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4254.html" t=
arget=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://ww=
w.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fd=
ocs%2Fpapers%2F2014%2Fn4254.html\46sa\75D\46sntz\0751\46usg\75AFQjCNH-SuHYm=
2q4io4cJVHUazmlATWiyg';return true;" onclick=3D"this.href=3D'http:/=
/www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%=
2Fdocs%2Fpapers%2F2014%2Fn4254.html\46sa\75D\46sntz\0751\46usg\75AFQjCNH-Su=
HYm2q4io4cJVHUazmlATWiyg';return true;">N4254 </a>("User-Defined L=
iterals for size_t (and ptrdiff_t)"?<div><br></div><div>As for its sta=
tus: I've been unable to attend any meetings, but I've had some fee=
dback from a national body on it, mainly expressing the wish to discuss the=
claims to single digit suffices in a broader context, and also to reconsid=
er the actual letters for the proposed suffices _z and _t. Please contact m=
e and I'll forward the NB comment.</div><div><br></div><div>For what it=
's worth, there has been mildly positive feedback from several places o=
n the web (two comments linking to the proposal on Herb Sutter's blog g=
athered 14 upvotes and no downvotes, and similar results on Reddit). Eric N=
iebler also has a _z suffix for size_t literals in his Meta support library=
for ranges-v3 (though using a literatal operator template to generate inte=
gral_contant<size_t, N> literals that implicitly convert to size_t).<=
/div><div><br></div><div><br><div><br></div><div><br></div></div></div></bl=
ockquote></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_31_1542429074.1444858471517--
------=_Part_30_1877354777.1444858471517--
.
Author: Moritz Klammler <moritz.klammler@gmail.com>
Date: Thu, 15 Oct 2015 01:39:35 +0200
Raw View
I think this is an awesome proposal. Very simple but highly useful.
I cannot offer a champion but I'd like to supply two more arguments for
your proposal.
1. For the fixed-width integral types defined in `<cstdint>` there are
already the `[U]INT{8,16,32,64}_C` function macros defined in the
same header. They're not pretty but sometimes useful. For
`std::size_t` and `std::ptrdiff_t` (which are, at least in my code,
much more frequently needed), no such feature exists right now.
2. While I would very much welcome the ability to write
for (auto i = 0z; i < v.size(); ++i)
std::cout << "v[" << i << "] = " << v[i] << "\n";
over
for (std::size_t i = 0; i < v.size(); ++i)
std::cout << "v[" << i << "] = " << v[i] << "\n";
it can be argued that this is at most a minor stylistic issue.
However, in the case of template argument deduction, the need for
precisely typed literals becomes pressing. Consider the following
perfectly reasonable setup.
template < typename T >
struct example;
template < typename T >
example<T>
operator+(const example<T>&, const example<T>&);
template < typename FuncT, typename ValT >
example<ValT>
make_example(FuncT, ValT);
Now, some seemingly innocent code like
auto s1 = make_example([](){}, sizeof(int));
auto s2 = make_example([](){}, 0);
auto s3 = s1 + s2;
won't compile. Since you cannot spell the type of the lambda, you
cannot be explicit about the template arguments. And even if you
could, suppressing template argument deduction is generally
considered poor style. So you have to write this
auto s2 = make_example([](){}, static_cast<std::size_t>(0));
which stil is arguably cleaner than this
auto lambda = [](){};
auto s2 = make_example<decltype(lambda), std::size_t>(lambda, 0);
Here, your proposal really shines.
auto s2 = make_example([](){}, 0z);
I would have written those literal operators for myself but having a
canonical version in the standard library seems much preferable.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Thu, 15 Oct 2015 00:17:55 -0700 (PDT)
Raw View
------=_Part_650_73002870.1444893475937
Content-Type: multipart/alternative;
boundary="----=_Part_651_1096888459.1444893475937"
------=_Part_651_1096888459.1444893475937
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, October 14, 2015 at 12:10:37 PM UTC-7, rhalb...@gmail.com=20
wrote:
>
> I'd like to inquire whether anyone who's attending the upcoming Kona=20
> meeting (LEWG in particular) would be willing to champion my paper N4254=
=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4254.html>("Use=
r-Defined=20
> Literals for size_t (and ptrdiff_t)"?
>
> As for its status: I've been unable to attend any meetings, but I've had=
=20
> some feedback from a national body on it, mainly expressing the wish to=
=20
> discuss the claims to single digit suffices in a broader context, and als=
o=20
> to reconsider the actual letters for the proposed suffices _z and _t.=20
> Please contact me and I'll forward the NB comment.
>
> For what it's worth, there has been mildly positive feedback from several=
=20
> places on the web (two comments linking to the proposal on Herb Sutter's=
=20
> blog gathered 14 upvotes and no downvotes, and similar results on Reddit)=
..=20
> Eric Niebler also has a _z suffix for size_t literals in his Meta support=
=20
> library for ranges-v3 (though using a literatal operator template to=20
> generate integral_contant<size_t, N> literals that implicitly convert to=
=20
> size_t).
>
>
I'll be at Kona (my first time going!), and I'm interested in this topic,=
=20
but I wouldn't be a champion of this particular proposal. I have some=20
hopefully-constructive comments, though:
(1)
Moritz Klammler suggested the use-case
for (auto i =3D 0z; i < v.size(); ++i)=20
std::cout << "v[" << i << "] =3D " << v[i] << "\n";=20
However, this is technically incorrect (the best kind of incorrect!) =E2=80=
=94=20
presumably the programmer intended decltype(i) to be=20
decltype(v)::size_type, but what he got was std::size_t instead. (These are=
=20
usually the same type, but can be different, for example if v is a vector=
=20
with a custom allocator.)
(2) I like the choice of "z" and "t" to match the printf specifiers; but I=
=20
would naively have expected the size_t specifier to be "zu", as in 42zu.=20
What if I want an integer literal of type std::ssize_t? After all, 42LL is=
=20
a *signed* long long; if you want it unsigned, you have to add the u=20
somewhere. Are we assuming that ptrdiff_t is always the same type as=20
ssize_t? (That might be a valid assumption; I don't actually know.) In=20
which case, I think it's weird that to get the signed resp. unsigned=20
versions of the type, you write t resp. z, which is out of keeping with=20
every integer suffix in the language today.
(3) Again on the subject of symmetry with the other integer suffixes: You=
=20
introduce a new(?) namespace std::literals::support_literals. I see that=20
N3642 introduced similarly named namespaces for string_literals,=20
chrono_literals, etc., so I see the pattern; but am I correct that the=20
existing integer literal suffixes u, l, ul, ll, ull, f, etc. etc., are=20
implemented in the language definition itself, not in the library? So if=20
this proposal is adopted, we'll have two completely incommensurable kinds=
=20
of integer-suffixes in the language: the built-in ones, and then the=20
UDL-supplied ones. It won't generally be obvious to programmers in 2019=20
which of the literal suffixes are built-in and which are UDLs, and why.
Therefore I would rather see some proposals on the subject of how to=20
reconcile UDLs with built-in literal-suffixes =E2=80=94 how can we make the=
two=20
kinds behave more like the same kind of thing? There may be proposals=20
already existing on the subject that I just don't know about.
It would be an interesting experiment to take one of the core language=20
suffixes =E2=80=94 say, "L" =E2=80=94 and reimplement it as a UDL. What wou=
ld break if we=20
do that? This experiment would give some insight into the things that would=
=20
break (or at least fail to work "as expected") if we add "z" as a UDL.
Off the top of my head:
- "0z" won't work in the preprocessor, even though "0ull" does.
- "0z" won't work unless you #include <cstddef> and then using namespace=20
std::literals::support_literals, which is a mouthful.
- Due to the above, "0z" is basically unusable inside .h files=20
<https://github.com/fmatthew5876/stdcxx-sv-literal/blob/master/proposal/dra=
ft.md#why-not-user-defined-literals>=20
(although modules might fix that?)
- What else?
- Can we patch any of the above issues so that it's not an issue anymore?
(4) Particularly because of the aforementioned
> "0z" won't work unless you #include <cstddef> and then using namespace=20
std::literals::support_literals, which is a mouthful.
I'm just not seeing the cost-benefit ratio here. Sure it might be nice to=
=20
write 0z, but I can already today write std::size_t(0), which is only a few=
=20
more characters, and doesn't require me to write using namespace=20
std::literals::support_literals everywhere in my code (nor even once at the=
=20
top of every .cpp file).
Which brings me back to point #1: I think in the vast majority of cases=20
where a C++ programmer *thinks* he needs a shorthand for std::size_t(0), he=
=20
*really* needs something else entirely =E2=80=94 most likely, a range-based=
for=20
loop.
HTH,
=E2=80=93Arthur
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_651_1096888459.1444893475937
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, October 14, 2015 at 12:10:37 PM UTC-7, rhalb...@gmail.com wro=
te:<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">I'd li=
ke to inquire whether anyone who's attending the upcoming Kona meeting =
(LEWG in particular) would be willing to champion my paper <a href=3D"http:=
//www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4254.html" target=3D"_b=
lank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.co=
m/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpaper=
s%2F2014%2Fn4254.html\46sa\75D\46sntz\0751\46usg\75AFQjCNH-SuHYm2q4io4cJVHU=
azmlATWiyg';return true;" onclick=3D"this.href=3D'http://www.google=
..com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpa=
pers%2F2014%2Fn4254.html\46sa\75D\46sntz\0751\46usg\75AFQjCNH-SuHYm2q4io4cJ=
VHUazmlATWiyg';return true;">N4254 </a>("User-Defined Literals for=
size_t (and ptrdiff_t)"?<div><br></div><div>As for its status: I'=
ve been unable to attend any meetings, but I've had some feedback from =
a national body on it, mainly expressing the wish to discuss the claims to =
single digit suffices in a broader context, and also to reconsider the actu=
al letters for the proposed suffices _z and _t. Please contact me and I'=
;ll forward the NB comment.</div><div><br></div><div>For what it's wort=
h, there has been mildly positive feedback from several places on the web (=
two comments linking to the proposal on Herb Sutter's blog gathered 14 =
upvotes and no downvotes, and similar results on Reddit). Eric Niebler also=
has a _z suffix for size_t literals in his Meta support library for ranges=
-v3 (though using a literatal operator template to generate integral_contan=
t<size_t, N> literals that implicitly convert to size_t).</div><div><=
br></div></div></blockquote><div><br></div><div>I'll be at Kona (my fir=
st time going!), and I'm interested in this topic, but I wouldn't b=
e a champion of this particular proposal. I have some hopefully-constructiv=
e comments, though:</div><div><br></div><div>(1)</div><div>Moritz Klammler =
suggested the use-case</div><div><font face=3D"courier new, monospace">=C2=
=A0 =C2=A0 for (auto i =3D 0z; i < v.size(); ++i)=C2=A0<br>=C2=A0 =C2=A0=
=C2=A0 =C2=A0 std::cout << "v[" << i << "=
] =3D " << v[i] << "\n";=C2=A0<br></font></div><=
div>However, this is technically incorrect (the best kind of incorrect!) =
=E2=80=94 presumably the programmer intended decltype(i) to be decltype(v):=
:size_type, but what he got was std::size_t instead. (These are usually the=
same type, but can be different, for example if v is a vector with a custo=
m allocator.)</div><div><br></div><div>(2) I like the choice of "z&quo=
t; and "t" to match the printf specifiers; but I would naively ha=
ve expected the size_t specifier to be "zu", as in <font face=3D"=
courier new, monospace">42zu</font>. What if I want an integer literal of t=
ype std::ssize_t? =C2=A0After all, <font face=3D"courier new, monospace">42=
LL</font> is a <b><i>signed</i></b> long long; if you want it unsigned, you=
have to add the <font face=3D"courier new, monospace">u</font> somewhere. =
Are we assuming that ptrdiff_t is always the same type as ssize_t? (That mi=
ght be a valid assumption; I don't actually know.) =C2=A0In which case,=
I think it's weird that to get the signed resp. unsigned versions of t=
he type, you write <font face=3D"courier new, monospace">t</font> resp. <fo=
nt face=3D"courier new, monospace">z</font>, which is out of keeping with e=
very integer suffix in the language today.</div><div><br></div><div>(3) Aga=
in on the subject of symmetry with the other integer suffixes: You introduc=
e a new(?) namespace std::literals::support_literals. I see that N3642 intr=
oduced similarly named namespaces for string_literals, chrono_literals, etc=
.., so I see the pattern; but am I correct that the existing integer literal=
suffixes <font face=3D"courier new, monospace">u, l, ul, ll, ull, f,</font=
>=C2=A0etc. etc., are implemented in the language definition itself, not in=
the library? So if this proposal is adopted, we'll have two completely=
incommensurable kinds of integer-suffixes in the language: the built-in on=
es, and then the UDL-supplied ones. It won't generally be obvious to pr=
ogrammers in 2019 which of the literal suffixes are built-in and which are =
UDLs, and why.</div><div>Therefore I would rather see some proposals on the=
subject of how to reconcile UDLs with built-in literal-suffixes =E2=80=94 =
how can we make the two kinds behave more like the same kind of thing? =C2=
=A0There may be proposals already existing on the subject that I just don&#=
39;t know about.</div><div>It would be an interesting experiment to take on=
e of the core language suffixes =E2=80=94 say, "L" =E2=80=94 and =
reimplement it as a UDL. What would break if we do that? This experiment wo=
uld give some insight into the things that would break (or at least fail to=
work "as expected") if we add "z" as a UDL.</div><div>=
Off the top of my head:</div><div>- "0z" won't work in the pr=
eprocessor, even though "0ull" does.</div><div>- "0z" w=
on't work unless you <font face=3D"courier new, monospace">#include <=
;cstddef></font> and then <font face=3D"courier new, monospace">using na=
mespace std::literals::support_literals</font>, which is a mouthful.</div><=
div>- Due to the above, "0z" is <a href=3D"https://github.com/fma=
tthew5876/stdcxx-sv-literal/blob/master/proposal/draft.md#why-not-user-defi=
ned-literals">basically unusable inside .h files</a> (although modules migh=
t fix that?)</div><div>- What else?</div><div>- Can we patch any of the abo=
ve issues so that it's not an issue anymore?</div><div><br></div><div>(=
4) Particularly because of the aforementioned</div><div><div>> "0z&=
quot; won't work unless you #include <cstddef> and then using nam=
espace std::literals::support_literals, which is a mouthful.</div></div><di=
v>I'm just not seeing the cost-benefit ratio here. Sure it might be nic=
e to write <font face=3D"courier new, monospace">0z</font>, but I can alrea=
dy today write <font face=3D"courier new, monospace">std::size_t(0)</font>,=
which is only a few more characters, and doesn't require me to write <=
font face=3D"courier new, monospace">using namespace std::literals::support=
_literals</font> everywhere in my code (nor even once at the top of every .=
cpp file).</div><div><br></div><div>Which brings me back to point #1: I thi=
nk in the vast majority of cases where a C++ programmer <i>thinks</i> he ne=
eds a shorthand for=C2=A0<font face=3D"courier new, monospace">std::size_t(=
0)</font>, he <i>really</i> needs something else entirely =E2=80=94 most li=
kely, a range-based for loop.</div><div><br></div><div>HTH,</div><div>=E2=
=80=93Arthur</div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_651_1096888459.1444893475937--
------=_Part_650_73002870.1444893475937--
.
Author: Moritz Klammler <moritz.klammler@gmail.com>
Date: Thu, 15 Oct 2015 09:53:41 +0200
Raw View
> Moritz Klammler suggested the use-case
>
> for (auto i =3D 0z; i < v.size(); ++i)
> std::cout << "v[" << i << "] =3D " << v[i] << "\n";
Well, actually, I've copied and pasted it from the proposal...
> However, this is technically incorrect (the best kind of incorrect!) =E2=
=80=94
> presumably the programmer intended decltype(i) to be
> decltype(v)::size_type, but what he got was std::size_t
> instead. (These are usually the same type, but can be different, for
> example if v is a vector with a custom allocator.)
Fair enough; the proposal also has a discussion about it. While there
is no guarantee that `std::vector<T>::size_type` is `std::size_t`, it
*is* guaranteed that a `std::size_t` is sufficient to index every byte
of memory and hence every element of any vector. Furthermore, there
won't be any (benign?) signed / unsigned compiler warnings because
`size_type` is required to be unsigned as is `std::size_t`. Again, this
is discussed in the proposal, too. So I think the idiom is perfectly
safe and wouldn't call it "incorrect".
> You introduce a new(?) namespace std::literals::support_literals. I
> see that N3642 introduced similarly named namespaces for
> string_literals, chrono_literals, etc., so I see the pattern; but am I
> correct that the existing integer literal suffixes u, l, ul, ll, ull,
> f, etc. etc., are implemented in the language definition itself, not
> in the library? So if this proposal is adopted, we'll have two
> completely incommensurable kinds of integer-suffixes in the language:
> the built-in ones, and then the UDL-supplied ones. It won't generally
> be obvious to programmers in 2019 which of the literal suffixes are
> built-in and which are UDLs, and why.
It actually makes a lot sense to me. `unsigned`, `long`, etc are types
implemented by the language itself so they have literal suffixes
implemented by the core language. `std::size_t` is a type defined by
the standard library (still not a user-defined type, though) so it has a
literal suffix defined by the standard library.
Note that there was a similar discussion predating C++14 regarding
binary literals. Some people would argue then that they should be
implemented as user-defined literals by the standard library but since
number parsing is a core-language feature (at least, it has always been
for octal, decimal and hex numbers) it was more consequent to implement
binary literals in the core language itself, too. This also made it
possible to use the `0b` *prefix* (consistent with `0x`) which would not
be possible with user-defined literals.
The use of `inline` `namespace`s for user-defined literals is a very
good pattern, I think. Note that because they are all nested `inline`,
each of these alternatives works.
std::string
f()
{
using namespace std;
return "hello, world"s;
}
std::string
g()
{
using namespace std::literals;
return "hello, world"s;
}
std::string
h()
{
using namespace std::string_literals;
return "hello, world"s;
}
I think this is a very good solution that offers simplicity where
possible and fine-grained control where needed.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Thu, 15 Oct 2015 01:43:20 -0700
Raw View
--047d7beba1dad4455f052220abc8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thu, Oct 15, 2015 at 12:53 AM, Moritz Klammler <moritz.klammler@gmail.co=
m
> wrote:
> > Moritz Klammler suggested the use-case
> >
> > for (auto i =3D 0z; i < v.size(); ++i)
> > std::cout << "v[" << i << "] =3D " << v[i] << "\n";
>
> Well, actually, I've copied and pasted it from the proposal...
>
Oops. My mistake. :)
<snip>
> It actually makes a lot sense to me. `unsigned`, `long`, etc are types
> implemented by the language itself so they have literal suffixes
> implemented by the core language. `std::size_t` is a type defined by
> the standard library (still not a user-defined type, though) so it has a
> literal suffix defined by the standard library.
>
I would argue that std::size_t bears the same relationship to the core
language as std::nullptr_t. The latter is merely a typedef for
decltype(nullptr), and the former is merely a typedef for decltype(sizeof
nullptr). The situation would be different for something like std::time_t,
which I'm pretty sure *is* just a made-up library type with no intrinsic
relationship to the core language.
> The use of `inline` `namespace`s for user-defined literals is a very
> good pattern, I think.
I don't disagree. *If* you're providing UDLs in C++14, then an inline
namespace is the right place for them. But notice that each of your
examples requires the use of a using-directive, which means it can't
(realistically speaking) appear at file scope in a header file. This means
there's no way to use 0z in a header.
However, I do recall now the previous discussion
<https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/hAnVRTl=
sQZY>
that proposed std::0z should work to get around that limitation.
=E2=80=93Arthur
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--047d7beba1dad4455f052220abc8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Oct 15, 2015 at 12:53 AM, Moritz Klammler <span di=
r=3D"ltr"><<a href=3D"mailto:moritz.klammler@gmail.com" target=3D"_blank=
">moritz.klammler@gmail.com</a>></span> wrote:<br><div class=3D"gmail_ex=
tra"><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">> Moritz =
Klammler suggested the use-case<br>
><br>
>=C2=A0 =C2=A0 =C2=A0for (auto i =3D 0z; i < v.size(); ++i)<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::cout << "v[" <=
;< i << "] =3D " << v[i] << "\n";<=
br>
<br>
Well, actually, I've copied and pasted it from the proposal...<br></blo=
ckquote><div><br></div><div>Oops. My mistake. :)</div><div><br></div><div>&=
lt;snip></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">It actually makes a lot sen=
se to me.=C2=A0 `unsigned`, `long`, etc are types<br>
implemented by the language itself so they have literal suffixes<br>
implemented by the core language.=C2=A0 `std::size_t` is a type defined by<=
br>
the standard library (still not a user-defined type, though) so it has a<br=
>
literal suffix defined by the standard library.<br></blockquote><div><br></=
div><div>I would argue that std::size_t bears the same relationship to the =
core language as std::nullptr_t.=C2=A0 The latter is merely a typedef for d=
ecltype(nullptr), and the former is merely a typedef for decltype(sizeof nu=
llptr).=C2=A0 The situation would be different for something like std::time=
_t, which I'm pretty sure=C2=A0<i>is</i> just a made-up library type wi=
th no intrinsic relationship to the core language.</div><div><br></div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">The use of `inline` `namespace`=
s for user-defined literals is a very<br>
good pattern, I think.</blockquote><div><br></div><div>I don't disagree=
.. =C2=A0<b><i>If</i></b> you're providing UDLs in C++14, then an inline=
namespace is the right place for them.=C2=A0 But notice that each of your =
examples requires the use of a using-directive, which means it can't (r=
ealistically speaking) appear at file scope in a header file. This means th=
ere's no way to use <font face=3D"monospace, monospace">0z</font> in a =
header.</div><div>However, I do recall now <a href=3D"https://groups.google=
..com/a/isocpp.org/forum/#!topic/std-proposals/hAnVRTlsQZY">the previous dis=
cussion</a> that proposed=C2=A0<font face=3D"monospace, monospace">std::0z<=
/font>=C2=A0should work=C2=A0to get around that limitation.</div><div><br><=
/div><div>=E2=80=93Arthur</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7beba1dad4455f052220abc8--
.
Author: rhalbersma@gmail.com
Date: Thu, 15 Oct 2015 14:26:03 -0700 (PDT)
Raw View
------=_Part_0_301827579.1444944363839
Content-Type: multipart/alternative;
boundary="----=_Part_1_19625765.1444944363845"
------=_Part_1_19625765.1444944363845
Content-Type: text/plain; charset=UTF-8
On Wednesday, October 14, 2015 at 11:34:31 PM UTC+2, Myriachan wrote:
>
> This sentence doesn't feel correct:
>
> However, the above might entail undefined behavior (with no diagnostic
>> required!) whenever v.size() is beyond the range of an unsigned (e.g.
>> more than 2^32 elements on most 64-bit systems) since then the loop
>> variable i will wrap-around, never actually reaching the bound.
>>
>
> This isn't undefined behavior. i will wrap, which is defined behavior
> with unsigned integer types. You'll then be accessing the beginning of the
> vector again, which is defined behavior. An infinite loop here is a bug,
> but it's a well-defined infinite loop.
>
Thank you, that's indeed a (silent and quite nasty) bug, not a UB.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1_19625765.1444944363845
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br>On Wednesday, October 14, 2015 at 11:34:31 PM UTC+2, Myriachan wrote:<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">This sentence d=
oesn't feel correct:<br><br><blockquote style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_=
quote"> However, the above might entail undefined behavior (with no diagnos=
tic required!) whenever <code>v.size()</code> is beyond the range of an <co=
de>unsigned</code> (e.g. more than <code>2^32</code> elements on most 64-bi=
t systems) since then the loop variable <code>i</code> will wrap-around, ne=
ver actually reaching the bound.<br></blockquote><br>This isn't undefin=
ed behavior.=C2=A0 <span style=3D"font-family:courier new,monospace">i</spa=
n> will wrap, which is defined behavior with unsigned integer types.=C2=A0 =
You'll then be accessing the beginning of the vector again, which is de=
fined behavior.=C2=A0 An infinite loop here is a bug, but it's a well-d=
efined infinite loop.</div></blockquote><div><br></div><div>Thank you, that=
's indeed a (silent and quite nasty) bug, not a UB. =C2=A0</div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1_19625765.1444944363845--
------=_Part_0_301827579.1444944363839--
.
Author: rhalbersma@gmail.com
Date: Thu, 15 Oct 2015 14:34:32 -0700 (PDT)
Raw View
------=_Part_4_1637771636.1444944872567
Content-Type: multipart/alternative;
boundary="----=_Part_5_1359164360.1444944872567"
------=_Part_5_1359164360.1444944872567
Content-Type: text/plain; charset=UTF-8
On Thursday, October 15, 2015 at 10:43:22 AM UTC+2, Arthur O'Dwyer wrote:
>
> On Thu, Oct 15, 2015 at 12:53 AM, Moritz Klammler <moritz....@gmail.com
> <javascript:>> wrote:
>
>> > Moritz Klammler suggested the use-case
>> >
>> > for (auto i = 0z; i < v.size(); ++i)
>> > std::cout << "v[" << i << "] = " << v[i] << "\n";
>>
>> Well, actually, I've copied and pasted it from the proposal...
>>
>
> Oops. My mistake. :)
>
Actually, this was *not* copy-pasted from the proposal. There it reads in
Extended Example a)
for (auto i = 0z, s = v.size(); i < s; ++i)
and if v.size() gives a size_type other than size_t, the compiler will give
a loud and clear error because i and s have to be of equal type.
Only in part e) did I write
for (auto i = 0u; i < v.size(); ++i)
But that's with 0u, not 0z.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_5_1359164360.1444944872567
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, October 15, 2015 at 10:43:22 AM UTC+2, Arthur O'Dwyer wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Thu, Oct=
15, 2015 at 12:53 AM, Moritz Klammler <span dir=3D"ltr"><<a href=3D"jav=
ascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"aweHs3TUDgAJ" rel=3D"n=
ofollow" onmousedown=3D"this.href=3D'javascript:';return true;" onc=
lick=3D"this.href=3D'javascript:';return true;">moritz....@gmail.co=
m</a>></span> wrote:<br><div><div class=3D"gmail_quote"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">> Moritz Klammler suggested the use-case<br>
><br>
>=C2=A0 =C2=A0 =C2=A0for (auto i =3D 0z; i < v.size(); ++i)<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::cout << "v[" <=
;< i << "] =3D " << v[i] << "\n";<=
br>
<br>
Well, actually, I've copied and pasted it from the proposal...<br></blo=
ckquote><div><br></div><div>Oops. My mistake. :)</div></div></div></div></b=
lockquote><div><br></div><div>Actually, this was *not* copy-pasted from the=
proposal. There it reads in Extended Example a)</div><div><br></div><div><=
span style=3D"color: rgb(0, 0, 0);">for (auto i =3D 0z, s =3D v.size(); i &=
lt; s; ++i)=C2=A0</span></div><div><br></div><div>and if v.size() gives a s=
ize_type other than size_t, the compiler will give a loud and clear error b=
ecause i and s have to be of equal type.</div><div><br></div><div>Only in p=
art e) did I write=C2=A0</div><div><br></div><div><pre style=3D"color: rgb(=
0, 0, 0);"><code>for (auto i =3D 0u; i < v.size(); ++i)</code></pre><pre=
style=3D"color: rgb(0, 0, 0);"><code><br></code></pre><pre><font face=3D"A=
rial, Helvetica, sans-serif"><span style=3D"white-space: normal;">But that&=
#39;s with 0u, not 0z.</span></font></pre></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_5_1359164360.1444944872567--
------=_Part_4_1637771636.1444944872567--
.
Author: rhalbersma@gmail.com
Date: Thu, 15 Oct 2015 14:41:07 -0700 (PDT)
Raw View
------=_Part_10_79260150.1444945267330
Content-Type: multipart/alternative;
boundary="----=_Part_11_79009312.1444945267330"
------=_Part_11_79009312.1444945267330
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, October 15, 2015 at 9:17:56 AM UTC+2, Arthur O'Dwyer wrote:
>
> I'll be at Kona (my first time going!), and I'm interested in this topic,=
=20
> but I wouldn't be a champion of this particular proposal. I have some=20
> hopefully-constructive comments, though:
>
Thanks for you indeed very constructive comments!=20
=20
> Therefore I would rather see some proposals on the subject of how to=20
> reconcile UDLs with built-in literal-suffixes =E2=80=94 how can we make t=
he two=20
> kinds behave more like the same kind of thing? There may be proposals=20
> already existing on the subject that I just don't know about.
> It would be an interesting experiment to take one of the core language=20
> suffixes =E2=80=94 say, "L" =E2=80=94 and reimplement it as a UDL. What w=
ould break if we=20
> do that? This experiment would give some insight into the things that wou=
ld=20
> break (or at least fail to work "as expected") if we add "z" as a UDL.
> Off the top of my head:
> - "0z" won't work in the preprocessor, even though "0ull" does.
> - "0z" won't work unless you #include <cstddef> and then using namespace=
=20
> std::literals::support_literals, which is a mouthful.
> - Due to the above, "0z" is basically unusable inside .h files=20
> <https://github.com/fmatthew5876/stdcxx-sv-literal/blob/master/proposal/d=
raft.md#why-not-user-defined-literals>=20
> (although modules might fix that?)
> - What else?
> - Can we patch any of the above issues so that it's not an issue anymore?
>
=20
Right, I hadn't really thought of the interaction with the preprocessor.=20
But I really didn't want to drag in all the builtin integral types, simply=
=20
because there are so many (also the _fast and _least version of uintX_t).
(4) Particularly because of the aforementioned
> > "0z" won't work unless you #include <cstddef> and then using namespace=
=20
> std::literals::support_literals, which is a mouthful.
> I'm just not seeing the cost-benefit ratio here. Sure it might be nice to=
=20
> write 0z, but I can already today write std::size_t(0), which is only a=
=20
> few more characters, and doesn't require me to write using namespace=20
> std::literals::support_literals everywhere in my code (nor even once at=
=20
> the top of every .cpp file).
>
Yes, this is a not so nice, but it's also the case for every other Standard=
=20
UDL (e.g. Chrono). In practice, I just place a using declaration at=20
function scope whenever I need a size_t literal. =20
Which brings me back to point #1: I think in the vast majority of cases=20
> where a C++ programmer *thinks* he needs a shorthand for std::size_t(0),=
=20
> he *really* needs something else entirely =E2=80=94 most likely, a range-=
based=20
> for loop.
>
Note that if you have a range, and want to do something other than 0-based=
=20
indexing (as in part b) of the Example), then UDL for size_t still comes in=
=20
handy.
=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_11_79009312.1444945267330
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, October 15, 2015 at 9:17:56 AM UTC+2, Arthur =
O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>I'l=
l be at Kona (my first time going!), and I'm interested in this topic, =
but I wouldn't be a champion of this particular proposal. I have some h=
opefully-constructive comments, though:</div></blockquote><div><br></div><d=
iv>Thanks for you indeed very constructive comments!=C2=A0</div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div></div><div>Therefor=
e I would rather see some proposals on the subject of how to reconcile UDLs=
with built-in literal-suffixes =E2=80=94 how can we make the two kinds beh=
ave more like the same kind of thing? =C2=A0There may be proposals already =
existing on the subject that I just don't know about.<br></div><div>It =
would be an interesting experiment to take one of the core language suffixe=
s =E2=80=94 say, "L" =E2=80=94 and reimplement it as a UDL. What =
would break if we do that? This experiment would give some insight into the=
things that would break (or at least fail to work "as expected")=
if we add "z" as a UDL.</div><div>Off the top of my head:</div><=
div>- "0z" won't work in the preprocessor, even though "=
0ull" does.</div><div>- "0z" won't work unless you <font=
face=3D"courier new, monospace">#include <cstddef></font> and then <=
font face=3D"courier new, monospace">using namespace std::literals::support=
_<wbr>literals</font>, which is a mouthful.</div><div>- Due to the above, &=
quot;0z" is <a href=3D"https://github.com/fmatthew5876/stdcxx-sv-liter=
al/blob/master/proposal/draft.md#why-not-user-defined-literals" target=3D"_=
blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://www.google.=
com/url?q\75https%3A%2F%2Fgithub.com%2Ffmatthew5876%2Fstdcxx-sv-literal%2Fb=
lob%2Fmaster%2Fproposal%2Fdraft.md%23why-not-user-defined-literals\46sa\75D=
\46sntz\0751\46usg\75AFQjCNGMWo1aScoa_nXFSQ4N5JHF5WQA4g';return true;" =
onclick=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgi=
thub.com%2Ffmatthew5876%2Fstdcxx-sv-literal%2Fblob%2Fmaster%2Fproposal%2Fdr=
aft.md%23why-not-user-defined-literals\46sa\75D\46sntz\0751\46usg\75AFQjCNG=
MWo1aScoa_nXFSQ4N5JHF5WQA4g';return true;">basically unusable inside .h=
files</a> (although modules might fix that?)</div><div>- What else?</div><=
div>- Can we patch any of the above issues so that it's not an issue an=
ymore?</div></blockquote><div>=C2=A0</div><div>Right, I hadn't really t=
hought of the interaction with the preprocessor. But I really didn't wa=
nt to drag in all the builtin integral types, simply because there are so m=
any (also the _fast and _least version of uintX_t).</div><div><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div></div><div>(4) Particularly =
because of the aforementioned</div><div><div>> "0z" won't =
work unless you #include <cstddef> and then using namespace std::lite=
rals::support_<wbr>literals, which is a mouthful.</div></div><div>I'm j=
ust not seeing the cost-benefit ratio here. Sure it might be nice to write =
<font face=3D"courier new, monospace">0z</font>, but I can already today wr=
ite <font face=3D"courier new, monospace">std::size_t(0)</font>, which is o=
nly a few more characters, and doesn't require me to write <font face=
=3D"courier new, monospace">using namespace std::literals::support_<wbr>lit=
erals</font> everywhere in my code (nor even once at the top of every .cpp =
file).</div></blockquote><div><br></div><div>Yes, this is a not so nice, bu=
t it's also the case for every other Standard UDL (e.g. Chrono). In pra=
ctice, I just place a using declaration at function scope whenever I need a=
size_t literal. =C2=A0</div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div>Which brings me back to point #1: I think in the vast ma=
jority of cases where a C++ programmer <i>thinks</i> he needs a shorthand f=
or=C2=A0<font face=3D"courier new, monospace">std::size_t(0)</font>, he <i>=
really</i> needs something else entirely =E2=80=94 most likely, a range-bas=
ed for loop.</div></blockquote><div><br></div><div>Note that if you have a =
range, and want to do something other than 0-based indexing (as in part b) =
of the Example), then UDL for size_t still comes in handy.</div><div>=C2=A0=
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_11_79009312.1444945267330--
------=_Part_10_79260150.1444945267330--
.
Author: rhalbersma@gmail.com
Date: Thu, 15 Oct 2015 14:44:44 -0700 (PDT)
Raw View
------=_Part_6_1955536492.1444945484512
Content-Type: multipart/alternative;
boundary="----=_Part_7_852978834.1444945484513"
------=_Part_7_852978834.1444945484513
Content-Type: text/plain; charset=UTF-8
On Thursday, October 15, 2015 at 1:39:39 AM UTC+2, Moritz Klammler wrote:
>
> I think this is an awesome proposal. Very simple but highly useful.
>
Thank you!
> I cannot offer a champion but I'd like to supply two more arguments for
> your proposal.
>
> Here, your proposal really shines.
>
> auto s2 = make_example([](){}, 0z);
>
Yes, in such places it really adds brevity. I found it useful in my own
code as well, after the initial publication of this proposal. I might
incorporate an example like this into an updated version.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_7_852978834.1444945484513
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, October 15, 2015 at 1:39:39 AM UTC+2, Moritz =
Klammler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I think this is=
an awesome proposal. =C2=A0Very simple but highly useful.
<br></blockquote><div><br></div><div>Thank you!=C2=A0</div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">I cannot offer a champion but=
I'd like to supply two more arguments for
<br>your proposal.
<br><br>=C2=A0 =C2=A0 Here, your proposal really shines.
<br>
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto s2 =3D make_example([](){}, 0z);
<br></blockquote><div><br></div><div>Yes, in such places it really adds bre=
vity. I found it useful in my own code as well, after the initial publicati=
on of this proposal. I might incorporate an example like this into an updat=
ed version.=C2=A0</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_7_852978834.1444945484513--
------=_Part_6_1955536492.1444945484512--
.