Topic: namespace-qualified used defined literals?
Author: Roland Bock <rbock@eudoxos.de>
Date: Tue, 16 Jun 2015 07:38:07 +0200
Raw View
Hi,
Is there any way to use a user defined literal without importing it into
the current namespace? If not, is there a proposal to do so?
I tried the following unsuccessfully with g++-5.0 -std=c++1z
#include <string>
auto hello = "hello"s; //of course not
auto world = "world"std::literals::string_literals::operator""s;
auto any = "any"(std::literals::string_literals::operator""s);
auto ideas = std::literals::string_literals::operator""s("ideas?");
int main() {}
Best,
Roland
--
---
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: "T. C." <rs2740@gmail.com>
Date: Mon, 15 Jun 2015 23:29:39 -0700 (PDT)
Raw View
------=_Part_1460_460261383.1434436179380
Content-Type: multipart/alternative;
boundary="----=_Part_1461_376967587.1434436179381"
------=_Part_1461_376967587.1434436179381
Content-Type: text/plain; charset=UTF-8
Doesn't explicitly qualifying the name defeat the whole point of
user-defined literals in the first place?
Anyway, operator""s() is a function that takes two arguments; the second
argument is the length of the string (not counting the terminating null),
so:
auto ideas = std::literals::string_literals::operator""s("ideas?",
sizeof("ideas?") - 1);
Since literals and string_literals are inline namespaces, this can be
simplified to
auto ideas = std::operator""s("ideas?", sizeof("ideas?") - 1);
But, again, what's the point?
On Tuesday, June 16, 2015 at 1:38:10 AM UTC-4, Roland Bock wrote:
>
> Hi,
>
> Is there any way to use a user defined literal without importing it into
> the current namespace? If not, is there a proposal to do so?
>
> I tried the following unsuccessfully with g++-5.0 -std=c++1z
>
>
> #include <string>
>
> auto hello = "hello"s; //of course not
> auto world = "world"std::literals::string_literals::operator""s;
> auto any = "any"(std::literals::string_literals::operator""s);
> auto ideas = std::literals::string_literals::operator""s("ideas?");
>
> int main() {}
>
>
> Best,
>
> Roland
>
--
---
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_1461_376967587.1434436179381
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Doesn't explicitly qualifying the name defeat the whole po=
int of user-defined literals in the first place?<div><br></div><div>Anyway,=
operator""s() is a function that takes two arguments; the second argument =
is the length of the string (not counting the terminating null), so:</div><=
div><br></div><div>auto ideas =3D std::literals::string_<wbr>literals::oper=
ator""s("ideas?", sizeof("ideas?") - 1); </div><div><br></div><div>Sin=
ce literals and string_literals are inline namespaces, this can be simplifi=
ed to </div><div><br></div><div>auto ideas =3D std::operator""s("ideas=
?", sizeof("ideas?") - 1); <br></div><div><br></div><div>But, again, w=
hat's the point?</div><div><div><br>On Tuesday, June 16, 2015 at 1:38:10 AM=
UTC-4, Roland Bock wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi,
<br>
<br>Is there any way to use a user defined literal without importing it int=
o
<br>the current namespace? If not, is there a proposal to do so?
<br>
<br>I tried the following unsuccessfully with g++-5.0 -std=3Dc++1z
<br>
<br>
<br>#include <string>
<br>
<br>auto hello =3D "hello"s; //of course not
<br>auto world =3D "world"std::literals::string_<wbr>literals::operator""s;
<br>auto any =3D "any"(std::literals::string_<wbr>literals::operator""s);
<br>auto ideas =3D std::literals::string_<wbr>literals::operator""s("ideas?=
"<wbr>);
<br>
<br>int main() {}
<br>
<br>
<br>Best,
<br>
<br>Roland
<br></blockquote></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_1461_376967587.1434436179381--
------=_Part_1460_460261383.1434436179380--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Tue, 16 Jun 2015 10:12:34 +0200
Raw View
This is a multi-part message in MIME format.
--------------080703030102010509000602
Content-Type: text/plain; charset=UTF-8
Boost::Hana provides a user-defined literal that I would like to use to
define a compile time string in a header.
See
http://ldionne.com/hana/structboost_1_1hana_1_1String.html#ad77f7afff008c2ce15739ad16a8bf0a8
I would really like to say
struct A
{
using name_t = decltype("sample"_s);
};
But _s is not in my namespace, so I would like to qualify it (using
namespace is not an option here).
And I would prefer not to provide the sizeof, which would require me to
write "sample" twice.
On 2015-06-16 08:29, T. C. wrote:
> Doesn't explicitly qualifying the name defeat the whole point of
> user-defined literals in the first place?
>
> Anyway, operator""s() is a function that takes two arguments; the
> second argument is the length of the string (not counting the
> terminating null), so:
>
> auto ideas = std::literals::string_literals::operator""s("ideas?",
> sizeof("ideas?") - 1);
>
> Since literals and string_literals are inline namespaces, this can be
> simplified to
>
> auto ideas = std::operator""s("ideas?", sizeof("ideas?") - 1);
>
> But, again, what's the point?
>
> On Tuesday, June 16, 2015 at 1:38:10 AM UTC-4, Roland Bock wrote:
>
> Hi,
>
> Is there any way to use a user defined literal without importing
> it into
> the current namespace? If not, is there a proposal to do so?
>
> I tried the following unsuccessfully with g++-5.0 -std=c++1z
>
>
> #include <string>
>
> auto hello = "hello"s; //of course not
> auto world = "world"std::literals::string_literals::operator""s;
> auto any = "any"(std::literals::string_literals::operator""s);
> auto ideas = std::literals::string_literals::operator""s("ideas?");
>
> int main() {}
>
>
> Best,
>
> Roland
>
> --
>
> ---
> 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
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--
---
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/.
--------------080703030102010509000602
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">Boost::Hana provides a user-defined
literal that I would like to use to define a compile time string
in a header.<br>
<br>
See
<a class=3D"moz-txt-link-freetext" href=3D"http://ldionne.com/hana/structbo=
ost_1_1hana_1_1String.html#ad77f7afff008c2ce15739ad16a8bf0a8">http://ldionn=
e.com/hana/structboost_1_1hana_1_1String.html#ad77f7afff008c2ce15739ad16a8b=
f0a8</a><br>
<br>
I would really like to say <br>
<br>
struct A<br>
{<br>
=C2=A0=C2=A0 using name_t =3D decltype("sample"_s);<br>
};<br>
<br>
But _s is not in my namespace, so I would like to qualify it
(using namespace is not an option here).<br>
And I would prefer not to provide the sizeof, which would require
me to write "sample" twice.<br>
<br>
<br>
On 2015-06-16 08:29, T. C. wrote:<br>
</div>
<blockquote
cite=3D"mid:d2c1d5b0-49b1-48b2-bceb-6c753d514e78@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">Doesn't explicitly qualifying the name defeat the
whole point of user-defined literals in the first place?
<div><br>
</div>
<div>Anyway, operator""s() is a function that takes two
arguments; the second argument is the length of the string
(not counting the terminating null), so:</div>
<div><br>
</div>
<div>auto ideas =3D std::literals::string_<wbr>literals::operator""=
s("ideas?",
sizeof("ideas?") - 1);=C2=A0</div>
<div><br>
</div>
<div>Since literals and string_literals are inline namespaces,
this can be simplified to=C2=A0</div>
<div><br>
</div>
<div>auto ideas =3D std::operator""s("ideas?", sizeof("ideas?") -
1);=C2=A0<br>
</div>
<div><br>
</div>
<div>But, again, what's the point?</div>
<div>
<div><br>
On Tuesday, June 16, 2015 at 1:38:10 AM UTC-4, Roland Bock
wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:
0;margin-left: 0.8ex;border-left: 1px #ccc
solid;padding-left: 1ex;">Hi,
<br>
<br>
Is there any way to use a user defined literal without
importing it into
<br>
the current namespace? If not, is there a proposal to do
so?
<br>
<br>
I tried the following unsuccessfully with g++-5.0
-std=3Dc++1z
<br>
<br>
<br>
#include <string>
<br>
<br>
auto hello =3D "hello"s; //of course not
<br>
auto world =3D "world"std::literals::string_<wbr>literals::op=
erator""s;
<br>
auto any =3D "any"(std::literals::string_<wbr>literals::opera=
tor""s);
<br>
auto ideas =3D std::literals::string_<wbr>literals::operator"=
"s("ideas?"<wbr>);
<br>
<br>
int main() {}
<br>
<br>
<br>
Best,
<br>
<br>
Roland
<br>
</blockquote>
</div>
</div>
</div>
-- <br>
<br>
--- <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 email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--------------080703030102010509000602--
.
Author: "T. C." <rs2740@gmail.com>
Date: Tue, 16 Jun 2015 07:21:09 -0700 (PDT)
Raw View
------=_Part_4841_2054326925.1434464469128
Content-Type: multipart/alternative;
boundary="----=_Part_4842_1978035656.1434464469128"
------=_Part_4842_1978035656.1434464469128
Content-Type: text/plain; charset=UTF-8
Hana's operator""_s is actually a template (which depends on a compiler
extension).
So it'd actually be operator""_s<char, 's', 'a', 'm', 'p', 'l', 'e'>().
That's arguably even worse.
On Tuesday, June 16, 2015 at 4:12:36 AM UTC-4, Roland Bock wrote:
>
> Boost::Hana provides a user-defined literal that I would like to use to
> define a compile time string in a header.
>
> See
> http://ldionne.com/hana/structboost_1_1hana_1_1String.html#ad77f7afff008c2ce15739ad16a8bf0a8
>
> I would really like to say
>
> struct A
> {
> using name_t = decltype("sample"_s);
> };
>
> But _s is not in my namespace, so I would like to qualify it (using
> namespace is not an option here).
> And I would prefer not to provide the sizeof, which would require me to
> write "sample" twice.
>
>
> On 2015-06-16 08:29, T. C. wrote:
>
> Doesn't explicitly qualifying the name defeat the whole point of
> user-defined literals in the first place?
>
> Anyway, operator""s() is a function that takes two arguments; the second
> argument is the length of the string (not counting the terminating null),
> so:
>
> auto ideas = std::literals::string_literals::operator""s("ideas?",
> sizeof("ideas?") - 1);
>
> Since literals and string_literals are inline namespaces, this can be
> simplified to
>
> auto ideas = std::operator""s("ideas?", sizeof("ideas?") - 1);
>
> But, again, what's the point?
>
> On Tuesday, June 16, 2015 at 1:38:10 AM UTC-4, Roland Bock wrote:
>>
>> Hi,
>>
>> Is there any way to use a user defined literal without importing it into
>> the current namespace? If not, is there a proposal to do so?
>>
>> I tried the following unsuccessfully with g++-5.0 -std=c++1z
>>
>>
>> #include <string>
>>
>> auto hello = "hello"s; //of course not
>> auto world = "world"std::literals::string_literals::operator""s;
>> auto any = "any"(std::literals::string_literals::operator""s);
>> auto ideas = std::literals::string_literals::operator""s("ideas?");
>>
>> int main() {}
>>
>>
>> Best,
>>
>> Roland
>>
> --
>
> ---
> 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-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
>
--
---
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_4842_1978035656.1434464469128
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hana's operator""_s is actually a template (which depends =
on a compiler extension).<div><br></div><div>So it'd actually be operator""=
_s<char, 's', 'a', 'm', 'p', 'l', 'e'>().</div><div><br></div><div>Th=
at's arguably even worse.<br><div><div><div><br>On Tuesday, June 16, 2015 a=
t 4:12:36 AM UTC-4, Roland Bock wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>Boost::Hana provides a user-defined
literal that I would like to use to define a compile time string
in a header.<br>
<br>
See
<a href=3D"http://ldionne.com/hana/structboost_1_1hana_1_1String.html#ad77f=
7afff008c2ce15739ad16a8bf0a8" target=3D"_blank" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fldionne.com%2F=
hana%2Fstructboost_1_1hana_1_1String.html%23ad77f7afff008c2ce15739ad16a8bf0=
a8\46sa\75D\46sntz\0751\46usg\75AFQjCNHDkIzQ9evLICl3UR5amXZWF5U79A';return =
true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fl=
dionne.com%2Fhana%2Fstructboost_1_1hana_1_1String.html%23ad77f7afff008c2ce1=
5739ad16a8bf0a8\46sa\75D\46sntz\0751\46usg\75AFQjCNHDkIzQ9evLICl3UR5amXZWF5=
U79A';return true;">http://ldionne.com/hana/<wbr>structboost_1_1hana_1_1Str=
ing.<wbr>html#<wbr>ad77f7afff008c2ce15739ad16a8bf<wbr>0a8</a><br>
<br>
I would really like to say <br>
<br>
struct A<br>
{<br>
using name_t =3D decltype("sample"_s);<br>
};<br>
<br>
But _s is not in my namespace, so I would like to qualify it
(using namespace is not an option here).<br>
And I would prefer not to provide the sizeof, which would require
me to write "sample" twice.<br>
<br>
<br>
On 2015-06-16 08:29, T. C. wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">Doesn't explicitly qualifying the name defeat the
whole point of user-defined literals in the first place?
<div><br>
</div>
<div>Anyway, operator""s() is a function that takes two
arguments; the second argument is the length of the string
(not counting the terminating null), so:</div>
<div><br>
</div>
<div>auto ideas =3D std::literals::string_<wbr>literals::operator""=
s("ideas?"<wbr>,
sizeof("ideas?") - 1); </div>
<div><br>
</div>
<div>Since literals and string_literals are inline namespaces,
this can be simplified to </div>
<div><br>
</div>
<div>auto ideas =3D std::operator""s("ideas?", sizeof("ideas?") -
1); <br>
</div>
<div><br>
</div>
<div>But, again, what's the point?</div>
<div>
<div><br>
On Tuesday, June 16, 2015 at 1:38:10 AM UTC-4, Roland Bock
wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,
<br>
<br>
Is there any way to use a user defined literal without
importing it into
<br>
the current namespace? If not, is there a proposal to do
so?
<br>
<br>
I tried the following unsuccessfully with g++-5.0
-std=3Dc++1z
<br>
<br>
<br>
#include <string>
<br>
<br>
auto hello =3D "hello"s; //of course not
<br>
auto world =3D "world"std::literals::string_<wbr>literals::op=
erator""s;
<br>
auto any =3D "any"(std::literals::string_<wbr>literals::opera=
tor""s);
<br>
auto ideas =3D std::literals::string_<wbr>literals::operator"=
"s("ideas?"<wbr>);
<br>
<br>
int main() {}
<br>
<br>
<br>
Best,
<br>
<br>
Roland
<br>
</blockquote>
</div>
</div>
</div>
-- <br>
<br>
--- <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 email to <a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"DRjOvDdaSjoJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'j=
avascript:';return true;" onclick=3D"this.href=3D'javascript:';return true;=
">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"DRjOvDdaSjoJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'jav=
ascript:';return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/=
group/std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;" onclick=3D"this.href=3D'http://groups.google.com/a/isocpp.org/grou=
p/std-proposals/';return true;">http://groups.google.com/a/<wbr>isocpp.org/=
group/std-<wbr>proposals/</a>.<br>
</blockquote>
<br>
</div>
</blockquote></div></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 />
------=_Part_4842_1978035656.1434464469128--
------=_Part_4841_2054326925.1434464469128--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Tue, 16 Jun 2015 22:18:23 +0200
Raw View
This is a multi-part message in MIME format.
--------------060307050106000208030608
Content-Type: text/plain; charset=UTF-8
On 2015-06-16 16:21, T. C. wrote:
> Hana's operator""_s is actually a template (which depends on a
> compiler extension).
>
> So it'd actually be operator""_s<char, 's', 'a', 'm', 'p', 'l', 'e'>().
>
> That's arguably even worse.
Worse than what?
Yes, it depends on a compiler extension, one that may or may not become
part of the standard one fine day. Still, I'd be interested in using a
named literal (for instance this one) without the "using namespace".
After all, it is just a function (except that there is some magic that
adds the size argument).
> On Tuesday, June 16, 2015 at 4:12:36 AM UTC-4, Roland Bock wrote:
>
> Boost::Hana provides a user-defined literal that I would like to
> use to define a compile time string in a header.
>
> See
> http://ldionne.com/hana/structboost_1_1hana_1_1String.html#ad77f7afff008c2ce15739ad16a8bf0a8
> <http://ldionne.com/hana/structboost_1_1hana_1_1String.html#ad77f7afff008c2ce15739ad16a8bf0a8>
>
> I would really like to say
>
> struct A
> {
> using name_t = decltype("sample"_s);
> };
>
> But _s is not in my namespace, so I would like to qualify it
> (using namespace is not an option here).
> And I would prefer not to provide the sizeof, which would require
> me to write "sample" twice.
>
>
> On 2015-06-16 08:29, T. C. wrote:
>> Doesn't explicitly qualifying the name defeat the whole point of
>> user-defined literals in the first place?
>>
>> Anyway, operator""s() is a function that takes two arguments; the
>> second argument is the length of the string (not counting the
>> terminating null), so:
>>
>> auto ideas =
>> std::literals::string_literals::operator""s("ideas?",
>> sizeof("ideas?") - 1);
>>
>> Since literals and string_literals are inline namespaces, this
>> can be simplified to
>>
>> auto ideas = std::operator""s("ideas?", sizeof("ideas?") - 1);
>>
>> But, again, what's the point?
>>
>> On Tuesday, June 16, 2015 at 1:38:10 AM UTC-4, Roland Bock wrote:
>>
>> Hi,
>>
>> Is there any way to use a user defined literal without
>> importing it into
>> the current namespace? If not, is there a proposal to do so?
>>
>> I tried the following unsuccessfully with g++-5.0 -std=c++1z
>>
>>
>> #include <string>
>>
>> auto hello = "hello"s; //of course not
>> auto world = "world"std::literals::string_literals::operator""s;
>> auto any = "any"(std::literals::string_literals::operator""s);
>> auto ideas =
>> std::literals::string_literals::operator""s("ideas?");
>>
>> int main() {}
>>
>>
>> Best,
>>
>> Roland
>>
>> --
>>
>> ---
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org
>> <javascript:>.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/
>> <http://groups.google.com/a/isocpp.org/group/std-proposals/>.
>
> --
>
> ---
> 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
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--
---
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/.
--------------060307050106000208030608
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">On 2015-06-16 16:21, T. C. wrote:<br>
</div>
<blockquote
cite=3D"mid:3fef2372-dfa5-424c-8895-099dab9b98d3@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">Hana's operator""_s is actually a template (which
depends on a compiler extension).
<div><br>
</div>
<div>So it'd actually be operator""_s<char, 's', 'a', 'm',
'p', 'l', 'e'>().</div>
<div><br>
</div>
<div>That's arguably even worse.<br>
</div>
</div>
</blockquote>
Worse than what?<br>
<br>
Yes, it depends on a compiler extension, one that may or may not
become part of the standard one fine day. Still, I'd be interested
in using a named literal (for instance this one) without the "using
namespace". After all, it is just a function (except that there is
some magic that adds the size argument).<br>
<br>
<blockquote
cite=3D"mid:3fef2372-dfa5-424c-8895-099dab9b98d3@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>
<div>
<div>
<div>On Tuesday, June 16, 2015 at 4:12:36 AM UTC-4, Roland
Bock wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:
0;margin-left: 0.8ex;border-left: 1px #ccc
solid;padding-left: 1ex;">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>Boost::Hana provides a user-defined literal
that I would like to use to define a compile time
string in a header.<br>
<br>
See
<a moz-do-not-send=3D"true"
href=3D"http://ldionne.com/hana/structboost_1_1hana_1_1String.html#ad77f7af=
ff008c2ce15739ad16a8bf0a8"
target=3D"_blank" rel=3D"nofollow"
onmousedown=3D"this.href=3D'http://www.google.com/u=
rl?q\75http%3A%2F%2Fldionne.com%2Fhana%2Fstructboost_1_1hana_1_1String.html=
%23ad77f7afff008c2ce15739ad16a8bf0a8\46sa\75D\46sntz\0751\46usg\75AFQjCNHDk=
IzQ9evLICl3UR5amXZWF5U79A';return
true;"
onclick=3D"this.href=3D'http://www.google.com/url?q=
\75http%3A%2F%2Fldionne.com%2Fhana%2Fstructboost_1_1hana_1_1String.html%23a=
d77f7afff008c2ce15739ad16a8bf0a8\46sa\75D\46sntz\0751\46usg\75AFQjCNHDkIzQ9=
evLICl3UR5amXZWF5U79A';return
true;">http://ldionne.com/hana/<wbr>structboost_1_1=
hana_1_1String.<wbr>html#<wbr>ad77f7afff008c2ce15739ad16a8bf<wbr>0a8</a><br=
>
<br>
I would really like to say <br>
<br>
struct A<br>
{<br>
=C2=A0=C2=A0 using name_t =3D decltype("sample"_s);<b=
r>
};<br>
<br>
But _s is not in my namespace, so I would like to
qualify it (using namespace is not an option
here).<br>
And I would prefer not to provide the sizeof,
which would require me to write "sample" twice.<br>
<br>
<br>
On 2015-06-16 08:29, T. C. wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">Doesn't explicitly qualifying the
name defeat the whole point of user-defined
literals in the first place?
<div><br>
</div>
<div>Anyway, operator""s() is a function that
takes two arguments; the second argument is
the length of the string (not counting the
terminating null), so:</div>
<div><br>
</div>
<div>auto ideas =3D std::literals::string_<wbr>lite=
rals::operator""s("ideas?"<wbr>,
sizeof("ideas?") - 1);=C2=A0</div>
<div><br>
</div>
<div>Since literals and string_literals are
inline namespaces, this can be simplified to=C2=
=A0</div>
<div><br>
</div>
<div>auto ideas =3D std::operator""s("ideas?",
sizeof("ideas?") - 1);=C2=A0<br>
</div>
<div><br>
</div>
<div>But, again, what's the point?</div>
<div>
<div><br>
On Tuesday, June 16, 2015 at 1:38:10 AM
UTC-4, Roland Bock wrote:
<blockquote class=3D"gmail_quote"
style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px
#ccc solid;padding-left:1ex">Hi, <br>
<br>
Is there any way to use a user defined
literal without importing it into <br>
the current namespace? If not, is there a
proposal to do so? <br>
<br>
I tried the following unsuccessfully with
g++-5.0 -std=3Dc++1z <br>
<br>
<br>
#include <string> <br>
<br>
auto hello =3D "hello"s; //of course not <br>
auto world =3D "world"std::literals::string_<=
wbr>literals::operator""s;
<br>
auto any =3D "any"(std::literals::string_<wbr=
>literals::operator""s);
<br>
auto ideas =3D std::literals::string_<wbr>lit=
erals::operator""s("ideas?"<wbr>);
<br>
<br>
int main() {} <br>
<br>
<br>
Best, <br>
<br>
Roland <br>
</blockquote>
</div>
</div>
</div>
-- <br>
<br>
--- <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 email to <a
moz-do-not-send=3D"true" href=3D"javascript:"
target=3D"_blank"
gdf-obfuscated-mailto=3D"DRjOvDdaSjoJ"
rel=3D"nofollow"
onmousedown=3D"this.href=3D'javascript:';return
true;" onclick=3D"this.href=3D'javascript:';return
true;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a
moz-do-not-send=3D"true" href=3D"javascript:"
target=3D"_blank"
gdf-obfuscated-mailto=3D"DRjOvDdaSjoJ"
rel=3D"nofollow"
onmousedown=3D"this.href=3D'javascript:';return
true;" onclick=3D"this.href=3D'javascript:';return
true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group=
/std-proposals/"
target=3D"_blank" rel=3D"nofollow"
onmousedown=3D"this.href=3D'http://groups.google.co=
m/a/isocpp.org/group/std-proposals/';return
true;"
onclick=3D"this.href=3D'http://groups.google.com/a/=
isocpp.org/group/std-proposals/';return
true;">http://groups.google.com/a/<wbr>isocpp.org/g=
roup/std-<wbr>proposals/</a>.<br>
</blockquote>
<br>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
-- <br>
<br>
--- <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 email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--------------060307050106000208030608--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 16 Jun 2015 14:42:06 -0700
Raw View
--bcaec52d52dd23d7630518a97259
Content-Type: text/plain; charset=UTF-8
On Tue, Jun 16, 2015 at 1:12 AM, Roland Bock <rbock@eudoxos.de> wrote:
> Boost::Hana provides a user-defined literal that I would like to use to
> define a compile time string in a header.
>
> See
> http://ldionne.com/hana/structboost_1_1hana_1_1String.html#ad77f7afff008c2ce15739ad16a8bf0a8
>
> I would really like to say
>
> struct A
> {
> using name_t = decltype("sample"_s);
>
If we remove the (now-redundant) restriction on lambdas in unevaluated
operands, you could write:
using name_t = decltype([] -> decltype(auto) {
using namespace boost::hana;
return "sample"_s;
});
And in today's C++:
static decltype(auto) name() {
using namespace boost::hana;
return "sample"_s;
}
using name_t = decltype(name());
> };
>
> But _s is not in my namespace, so I would like to qualify it (using
> namespace is not an option here).
> And I would prefer not to provide the sizeof, which would require me to
> write "sample" twice.
>
>
>
> On 2015-06-16 08:29, T. C. wrote:
>
> Doesn't explicitly qualifying the name defeat the whole point of
> user-defined literals in the first place?
>
> Anyway, operator""s() is a function that takes two arguments; the second
> argument is the length of the string (not counting the terminating null),
> so:
>
> auto ideas = std::literals::string_literals::operator""s("ideas?",
> sizeof("ideas?") - 1);
>
> Since literals and string_literals are inline namespaces, this can be
> simplified to
>
> auto ideas = std::operator""s("ideas?", sizeof("ideas?") - 1);
>
> But, again, what's the point?
>
> On Tuesday, June 16, 2015 at 1:38:10 AM UTC-4, Roland Bock wrote:
>>
>> Hi,
>>
>> Is there any way to use a user defined literal without importing it into
>> the current namespace? If not, is there a proposal to do so?
>>
>> I tried the following unsuccessfully with g++-5.0 -std=c++1z
>>
>>
>> #include <string>
>>
>> auto hello = "hello"s; //of course not
>> auto world = "world"std::literals::string_literals::operator""s;
>> auto any = "any"(std::literals::string_literals::operator""s);
>> auto ideas = std::literals::string_literals::operator""s("ideas?");
>>
>> int main() {}
>>
>>
>> Best,
>>
>> Roland
>>
> --
>
> ---
> 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/.
>
>
> --
>
> ---
> 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/.
>
--
---
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/.
--bcaec52d52dd23d7630518a97259
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, Jun 16, 2015 at 1:12 AM, Roland Bock <span dir=3D"ltr"><<a href=3D"m=
ailto:rbock@eudoxos.de" target=3D"_blank">rbock@eudoxos.de</a>></span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>Boost::Hana provides a user-defined
literal that I would like to use to define a compile time string
in a header.<br>
<br>
See
<a href=3D"http://ldionne.com/hana/structboost_1_1hana_1_1String.html#ad77f=
7afff008c2ce15739ad16a8bf0a8" target=3D"_blank">http://ldionne.com/hana/str=
uctboost_1_1hana_1_1String.html#ad77f7afff008c2ce15739ad16a8bf0a8</a><br>
<br>
I would really like to say <br>
<br>
struct A<br>
{<br>
=C2=A0=C2=A0 using name_t =3D decltype("sample"_s);<br></di=
v></div></blockquote><div><br></div><div>If we remove the (now-redundant) r=
estriction on lambdas in unevaluated operands, you could write:</div><div><=
br></div><div>=C2=A0 using name_t =3D decltype([] -> decltype(auto) {</d=
iv><div>=C2=A0 =C2=A0 using namespace boost::hana;</div><div>=C2=A0 =C2=A0 =
return "sample"_s;</div><div>=C2=A0 });</div><div><br></div><div>=
And in today's C++:</div><div><br></div><div>=C2=A0 static decltype(aut=
o) name() {</div><div>=C2=A0 =C2=A0 using namespace boost::hana;</div><div>=
=C2=A0 =C2=A0 return "sample"_s;</div><div>=C2=A0 }</div><div>=C2=
=A0 using name_t =3D decltype(name());</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div text=3D"#000000" bgcolor=3D"#FFFFFF"><div>
};<br>
<br>
But _s is not in my namespace, so I would like to qualify it
(using namespace is not an option here).<br>
And I would prefer not to provide the sizeof, which would require
me to write "sample" twice.<div><div class=3D"h5"><br>
<br>
<br>
On 2015-06-16 08:29, T. C. wrote:<br>
</div></div></div><div><div class=3D"h5">
<blockquote type=3D"cite">
<div dir=3D"ltr">Doesn't explicitly qualifying the name defeat th=
e
whole point of user-defined literals in the first place?
<div><br>
</div>
<div>Anyway, operator""s() is a function that takes two
arguments; the second argument is the length of the string
(not counting the terminating null), so:</div>
<div><br>
</div>
<div>auto ideas =3D std::literals::string_literals::operator"&=
quot;s("ideas?",
sizeof("ideas?") - 1);=C2=A0</div>
<div><br>
</div>
<div>Since literals and string_literals are inline namespaces,
this can be simplified to=C2=A0</div>
<div><br>
</div>
<div>auto ideas =3D std::operator""s("ideas?", =
sizeof("ideas?") -
1);=C2=A0<br>
</div>
<div><br>
</div>
<div>But, again, what's the point?</div>
<div>
<div><br>
On Tuesday, June 16, 2015 at 1:38:10 AM UTC-4, Roland Bock
wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,
<br>
<br>
Is there any way to use a user defined literal without
importing it into
<br>
the current namespace? If not, is there a proposal to do
so?
<br>
<br>
I tried the following unsuccessfully with g++-5.0
-std=3Dc++1z
<br>
<br>
<br>
#include <string>
<br>
<br>
auto hello =3D "hello"s; //of course not
<br>
auto world =3D "world"std::literals::string_literal=
s::operator""s;
<br>
auto any =3D "any"(std::literals::string_literals::=
operator""s);
<br>
auto ideas =3D std::literals::string_literals::operator"=
"s("ideas?");
<br>
<br>
int main() {}
<br>
<br>
<br>
Best,
<br>
<br>
Roland
<br>
</blockquote>
</div>
</div>
</div>
-- <br>
<br>
--- <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 email to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.o=
rg" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/=
group/std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.o=
rg/group/std-proposals/</a>.<br>
</blockquote>
<br>
</div></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<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" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--bcaec52d52dd23d7630518a97259--
.
Author: Tomasz <tomaszkam@gmail.com>
Date: Tue, 16 Jun 2015 22:08:33 -0700 (PDT)
Raw View
------=_Part_5458_1913319852.1434517713401
Content-Type: multipart/alternative;
boundary="----=_Part_5459_746622386.1434517713401"
------=_Part_5459_746622386.1434517713401
Content-Type: text/plain; charset=UTF-8
>
> #include <string>
>
> auto hello = "hello"s; //of course not
> auto world = "world"std::literals::string_literals::operator""s;
> auto any = "any"(std::literals::string_literals::operator""s);
> auto ideas = std::literals::string_literals::operator""s("ideas?");
>
>
> As, the literals namespaces are inline, this could be simplified to use
std::opeator""s. However I think that better syntax would be to place the
qualification before literal itself, so we would get:
auto hello = "hello"s;
auto world = std::"world"s;
auto any = std::literals::string_literals::"any"s; //If you insist on
writing more
and
auto s = boost::hana::"sample"_s;
Having prefixed qualified literal would allow to remove the limittion to
use _ in user defined literals, because situation would now be same as for
any other entity.
--
---
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_5459_746622386.1434517713401
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>#incl=
ude <string>
<br>
<br>auto hello =3D "hello"s; //of course not
<br>auto world =3D "world"std::literals::string_<wbr>literals::operator""s;
<br>auto any =3D "any"(std::literals::string_<wbr>literals::operator""s);
<br>auto ideas =3D std::literals::string_<wbr>literals::operator""s("ideas?=
"<wbr>);
<br>
<br><br></blockquote><div>As, the literals namespaces are inline, this coul=
d be simplified to use std::opeator""s. However I think that better syntax =
would be to place the qualification before literal itself, so we would get:=
<br>auto hello =3D "hello"s;<br>auto world =3D std::"world"s;<br>auto any =
=3D std::literals::string_literals::"any"s; //If you insist on writing more=
<br>and<br>auto s =3D boost::hana::"sample"_s;<br><br>Having prefixed quali=
fied literal would allow to remove the limittion to use _ in user defined l=
iterals, because situation would now be same as for any other entity.<br></=
div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_5459_746622386.1434517713401--
------=_Part_5458_1913319852.1434517713401--
.
Author: Tomasz <tomaszkam@gmail.com>
Date: Tue, 16 Jun 2015 22:16:19 -0700 (PDT)
Raw View
------=_Part_4442_153171865.1434518179440
Content-Type: multipart/alternative;
boundary="----=_Part_4443_1674125949.1434518179440"
------=_Part_4443_1674125949.1434518179440
Content-Type: text/plain; charset=UTF-8
>
> But, again, what's the point?
>
> To no put arbitrarily restrictions on the suffix name and allow multiple
libraries providing same suffixes to be used in single program, which is
the thing we use namespace for. For example if I have std::string and
mylib::string, then both libraries would be allowed to provide s literal
and I would use std::"ala"s to get std::string and mylib::"ala"s to get
mylib::string.
--
---
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_4443_1674125949.1434518179440
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div></div><div>But, again, what's the point?</div><br></div></blockquo=
te><div>To no put arbitrarily restrictions on the suffix name and allow mul=
tiple libraries providing same suffixes to be used in single program, which=
is the thing we use namespace for. For example if I have std::string and m=
ylib::string, then both libraries would be allowed to provide s literal and=
I would use std::"ala"s to get std::string and mylib::"ala"s to get mylib:=
:string.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_4443_1674125949.1434518179440--
------=_Part_4442_153171865.1434518179440--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Wed, 17 Jun 2015 09:05:03 +0200
Raw View
This is a multi-part message in MIME format.
--------------070200020001050901090601
Content-Type: text/plain; charset=UTF-8
On 2015-06-17 07:08, Tomasz wrote:
>
>
> #include <string>
>
> auto hello = "hello"s; //of course not
> auto world = "world"std::literals::string_literals::operator""s;
> auto any = "any"(std::literals::string_literals::operator""s);
> auto ideas = std::literals::string_literals::operator""s("ideas?");
>
>
> As, the literals namespaces are inline, this could be simplified to
> use std::opeator""s. However I think that better syntax would be to
> place the qualification before literal itself, so we would get:
> auto hello = "hello"s;
> auto world = std::"world"s;
> auto any = std::literals::string_literals::"any"s; //If you insist on
> writing more
> and
> auto s = boost::hana::"sample"_s;
>
I would like that very much indeed!
Thus, we could have something like this in a header (without using
namespace):
struct A
{
static auto hello = std::"world"s; // std::string
static constexpr auto minute = std::60s; // std::chrono::duration
static constexpr auto hana = boost::hana::"sample"s; //
boost::hana::string
};
That would be quite helpful indeed!
>
> Having prefixed qualified literal would allow to remove the limittion
> to use _ in user defined literals, because situation would now be same
> as for any other entity.
+1
Thanks and regards,
Roland
--
---
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/.
--------------070200020001050901090601
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">On 2015-06-17 07:08, Tomasz wrote:<br>
</div>
<blockquote
cite=3D"mid:eaa7a034-bf06-48ab-9852-5d727048a90c@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>
#include <string>
<br>
<br>
auto hello =3D "hello"s; //of course not
<br>
auto world =3D "world"std::literals::string_<wbr>literals::operat=
or""s;
<br>
auto any =3D "any"(std::literals::string_<wbr>literals::operator"=
"s);
<br>
auto ideas =3D std::literals::string_<wbr>literals::operator""s("=
ideas?"<wbr>);
<br>
<br>
<br>
</blockquote>
<div>As, the literals namespaces are inline, this could be
simplified to use std::opeator""s. However I think that better
syntax would be to place the qualification before literal
itself, so we would get:<br>
auto hello =3D "hello"s;<br>
auto world =3D std::"world"s;<br>
auto any =3D std::literals::string_literals::"any"s; //If you
insist on writing more<br>
and<br>
auto s =3D boost::hana::"sample"_s;<br>
<br>
</div>
</div>
</blockquote>
I would like that very much indeed!<br>
<br>
Thus, we could have something like this in a header (without using
namespace):<br>
<br>
struct A<br>
{<br>
=C2=A0=C2=A0 static auto hello =3D std::"world"s; // std::string<br>
=C2=A0=C2=A0 static constexpr auto minute =3D std::60s;=C2=A0=C2=A0=C2=
=A0=C2=A0 //
std::chrono::duration<br>
=C2=A0=C2=A0 static constexpr auto hana =3D boost::hana::"sample"s; //
boost::hana::string<br>
};<br>
<br>
That would be quite helpful indeed!<br>
<br>
<blockquote
cite=3D"mid:eaa7a034-bf06-48ab-9852-5d727048a90c@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div><br>
Having prefixed qualified literal would allow to remove the
limittion to use _ in user defined literals, because situation
would now be same as for any other entity.<br>
</div>
</div>
</blockquote>
+1<br>
<br>
<br>
Thanks and regards,<br>
<br>
Roland<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--------------070200020001050901090601--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Wed, 17 Jun 2015 09:19:25 +0200
Raw View
This is a multi-part message in MIME format.
--------------000908070300050207000902
Content-Type: text/plain; charset=UTF-8
On 2015-06-16 23:42, Richard Smith wrote:
> On Tue, Jun 16, 2015 at 1:12 AM, Roland Bock <rbock@eudoxos.de
> <mailto:rbock@eudoxos.de>> wrote:
>
> Boost::Hana provides a user-defined literal that I would like to
> use to define a compile time string in a header.
>
> See
> http://ldionne.com/hana/structboost_1_1hana_1_1String.html#ad77f7afff008c2ce15739ad16a8bf0a8
>
> I would really like to say
>
> struct A
> {
> using name_t = decltype("sample"_s);
>
>
> If we remove the (now-redundant) restriction on lambdas in unevaluated
> operands, you could write:
Are there plans/proposals to do that? I stumbled over this restriction
quite a few times.
>
> using name_t = decltype([] -> decltype(auto) {
> using namespace boost::hana;
> return "sample"_s;
> });
>
> And in today's C++:
>
> static decltype(auto) name() {
> using namespace boost::hana;
> return "sample"_s;
> }
> using name_t = decltype(name());
Right, these are possible. But one of the basic ideas of UDLs seems to
be brevity. I was hoping for something shorter, more expressive than I
have now [1]:
struct alias_t
{
static constexpr const char _literal[] = "delta";
using name_t = sqlpp::make_char_sequence<sizeof(_literal), _literal>;
};
I therefore like Tomasz' suggestion very much:
struct alias_t
{
using name_t = decltype(::boost::hana::"delta"s);
};
Short and expressive :-)
Best,
Roland
[1] https://github.com/rbock/sqlpp11/blob/master/tests/Sample.h#L14-L17
>
>
> };
>
> But _s is not in my namespace, so I would like to qualify it
> (using namespace is not an option here).
> And I would prefer not to provide the sizeof, which would require
> me to write "sample" twice.
>
>
>
> On 2015-06-16 08:29, T. C. wrote:
>> Doesn't explicitly qualifying the name defeat the whole point of
>> user-defined literals in the first place?
>>
>> Anyway, operator""s() is a function that takes two arguments; the
>> second argument is the length of the string (not counting the
>> terminating null), so:
>>
>> auto ideas =
>> std::literals::string_literals::operator""s("ideas?",
>> sizeof("ideas?") - 1);
>>
>> Since literals and string_literals are inline namespaces, this
>> can be simplified to
>>
>> auto ideas = std::operator""s("ideas?", sizeof("ideas?") - 1);
>>
>> But, again, what's the point?
>>
>> On Tuesday, June 16, 2015 at 1:38:10 AM UTC-4, Roland Bock wrote:
>>
>> Hi,
>>
>> Is there any way to use a user defined literal without
>> importing it into
>> the current namespace? If not, is there a proposal to do so?
>>
>> I tried the following unsuccessfully with g++-5.0 -std=c++1z
>>
>>
>> #include <string>
>>
>> auto hello = "hello"s; //of course not
>> auto world = "world"std::literals::string_literals::operator""s;
>> auto any = "any"(std::literals::string_literals::operator""s);
>> auto ideas =
>> std::literals::string_literals::operator""s("ideas?");
>>
>> int main() {}
>>
>>
>> Best,
>>
>> Roland
>>
>> --
>>
>> ---
>> 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
>> <mailto:std-proposals+unsubscribe@isocpp.org>.
>> To post to this group, send email to std-proposals@isocpp.org
>> <mailto:std-proposals@isocpp.org>.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --
>
> ---
> 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
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
> --
>
> ---
> 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
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--
---
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/.
--------------000908070300050207000902
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">On 2015-06-16 23:42, Richard Smith
wrote:<br>
</div>
<blockquote
cite=3D"mid:CAOfiQqn07HG1Wv5+UW2vNgDNRhb7fguu26JbVH0Vj=3DXLuz5wJQ@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Tue, Jun 16, 2015 at 1:12 AM,
Roland Bock <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:rbock@eudoxos.de" target=3D"_blank">rbock@eu=
doxos.de</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 text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>Boost::Hana provides a user-defined literal that I
would like to use to define a compile time string in a
header.<br>
<br>
See
<a moz-do-not-send=3D"true"
href=3D"http://ldionne.com/hana/structboost_1_1hana_1_1String.html#ad77f7af=
ff008c2ce15739ad16a8bf0a8"
target=3D"_blank">http://ldionne.com/hana/structboost_1=
_1hana_1_1String.html#ad77f7afff008c2ce15739ad16a8bf0a8</a><br>
<br>
I would really like to say <br>
<br>
struct A<br>
{<br>
=C2=A0=C2=A0 using name_t =3D decltype("sample"_s);<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>If we remove the (now-redundant) restriction on lambdas
in unevaluated operands, you could write:</div>
</div>
</div>
</div>
</blockquote>
Are there plans/proposals to do that? I stumbled over this
restriction quite a few times.<br>
<br>
<blockquote
cite=3D"mid:CAOfiQqn07HG1Wv5+UW2vNgDNRhb7fguu26JbVH0Vj=3DXLuz5wJQ@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div><br>
</div>
<div>=C2=A0 using name_t =3D decltype([] -> decltype(auto) {=
</div>
<div>=C2=A0 =C2=A0 using namespace boost::hana;</div>
<div>=C2=A0 =C2=A0 return "sample"_s;</div>
<div>=C2=A0 });</div>
<div><br>
</div>
<div>And in today's C++:</div>
<div><br>
</div>
<div>=C2=A0 static decltype(auto) name() {</div>
<div>=C2=A0 =C2=A0 using namespace boost::hana;</div>
<div>=C2=A0 =C2=A0 return "sample"_s;</div>
<div>=C2=A0 }</div>
<div>=C2=A0 using name_t =3D decltype(name());</div>
</div>
</div>
</div>
</blockquote>
<br>
Right, these are possible. But one of the basic ideas of UDLs seems
to be brevity. I was hoping for something shorter, more expressive
than I have now [1]:<br>
<br>
<pre wrap=3D"">struct alias_t
{
static constexpr const char _literal[] =3D "delta";
using name_t =3D sqlpp::make_char_sequence<sizeof(_literal), _literal&=
gt;;
};</pre>
<br>
I therefore like Tomasz' suggestion very much:<br>
<br>
<pre wrap=3D"">struct alias_t
{
using name_t =3D decltype(::boost::hana::"delta"s);
};</pre>
<br>
Short and expressive :-)<br>
<br>
Best,<br>
<br>
Roland<br>
<br>
<br>
[1]
<a class=3D"moz-txt-link-freetext" href=3D"https://github.com/rbock/sql=
pp11/blob/master/tests/Sample.h#L14-L17">https://github.com/rbock/sqlpp11/b=
lob/master/tests/Sample.h#L14-L17</a><br>
<br>
<blockquote
cite=3D"mid:CAOfiQqn07HG1Wv5+UW2vNgDNRhb7fguu26JbVH0Vj=3DXLuz5wJQ@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div> };<br>
<br>
But _s is not in my namespace, so I would like to
qualify it (using namespace is not an option here).<br>
And I would prefer not to provide the sizeof, which
would require me to write "sample" twice.
<div>
<div class=3D"h5"><br>
<br>
<br>
On 2015-06-16 08:29, T. C. wrote:<br>
</div>
</div>
</div>
<div>
<div class=3D"h5">
<blockquote type=3D"cite">
<div dir=3D"ltr">Doesn't explicitly qualifying the
name defeat the whole point of user-defined
literals in the first place?
<div><br>
</div>
<div>Anyway, operator""s() is a function that
takes two arguments; the second argument is
the length of the string (not counting the
terminating null), so:</div>
<div><br>
</div>
<div>auto ideas =3D
std::literals::string_literals::operator""s("idea=
s?",
sizeof("ideas?") - 1);=C2=A0</div>
<div><br>
</div>
<div>Since literals and string_literals are
inline namespaces, this can be simplified to=C2=
=A0</div>
<div><br>
</div>
<div>auto ideas =3D std::operator""s("ideas?",
sizeof("ideas?") - 1);=C2=A0<br>
</div>
<div><br>
</div>
<div>But, again, what's the point?</div>
<div>
<div><br>
On Tuesday, June 16, 2015 at 1:38:10 AM
UTC-4, Roland Bock wrote:
<blockquote class=3D"gmail_quote"
style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px
#ccc solid;padding-left:1ex">Hi, <br>
<br>
Is there any way to use a user defined
literal without importing it into <br>
the current namespace? If not, is there a
proposal to do so? <br>
<br>
I tried the following unsuccessfully with
g++-5.0 -std=3Dc++1z <br>
<br>
<br>
#include <string> <br>
<br>
auto hello =3D "hello"s; //of course not <br>
auto world =3D
"world"std::literals::string_literals::operat=
or""s;
<br>
auto any =3D
"any"(std::literals::string_literals::operato=
r""s);
<br>
auto ideas =3D
std::literals::string_literals::operator""s("=
ideas?");
<br>
<br>
int main() {} <br>
<br>
<br>
Best, <br>
<br>
Roland <br>
</blockquote>
</div>
</div>
</div>
-- <br>
<br>
--- <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 email to <a
moz-do-not-send=3D"true"
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
moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org"
target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group=
/std-proposals/"
target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/</a>.<br>
</blockquote>
<br>
</div>
</div>
</div>
<div class=3D"HOEnZb">
<div class=3D"h5">
-- <br>
<br>
--- <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 email to <a
moz-do-not-send=3D"true"
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
moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org"
target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/std=
-proposals/"
target=3D"_blank">http://groups.google.com/a/isocpp.org=
/group/std-proposals/</a>.<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
-- <br>
<br>
--- <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 email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--------------000908070300050207000902--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 17 Jun 2015 11:44:28 -0700
Raw View
--20cf307f3834b776140518bb1405
Content-Type: text/plain; charset=UTF-8
On Wed, Jun 17, 2015 at 12:19 AM, Roland Bock <rbock@eudoxos.de> wrote:
> On 2015-06-16 23:42, Richard Smith wrote:
>
> On Tue, Jun 16, 2015 at 1:12 AM, Roland Bock <rbock@eudoxos.de> wrote:
>
>> Boost::Hana provides a user-defined literal that I would like to use to
>> define a compile time string in a header.
>>
>> See
>> http://ldionne.com/hana/structboost_1_1hana_1_1String.html#ad77f7afff008c2ce15739ad16a8bf0a8
>>
>> I would really like to say
>>
>> struct A
>> {
>> using name_t = decltype("sample"_s);
>>
>
> If we remove the (now-redundant) restriction on lambdas in unevaluated
> operands, you could write:
>
> Are there plans/proposals to do that? I stumbled over this restriction
> quite a few times.
>
I don't think it's on the core issues list. We discussed it while working
on core issue 1607, but I think we thought it would be best handled
separately.
> using name_t = decltype([] -> decltype(auto) {
> using namespace boost::hana;
> return "sample"_s;
> });
>
> And in today's C++:
>
> static decltype(auto) name() {
> using namespace boost::hana;
> return "sample"_s;
> }
> using name_t = decltype(name());
>
>
> Right, these are possible. But one of the basic ideas of UDLs seems to be
> brevity. I was hoping for something shorter, more expressive than I have
> now [1]:
>
> struct alias_t
> {
> static constexpr const char _literal[] = "delta";
> using name_t = sqlpp::make_char_sequence<sizeof(_literal), _literal>;
> };
>
>
> I therefore like Tomasz' suggestion very much:
>
> struct alias_t
> {
> using name_t = decltype(::boost::hana::"delta"s);
> };
>
>
> Short and expressive :-)
>
> Best,
>
> Roland
>
>
> [1] https://github.com/rbock/sqlpp11/blob/master/tests/Sample.h#L14-L17
>
>
>
>
>> };
>>
>> But _s is not in my namespace, so I would like to qualify it (using
>> namespace is not an option here).
>> And I would prefer not to provide the sizeof, which would require me to
>> write "sample" twice.
>>
>>
>>
>> On 2015-06-16 08:29, T. C. wrote:
>>
>> Doesn't explicitly qualifying the name defeat the whole point of
>> user-defined literals in the first place?
>>
>> Anyway, operator""s() is a function that takes two arguments; the
>> second argument is the length of the string (not counting the terminating
>> null), so:
>>
>> auto ideas = std::literals::string_literals::operator""s("ideas?",
>> sizeof("ideas?") - 1);
>>
>> Since literals and string_literals are inline namespaces, this can be
>> simplified to
>>
>> auto ideas = std::operator""s("ideas?", sizeof("ideas?") - 1);
>>
>> But, again, what's the point?
>>
>> On Tuesday, June 16, 2015 at 1:38:10 AM UTC-4, Roland Bock wrote:
>>>
>>> Hi,
>>>
>>> Is there any way to use a user defined literal without importing it into
>>> the current namespace? If not, is there a proposal to do so?
>>>
>>> I tried the following unsuccessfully with g++-5.0 -std=c++1z
>>>
>>>
>>> #include <string>
>>>
>>> auto hello = "hello"s; //of course not
>>> auto world = "world"std::literals::string_literals::operator""s;
>>> auto any = "any"(std::literals::string_literals::operator""s);
>>> auto ideas = std::literals::string_literals::operator""s("ideas?");
>>>
>>> int main() {}
>>>
>>>
>>> Best,
>>>
>>> Roland
>>>
>> --
>>
>> ---
>> 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/.
>>
>>
>> --
>>
>> ---
>> 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/.
>>
>
> --
>
> ---
> 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/.
>
>
> --
>
> ---
> 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/.
>
--
---
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/.
--20cf307f3834b776140518bb1405
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, Jun 17, 2015 at 12:19 AM, Roland Bock <span dir=3D"ltr"><<a href=3D"=
mailto:rbock@eudoxos.de" target=3D"_blank">rbock@eudoxos.de</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF"><span class=3D"">
<div>On 2015-06-16 23:42, Richard Smith
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Tue, Jun 16, 2015 at 1:12 AM,
Roland Bock <span dir=3D"ltr"><<a href=3D"mailto:rbock@eudox=
os.de" target=3D"_blank">rbock@eudoxos.de</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 text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>Boost::Hana provides a user-defined literal that I
would like to use to define a compile time string in a
header.<br>
<br>
See
<a href=3D"http://ldionne.com/hana/structboost_1_1hana_1_=
1String.html#ad77f7afff008c2ce15739ad16a8bf0a8" target=3D"_blank">http://ld=
ionne.com/hana/structboost_1_1hana_1_1String.html#ad77f7afff008c2ce15739ad1=
6a8bf0a8</a><br>
<br>
I would really like to say <br>
<br>
struct A<br>
{<br>
=C2=A0=C2=A0 using name_t =3D decltype("sample"=
_s);<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>If we remove the (now-redundant) restriction on lambdas
in unevaluated operands, you could write:</div>
</div>
</div>
</div>
</blockquote></span>
Are there plans/proposals to do that? I stumbled over this
restriction quite a few times.</div></blockquote><div><br></div><div>I =
don't think it's on the core issues list. We discussed it while wor=
king on core issue 1607, but I think we thought it would be best handled se=
parately.</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div text=3D"#000000" bgcolor=
=3D"#FFFFFF"><span class=3D""><blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
=20
<div>=C2=A0 using name_t =3D decltype([] -> decltype(auto) {=
</div>
<div>=C2=A0 =C2=A0 using namespace boost::hana;</div>
<div>=C2=A0 =C2=A0 return "sample"_s;</div>
<div>=C2=A0 });</div>
<div><br>
</div>
<div>And in today's C++:</div>
<div><br>
</div>
<div>=C2=A0 static decltype(auto) name() {</div>
<div>=C2=A0 =C2=A0 using namespace boost::hana;</div>
<div>=C2=A0 =C2=A0 return "sample"_s;</div>
<div>=C2=A0 }</div>
<div>=C2=A0 using name_t =3D decltype(name());</div>
</div>
</div>
</div>
</blockquote>
<br></span>
Right, these are possible. But one of the basic ideas of UDLs seems
to be brevity. I was hoping for something shorter, more expressive
than I have now [1]:<br>
<br>
<pre>struct alias_t
{
static constexpr const char _literal[] =3D "delta";
using name_t =3D sqlpp::make_char_sequence<sizeof(_literal), _literal&=
gt;;
};</pre>
<br>
I therefore like Tomasz' suggestion very much:<br>
<br>
<pre>struct alias_t
{
using name_t =3D decltype(::boost::hana::"delta"s);
};</pre>
<br>
Short and expressive :-)<br>
<br>
Best,<br>
<br>
Roland<br>
<br>
<br>
[1]
<a href=3D"https://github.com/rbock/sqlpp11/blob/master/tests/Sample.h#=
L14-L17" target=3D"_blank">https://github.com/rbock/sqlpp11/blob/master/tes=
ts/Sample.h#L14-L17</a><div><div class=3D"h5"><br>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div> };<br>
<br>
But _s is not in my namespace, so I would like to
qualify it (using namespace is not an option here).<br>
And I would prefer not to provide the sizeof, which
would require me to write "sample" twice.
<div>
<div><br>
<br>
<br>
On 2015-06-16 08:29, T. C. wrote:<br>
</div>
</div>
</div>
<div>
<div>
<blockquote type=3D"cite">
<div dir=3D"ltr">Doesn't explicitly qualifying th=
e
name defeat the whole point of user-defined
literals in the first place?
<div><br>
</div>
<div>Anyway, operator""s() is a function =
that
takes two arguments; the second argument is
the length of the string (not counting the
terminating null), so:</div>
<div><br>
</div>
<div>auto ideas =3D
std::literals::string_literals::operator"&qu=
ot;s("ideas?",
sizeof("ideas?") - 1);=C2=A0</div>
<div><br>
</div>
<div>Since literals and string_literals are
inline namespaces, this can be simplified to=C2=
=A0</div>
<div><br>
</div>
<div>auto ideas =3D std::operator""s(&quo=
t;ideas?",
sizeof("ideas?") - 1);=C2=A0<br>
</div>
<div><br>
</div>
<div>But, again, what's the point?</div>
<div>
<div><br>
On Tuesday, June 16, 2015 at 1:38:10 AM
UTC-4, Roland Bock wrote:
<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, <br=
>
<br>
Is there any way to use a user defined
literal without importing it into <br>
the current namespace? If not, is there a
proposal to do so? <br>
<br>
I tried the following unsuccessfully with
g++-5.0 -std=3Dc++1z <br>
<br>
<br>
#include <string> <br>
<br>
auto hello =3D "hello"s; //of cours=
e not <br>
auto world =3D
"world"std::literals::string_litera=
ls::operator""s;
<br>
auto any =3D
"any"(std::literals::string_literal=
s::operator""s);
<br>
auto ideas =3D
std::literals::string_literals::operator"=
;"s("ideas?");
<br>
<br>
int main() {} <br>
<br>
<br>
Best, <br>
<br>
Roland <br>
</blockquote>
</div>
</div>
</div>
-- <br>
<br>
--- <br>
You received this message because you are
subscribed to the Google Groups "ISO C++ Standar=
d
- Future Proposals" group.<br>
To unsubscribe from this group and stop receiving
emails from it, send an email to <a href=3D"mailto:st=
d-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-proposals+unsubsc=
ribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailt=
o:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>.=
<br>
Visit this group at <a href=3D"http://groups.google.c=
om/a/isocpp.org/group/std-proposals/" target=3D"_blank">http://groups.googl=
e.com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
<br>
</div>
</div>
</div>
<div>
<div>
-- <br>
<br>
--- <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 email to <a href=3D"mailto:std-pr=
oposals+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:st=
d-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a=
/isocpp.org/group/std-proposals/" target=3D"_blank">http://groups.google.co=
m/a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
-- <br>
<br>
--- <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 email to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.o=
rg" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/=
group/std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.o=
rg/group/std-proposals/</a>.<br>
</blockquote>
<br>
</div></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<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" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--20cf307f3834b776140518bb1405--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Wed, 17 Jun 2015 22:37:06 +0200
Raw View
This is a multi-part message in MIME format.
--------------090305080509010206020500
Content-Type: text/plain; charset=UTF-8
On 2015-06-17 07:08, Tomasz wrote:
>
>
> #include <string>
>
> auto hello = "hello"s; //of course not
> auto world = "world"std::literals::string_literals::operator""s;
> auto any = "any"(std::literals::string_literals::operator""s);
> auto ideas = std::literals::string_literals::operator""s("ideas?");
>
>
> As, the literals namespaces are inline, this could be simplified to
> use std::opeator""s. However I think that better syntax would be to
> place the qualification before literal itself, so we would get:
> auto hello = "hello"s;
> auto world = std::"world"s;
> auto any = std::literals::string_literals::"any"s; //If you insist on
> writing more
> and
> auto s = boost::hana::"sample"_s;
>
> Having prefixed qualified literal would allow to remove the limittion
> to use _ in user defined literals, because situation would now be same
> as for any other entity.
Anybody interested in writing or helping to write a proposal for this? I
certainly give it a try, but it will take some time before I get to it.
Cheers,
Roland
--
---
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/.
--------------090305080509010206020500
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">On 2015-06-17 07:08, Tomasz wrote:<br>
</div>
<blockquote
cite=3D"mid:eaa7a034-bf06-48ab-9852-5d727048a90c@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>
#include <string>
<br>
<br>
auto hello =3D "hello"s; //of course not
<br>
auto world =3D "world"std::literals::string_<wbr>literals::operat=
or""s;
<br>
auto any =3D "any"(std::literals::string_<wbr>literals::operator"=
"s);
<br>
auto ideas =3D std::literals::string_<wbr>literals::operator""s("=
ideas?"<wbr>);
<br>
<br>
<br>
</blockquote>
<div>As, the literals namespaces are inline, this could be
simplified to use std::opeator""s. However I think that better
syntax would be to place the qualification before literal
itself, so we would get:<br>
auto hello =3D "hello"s;<br>
auto world =3D std::"world"s;<br>
auto any =3D std::literals::string_literals::"any"s; //If you
insist on writing more<br>
and<br>
auto s =3D boost::hana::"sample"_s;<br>
<br>
Having prefixed qualified literal would allow to remove the
limittion to use _ in user defined literals, because situation
would now be same as for any other entity.<br>
</div>
</div>
</blockquote>
<br>
Anybody interested in writing or helping to write a proposal for
this? I certainly give it a=C2=A0 try, but it will take some time befor=
e
I get to it.<br>
<br>
Cheers,<br>
<br>
Roland<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--------------090305080509010206020500--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Wed, 17 Jun 2015 22:38:44 +0200
Raw View
This is a multi-part message in MIME format.
--------------070002010802060405020908
Content-Type: text/plain; charset=UTF-8
On 2015-06-17 20:44, Richard Smith wrote:
> On Wed, Jun 17, 2015 at 12:19 AM, Roland Bock <rbock@eudoxos.de
> <mailto:rbock@eudoxos.de>> wrote:
>
> On 2015-06-16 23:42, Richard Smith wrote:
>> On Tue, Jun 16, 2015 at 1:12 AM, Roland Bock <rbock@eudoxos.de
>> <mailto:rbock@eudoxos.de>> wrote:
>>
>> Boost::Hana provides a user-defined literal that I would like
>> to use to define a compile time string in a header.
>>
>> See
>> http://ldionne.com/hana/structboost_1_1hana_1_1String.html#ad77f7afff008c2ce15739ad16a8bf0a8
>>
>> I would really like to say
>>
>> struct A
>> {
>> using name_t = decltype("sample"_s);
>>
>>
>> If we remove the (now-redundant) restriction on lambdas in
>> unevaluated operands, you could write:
> Are there plans/proposals to do that? I stumbled over this
> restriction quite a few times.
>
>
> I don't think it's on the core issues list. We discussed it while
> working on core issue 1607, but I think we thought it would be best
> handled separately.
Can you give me a pointer as to why the restriction is redundant now?
Best,
Roland
--
---
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/.
--------------070002010802060405020908
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">On 2015-06-17 20:44, Richard Smith
wrote:<br>
</div>
<blockquote
cite=3D"mid:CAOfiQqkmoK00bRMdLr6KFO-moEi0BpMEUA0ctaTf0G6o=3D+r2eQ@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Wed, Jun 17, 2015 at 12:19 AM,
Roland Bock <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:rbock@eudoxos.de" target=3D"_blank">rbock@eu=
doxos.de</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 text=3D"#000000" bgcolor=3D"#FFFFFF"><span class=3D"">
<div>On 2015-06-16 23:42, Richard Smith wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Tue, Jun 16, 2015 at
1:12 AM, Roland Bock <span dir=3D"ltr"><<a
moz-do-not-send=3D"true"
href=3D"mailto:rbock@eudoxos.de"
target=3D"_blank">rbock@eudoxos.de</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 text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>Boost::Hana provides a user-defined
literal that I would like to use to
define a compile time string in a
header.<br>
<br>
See <a moz-do-not-send=3D"true"
href=3D"http://ldionne.com/hana/structboost_1_1hana_1_1String.html#ad77f7af=
ff008c2ce15739ad16a8bf0a8"
target=3D"_blank">http://ldionne.com/hana=
/structboost_1_1hana_1_1String.html#ad77f7afff008c2ce15739ad16a8bf0a8</a><b=
r>
<br>
I would really like to say <br>
<br>
struct A<br>
{<br>
=C2=A0=C2=A0 using name_t =3D decltype("sam=
ple"_s);<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>If we remove the (now-redundant)
restriction on lambdas in unevaluated
operands, you could write:</div>
</div>
</div>
</div>
</blockquote>
</span> Are there plans/proposals to do that? I stumbled
over this restriction quite a few times.</div>
</blockquote>
<div><br>
</div>
<div>I don't think it's on the core issues list. We
discussed it while working on core issue 1607, but I think
we thought it would be best handled separately.</div>
</div>
</div>
</div>
</blockquote>
Can you give me a pointer as to why the restriction is redundant
now?<br>
<br>
Best,<br>
<br>
Roland<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--------------070002010802060405020908--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 17 Jun 2015 13:46:23 -0700
Raw View
--bcaec51a742cad69b20518bcc839
Content-Type: text/plain; charset=UTF-8
On Wed, Jun 17, 2015 at 1:38 PM, Roland Bock <rbock@eudoxos.de> wrote:
> On 2015-06-17 20:44, Richard Smith wrote:
>
> On Wed, Jun 17, 2015 at 12:19 AM, Roland Bock <rbock@eudoxos.de> wrote:
>
>> On 2015-06-16 23:42, Richard Smith wrote:
>>
>> On Tue, Jun 16, 2015 at 1:12 AM, Roland Bock <rbock@eudoxos.de> wrote:
>>
>>> Boost::Hana provides a user-defined literal that I would like to use
>>> to define a compile time string in a header.
>>>
>>> See
>>> http://ldionne.com/hana/structboost_1_1hana_1_1String.html#ad77f7afff008c2ce15739ad16a8bf0a8
>>>
>>> I would really like to say
>>>
>>> struct A
>>> {
>>> using name_t = decltype("sample"_s);
>>>
>>
>> If we remove the (now-redundant) restriction on lambdas in unevaluated
>> operands, you could write:
>>
>> Are there plans/proposals to do that? I stumbled over this restriction
>> quite a few times.
>>
>
> I don't think it's on the core issues list. We discussed it while
> working on core issue 1607, but I think we thought it would be best handled
> separately.
>
> Can you give me a pointer as to why the restriction is redundant now?
>
See core issue 1607. The purpose of the restriction was to avoid
lambda-expressions appearing in a signature (so that implementations don't
need to implement declaration / statement SFINAE and don't need to mangle
them), but it was neither necessary nor sufficient for that. The new rules
in core issue 1607 don't need this restriction to implement that intent.
--
---
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/.
--bcaec51a742cad69b20518bcc839
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, Jun 17, 2015 at 1:38 PM, Roland Bock <span dir=3D"ltr"><<a href=3D"m=
ailto:rbock@eudoxos.de" target=3D"_blank">rbock@eudoxos.de</a>></span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF"><span class=3D"">
<div>On 2015-06-17 20:44, Richard Smith
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Wed, Jun 17, 2015 at 12:19 AM,
Roland Bock <span dir=3D"ltr"><<a href=3D"mailto:rbock@eudox=
os.de" target=3D"_blank">rbock@eudoxos.de</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 text=3D"#000000" bgcolor=3D"#FFFFFF"><span>
<div>On 2015-06-16 23:42, Richard Smith wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Tue, Jun 16, 2015 at
1:12 AM, Roland Bock <span dir=3D"ltr"><<a hre=
f=3D"mailto:rbock@eudoxos.de" target=3D"_blank">rbock@eudoxos.de</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 text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>Boost::Hana provides a user-defined
literal that I would like to use to
define a compile time string in a
header.<br>
<br>
See <a href=3D"http://ldionne.com/hana/stru=
ctboost_1_1hana_1_1String.html#ad77f7afff008c2ce15739ad16a8bf0a8" target=3D=
"_blank">http://ldionne.com/hana/structboost_1_1hana_1_1String.html#ad77f7a=
fff008c2ce15739ad16a8bf0a8</a><br>
<br>
I would really like to say <br>
<br>
struct A<br>
{<br>
=C2=A0=C2=A0 using name_t =3D decltype(&quo=
t;sample"_s);<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>If we remove the (now-redundant)
restriction on lambdas in unevaluated
operands, you could write:</div>
</div>
</div>
</div>
</blockquote>
</span> Are there plans/proposals to do that? I stumbled
over this restriction quite a few times.</div>
</blockquote>
<div><br>
</div>
<div>I don't think it's on the core issues list. We
discussed it while working on core issue 1607, but I think
we thought it would be best handled separately.</div>
</div>
</div>
</div>
</blockquote></span>
Can you give me a pointer as to why the restriction is redundant
now?<br></div></blockquote><div><br></div><div>See core issue 1607. The=
purpose of the restriction was to avoid lambda-expressions appearing in a =
signature (so that implementations don't need to implement declaration =
/ statement SFINAE and don't need to mangle them), but it was neither n=
ecessary nor sufficient for that. The new rules in core issue 1607 don'=
t need this restriction to implement that intent.</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 />
--bcaec51a742cad69b20518bcc839--
.
Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Thu, 18 Jun 2015 14:28:57 +0100
Raw View
--001a11c264be29fa1c0518caca67
Content-Type: text/plain; charset=UTF-8
Would it make sense to reorder the literal use?
I find this "Hello"std::s more readable than std::"Hello"s. I have the
feeling that this would also have less impact on the language (the user
defined suffix can be qualified, vs. having to define qualified-literals),
it also places the value (which I imagine more important), rather than
having to visually scan for the literal inside of the
<namespace::><literal><suffix> sequence; and it places the suffix together
with the namespace that needs to be checked...
On Wed, Jun 17, 2015 at 9:46 PM, Richard Smith <richard@metafoo.co.uk>
wrote:
> On Wed, Jun 17, 2015 at 1:38 PM, Roland Bock <rbock@eudoxos.de> wrote:
>
>> On 2015-06-17 20:44, Richard Smith wrote:
>>
>> On Wed, Jun 17, 2015 at 12:19 AM, Roland Bock <rbock@eudoxos.de> wrote:
>>
>>> On 2015-06-16 23:42, Richard Smith wrote:
>>>
>>> On Tue, Jun 16, 2015 at 1:12 AM, Roland Bock <rbock@eudoxos.de> wrote:
>>>
>>>> Boost::Hana provides a user-defined literal that I would like to use
>>>> to define a compile time string in a header.
>>>>
>>>> See
>>>> http://ldionne.com/hana/structboost_1_1hana_1_1String.html#ad77f7afff008c2ce15739ad16a8bf0a8
>>>>
>>>> I would really like to say
>>>>
>>>> struct A
>>>> {
>>>> using name_t = decltype("sample"_s);
>>>>
>>>
>>> If we remove the (now-redundant) restriction on lambdas in unevaluated
>>> operands, you could write:
>>>
>>> Are there plans/proposals to do that? I stumbled over this restriction
>>> quite a few times.
>>>
>>
>> I don't think it's on the core issues list. We discussed it while
>> working on core issue 1607, but I think we thought it would be best handled
>> separately.
>>
>> Can you give me a pointer as to why the restriction is redundant now?
>>
>
> See core issue 1607. The purpose of the restriction was to avoid
> lambda-expressions appearing in a signature (so that implementations don't
> need to implement declaration / statement SFINAE and don't need to mangle
> them), but it was neither necessary nor sufficient for that. The new rules
> in core issue 1607 don't need this restriction to implement that intent.
>
> --
>
> ---
> 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/.
>
--
---
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/.
--001a11c264be29fa1c0518caca67
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Would it make sense to reorder the literal use?<br><br>I f=
ind this "Hello"std::s more readable than std::"Hello"s=
.. I have the feeling that this would also have less impact on the language =
(the user defined suffix can be qualified, vs. having to define qualified-l=
iterals), it also places the value (which I imagine more important), rather=
than having to visually scan for the literal inside of the <namespace::=
><literal><suffix> sequence; and it places the suffix togeth=
er with the namespace that needs to be checked...</div><div class=3D"gmail_=
extra"><br><div class=3D"gmail_quote">On Wed, Jun 17, 2015 at 9:46 PM, Rich=
ard Smith <span dir=3D"ltr"><<a href=3D"mailto:richard@metafoo.co.uk" ta=
rget=3D"_blank">richard@metafoo.co.uk</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"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><span class=3D"">On Wed, Jun 17, 2015 at 1:38 PM, Roland B=
ock <span dir=3D"ltr"><<a href=3D"mailto:rbock@eudoxos.de" target=3D"_bl=
ank">rbock@eudoxos.de</a>></span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF"><span>
<div>On 2015-06-17 20:44, Richard Smith
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Wed, Jun 17, 2015 at 12:19 AM,
Roland Bock <span dir=3D"ltr"><<a href=3D"mailto:rbock@eudox=
os.de" target=3D"_blank">rbock@eudoxos.de</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 text=3D"#000000" bgcolor=3D"#FFFFFF"><span>
<div>On 2015-06-16 23:42, Richard Smith wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Tue, Jun 16, 2015 at
1:12 AM, Roland Bock <span dir=3D"ltr"><<a hre=
f=3D"mailto:rbock@eudoxos.de" target=3D"_blank">rbock@eudoxos.de</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 text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>Boost::Hana provides a user-defined
literal that I would like to use to
define a compile time string in a
header.<br>
<br>
See <a href=3D"http://ldionne.com/hana/stru=
ctboost_1_1hana_1_1String.html#ad77f7afff008c2ce15739ad16a8bf0a8" target=3D=
"_blank">http://ldionne.com/hana/structboost_1_1hana_1_1String.html#ad77f7a=
fff008c2ce15739ad16a8bf0a8</a><br>
<br>
I would really like to say <br>
<br>
struct A<br>
{<br>
=C2=A0=C2=A0 using name_t =3D decltype(&quo=
t;sample"_s);<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>If we remove the (now-redundant)
restriction on lambdas in unevaluated
operands, you could write:</div>
</div>
</div>
</div>
</blockquote>
</span> Are there plans/proposals to do that? I stumbled
over this restriction quite a few times.</div>
</blockquote>
<div><br>
</div>
<div>I don't think it's on the core issues list. We
discussed it while working on core issue 1607, but I think
we thought it would be best handled separately.</div>
</div>
</div>
</div>
</blockquote></span>
Can you give me a pointer as to why the restriction is redundant
now?<br></div></blockquote><div><br></div></span><div>See core issue 16=
07. The purpose of the restriction was to avoid lambda-expressions appearin=
g in a signature (so that implementations don't need to implement decla=
ration / statement SFINAE and don't need to mangle them), but it was ne=
ither necessary nor sufficient for that. The new rules in core issue 1607 d=
on't need this restriction to implement that intent.</div></div></div><=
/div><div class=3D"HOEnZb"><div class=3D"h5">
<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" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a11c264be29fa1c0518caca67--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Thu, 18 Jun 2015 17:21:54 -0700 (PDT)
Raw View
------=_Part_85_2054022679.1434673314241
Content-Type: multipart/alternative;
boundary="----=_Part_86_1159540428.1434673314241"
------=_Part_86_1159540428.1434673314241
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
YMMV; I find std::"Hello"s to be more readable. (Intuitively: *std::*
"Hello"s is a *std::*string. The prefix remains a prefix, and doesn't=20
switch into an internal position.)
Also, I feel like there would be a potential ambiguity with e.g. "Hello"a::=
b=20
=E2=80=94 is that the b belonging to "Hello"a, or is it "Hello"b evaluated =
with=20
respect to the a namespace? (Notice that there may also be a member b of=20
the a namespace, which is *completely* unrelated.) At the moment I *think*=
=20
it's impossible to create an actual grammatical ambiguity there, but it=20
*feels* dangerous.
On the other hand, consider the attempt to create an X::wstring via the=20
expression X::LR"(Hello)"s (respectively LR"(Hello)"X::s). How does this=20
interact with the declaration of a variable named X::LR (respectively X::s)=
?
Then consider the parsing nightmare that is units::42m resp. 42units::m.=20
(Those expressions' respective readability strikes me as a good argument in=
=20
favor of Roland's units::42m syntax and against David's alternative=20
suggestion.)
User-defined literals are a mess added on top of the pre-existing mess of=
=20
literal prefixes and suffixes, and perhaps the best thing to do is just=20
stay far away from them...?
On Thursday, June 18, 2015 at 6:29:02 AM UTC-7, David Rodr=C3=ADguez Ibeas =
wrote:
>
> Would it make sense to reorder the literal use?
>
> I find this "Hello"std::s more readable than std::"Hello"s. I have the=20
> feeling that this would also have less impact on the language (the user=
=20
> defined suffix can be qualified, vs. having to define qualified-literals)=
,=20
> it also places the value (which I imagine more important), rather than=20
> having to visually scan for the literal inside of the=20
> <namespace::><literal><suffix> sequence; and it places the suffix togethe=
r=20
> with the namespace that needs to be checked...
>
> On Wed, Jun 17, 2015 at 9:46 PM, Richard Smith <ric...@metafoo.co.uk=20
> <javascript:>> wrote:
>
>> On Wed, Jun 17, 2015 at 1:38 PM, Roland Bock <rb...@eudoxos.de=20
>> <javascript:>> wrote:
>>
>>> On 2015-06-17 20:44, Richard Smith wrote:
>>> =20
>>> On Wed, Jun 17, 2015 at 12:19 AM, Roland Bock <rb...@eudoxos.de=20
>>> <javascript:>> wrote:
>>>
>>>> On 2015-06-16 23:42, Richard Smith wrote:
>>>> =20
>>>> On Tue, Jun 16, 2015 at 1:12 AM, Roland Bock <rb...@eudoxos.de=20
>>>> <javascript:>> wrote:
>>>>
>>>>> Boost::Hana provides a user-defined literal that I would like to use=
=20
>>>>> to define a compile time string in a header.
>>>>>
>>>>> See=20
>>>>> http://ldionne.com/hana/structboost_1_1hana_1_1String.html#ad77f7afff=
008c2ce15739ad16a8bf0a8
>>>>>
>>>>> I would really like to say=20
>>>>>
>>>>> struct A
>>>>> {
>>>>> using name_t =3D decltype("sample"_s);
>>>>> =20
>>>>
>>>> If we remove the (now-redundant) restriction on lambdas in=20
>>>> unevaluated operands, you could write:
>>>> =20
>>>> Are there plans/proposals to do that? I stumbled over this restrictio=
n=20
>>>> quite a few times.
>>>>
>>>
>>> I don't think it's on the core issues list. We discussed it while=20
>>> working on core issue 1607, but I think we thought it would be best han=
dled=20
>>> separately.
>>> =20
>>> Can you give me a pointer as to why the restriction is redundant now?
>>>
>>
>> See core issue 1607. The purpose of the restriction was to avoid=20
>> lambda-expressions appearing in a signature (so that implementations don=
't=20
>> need to implement declaration / statement SFINAE and don't need to mangl=
e=20
>> them), but it was neither necessary nor sufficient for that. The new rul=
es=20
>> in core issue 1607 don't need this restriction to implement that intent.
>>
>> --=20
>>
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>
--=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_86_1159540428.1434673314241
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">YMMV; I find <font face=3D"courier new, monospace">std::"H=
ello"s</font> to be more readable. (Intuitively: <font face=3D"courier new,=
monospace"><b>std::</b>"Hello"s</font> is a <font face=3D"courier new, mon=
ospace"><b>std::</b>string</font>. The prefix remains a prefix, and doesn't=
switch into an internal position.)<div>Also, I feel like there would be a =
potential ambiguity with e.g. <font face=3D"courier new, monospace">"Hello"=
a::b</font> =E2=80=94 is that the <font face=3D"courier new, monospace">b</=
font> belonging to <font face=3D"courier new, monospace">"Hello"a</font>, o=
r is it <font face=3D"courier new, monospace">"Hello"b</font> evaluated wit=
h respect to the <font face=3D"courier new, monospace">a</font> namespace? =
(Notice that there may also be a member <font face=3D"courier new, monospac=
e">b</font> of the <font face=3D"courier new, monospace">a</font> namespace=
, which is <i>completely</i> unrelated.) At the moment I <i>think</i> it's =
impossible to create an actual grammatical ambiguity there, but it <i>feels=
</i> dangerous.</div><div><br>On the other hand, consider the attempt to cr=
eate an <font face=3D"courier new, monospace">X::wstring</font> via the exp=
ression <font face=3D"courier new, monospace">X::LR"(Hello)"s</font> (respe=
ctively <font face=3D"courier new, monospace">LR"(Hello)"X::s</font>). How =
does this interact with the declaration of a variable named <font face=3D"c=
ourier new, monospace">X::LR</font> (respectively <font face=3D"courie=
r new, monospace">X::s</font>)?</div><div><br></div><div>Then consider the =
parsing nightmare that is <font face=3D"courier new, monospace">units::42m<=
/font> resp. <font face=3D"courier new, monospace">42units::m</font>. (Thos=
e expressions' respective readability strikes me as a good argument in favo=
r of Roland's <font face=3D"courier new, monospace">units::42m</font> synta=
x and against David's alternative suggestion.)<br><br>User-defined literals=
are a mess added on top of the pre-existing mess of literal prefixes and s=
uffixes, and perhaps the best thing to do is just stay far away from them..=
..?</div><div><br></div><div><br>On Thursday, June 18, 2015 at 6:29:02 AM UT=
C-7, David Rodr=C3=ADguez Ibeas wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr">Would it make sense to reorder the literal use?<br=
><br>I find this "Hello"std::s more readable than std::"Hello"s. I have the=
feeling that this would also have less impact on the language (the user de=
fined suffix can be qualified, vs. having to define qualified-literals), it=
also places the value (which I imagine more important), rather than having=
to visually scan for the literal inside of the <namespace::><lite=
ral><suffix> sequence; and it places the suffix together with the =
namespace that needs to be checked...</div><div><br><div class=3D"gmail_quo=
te">On Wed, Jun 17, 2015 at 9:46 PM, Richard Smith <span dir=3D"ltr"><<a=
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"ui2Zx2dSQ3=
0J" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;"=
onclick=3D"this.href=3D'javascript:';return true;">ric...@metafoo.co.uk</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"><div=
><div class=3D"gmail_quote"><span>On Wed, Jun 17, 2015 at 1:38 PM, Roland B=
ock <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"ui2Zx2dSQ30J" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;">rb...@eudoxos.de</a>></span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF"><span>
<div>On 2015-06-17 20:44, Richard Smith
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>
<div class=3D"gmail_quote">On Wed, Jun 17, 2015 at 12:19 AM,
Roland Bock <span dir=3D"ltr"><<a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"ui2Zx2dSQ30J" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'ja=
vascript:';return true;">rb...@eudoxos.de</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 text=3D"#000000" bgcolor=3D"#FFFFFF"><span>
<div>On 2015-06-16 23:42, Richard Smith wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>
<div class=3D"gmail_quote">On Tue, Jun 16, 2015 at
1:12 AM, Roland Bock <span dir=3D"ltr"><<a hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"ui2Zx2dSQ30J" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" onc=
lick=3D"this.href=3D'javascript:';return true;">rb...@eudoxos.de</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 text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>Boost::Hana provides a user-defined
literal that I would like to use to
define a compile time string in a
header.<br>
<br>
See <a href=3D"http://ldionne.com/hana/stru=
ctboost_1_1hana_1_1String.html#ad77f7afff008c2ce15739ad16a8bf0a8" target=3D=
"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com=
/url?q\75http%3A%2F%2Fldionne.com%2Fhana%2Fstructboost_1_1hana_1_1String.ht=
ml%23ad77f7afff008c2ce15739ad16a8bf0a8\46sa\75D\46sntz\0751\46usg\75AFQjCNH=
DkIzQ9evLICl3UR5amXZWF5U79A';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\75http%3A%2F%2Fldionne.com%2Fhana%2Fstructboost_1_1hana=
_1_1String.html%23ad77f7afff008c2ce15739ad16a8bf0a8\46sa\75D\46sntz\0751\46=
usg\75AFQjCNHDkIzQ9evLICl3UR5amXZWF5U79A';return true;">http://ldionne.com/=
hana/<wbr>structboost_1_1hana_1_1String.<wbr>html#<wbr>ad77f7afff008c2ce157=
39ad16a8bf<wbr>0a8</a><br>
<br>
I would really like to say <br>
<br>
struct A<br>
{<br>
using name_t =3D decltype("sam=
ple"_s);<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>If we remove the (now-redundant)
restriction on lambdas in unevaluated
operands, you could write:</div>
</div>
</div>
</div>
</blockquote>
</span> Are there plans/proposals to do that? I stumbled
over this restriction quite a few times.</div>
</blockquote>
<div><br>
</div>
<div>I don't think it's on the core issues list. We
discussed it while working on core issue 1607, but I think
we thought it would be best handled separately.</div>
</div>
</div>
</div>
</blockquote></span>
Can you give me a pointer as to why the restriction is redundant
now?<br></div></blockquote><div><br></div></span><div>See core issue 16=
07. The purpose of the restriction was to avoid lambda-expressions appearin=
g in a signature (so that implementations don't need to implement declarati=
on / statement SFINAE and don't need to mangle them), but it was neither ne=
cessary nor sufficient for that. The new rules in core issue 1607 don't nee=
d this restriction to implement that intent.</div></div></div></div><div><d=
iv>
<p></p>
-- <br>
<br>
--- <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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
ui2Zx2dSQ30J" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';ret=
urn true;" onclick=3D"this.href=3D'javascript:';return true;">std-proposal.=
...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"ui2Zx2dSQ30J" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:=
';return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';return true=
;" onclick=3D"this.href=3D'http://groups.google.com/a/isocpp.org/group/std-=
proposals/';return true;">http://groups.google.com/a/<wbr>isocpp.org/group/=
std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></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_86_1159540428.1434673314241--
------=_Part_85_2054022679.1434673314241--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Thu, 18 Jun 2015 18:04:07 -0700
Raw View
--001a1133f7e2409db90518d480fb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thu, Jun 18, 2015 at 5:21 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:
> YMMV; I find std::"Hello"s to be more readable. (Intuitively: *std::*
> "Hello"s is a *std::*string. The prefix remains a prefix, and doesn't
> switch into an internal position.)
> Also, I feel like there would be a potential ambiguity with e.g.
> "Hello"a::b =E2=80=94 is that the b belonging to "Hello"a, or is it "Hell=
o"b
> evaluated with respect to the a namespace? (Notice that there may also be
> a member b of the a namespace, which is *completely* unrelated.) At the
> moment I *think* it's impossible to create an actual grammatical
> ambiguity there, but it *feels* dangerous.
>
The *nested-name-specifier*-after-literal form is also unusable for various
kinds of *ud-suffix*. For instance:
std::complex<float> x =3D 1.0std::if; // error, 'if' is a keyword
my::filesize =3D 33my::_MB; // error, '_MB' is reserved
Putting the *nested-name-specifier* before the *user-defined-literal* token
seems like the better choice to me.
> On the other hand, consider the attempt to create an X::wstring via the
> expression X::LR"(Hello)"s (respectively LR"(Hello)"X::s). How does this
> interact with the declaration of a variable named X::LR (respectively X::=
s
> )?
>
I don't think this is any different from the existing situation if you
wrote LR"(Hello)"s inside namespace X: you get a raw string literal token.
I think this works fine with either approach.
> Then consider the parsing nightmare that is units::42m resp. 42units::m.
> (Those expressions' respective readability strikes me as a good argument =
in
> favor of Roland's units::42m syntax and against David's alternative
> suggestion.)
>
I too find the prefix form more readable.
User-defined literals are a mess added on top of the pre-existing mess of
> literal prefixes and suffixes, and perhaps the best thing to do is just
> stay far away from them...?
>
>
> On Thursday, June 18, 2015 at 6:29:02 AM UTC-7, David Rodr=C3=ADguez Ibea=
s
> wrote:
>>
>> Would it make sense to reorder the literal use?
>>
>> I find this "Hello"std::s more readable than std::"Hello"s. I have the
>> feeling that this would also have less impact on the language (the user
>> defined suffix can be qualified, vs. having to define qualified-literals=
),
>> it also places the value (which I imagine more important), rather than
>> having to visually scan for the literal inside of the
>> <namespace::><literal><suffix> sequence; and it places the suffix togeth=
er
>> with the namespace that needs to be checked...
>>
>> On Wed, Jun 17, 2015 at 9:46 PM, Richard Smith <ric...@metafoo.co.uk>
>> wrote:
>>
>>> On Wed, Jun 17, 2015 at 1:38 PM, Roland Bock <rb...@eudoxos.de> wrote:
>>>
>>>> On 2015-06-17 20:44, Richard Smith wrote:
>>>>
>>>> On Wed, Jun 17, 2015 at 12:19 AM, Roland Bock <rb...@eudoxos.de>
>>>> wrote:
>>>>
>>>>> On 2015-06-16 23:42, Richard Smith wrote:
>>>>>
>>>>> On Tue, Jun 16, 2015 at 1:12 AM, Roland Bock <rb...@eudoxos.de>
>>>>> wrote:
>>>>>
>>>>>> Boost::Hana provides a user-defined literal that I would like to
>>>>>> use to define a compile time string in a header.
>>>>>>
>>>>>> See
>>>>>> http://ldionne.com/hana/structboost_1_1hana_1_1String.html#ad77f7aff=
f008c2ce15739ad16a8bf0a8
>>>>>>
>>>>>> I would really like to say
>>>>>>
>>>>>> struct A
>>>>>> {
>>>>>> using name_t =3D decltype("sample"_s);
>>>>>>
>>>>>
>>>>> If we remove the (now-redundant) restriction on lambdas in
>>>>> unevaluated operands, you could write:
>>>>>
>>>>> Are there plans/proposals to do that? I stumbled over this
>>>>> restriction quite a few times.
>>>>>
>>>>
>>>> I don't think it's on the core issues list. We discussed it while
>>>> working on core issue 1607, but I think we thought it would be best ha=
ndled
>>>> separately.
>>>>
>>>> Can you give me a pointer as to why the restriction is redundant now?
>>>>
>>>
>>> See core issue 1607. The purpose of the restriction was to avoid
>>> lambda-expressions appearing in a signature (so that implementations do=
n't
>>> need to implement declaration / statement SFINAE and don't need to mang=
le
>>> them), but it was neither necessary nor sufficient for that. The new ru=
les
>>> in core issue 1607 don't need this restriction to implement that intent=
..
>>>
>>> --
>>>
>>> ---
>>> 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-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>> --
>
> ---
> 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/.
>
--=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/.
--001a1133f7e2409db90518d480fb
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, Jun 18, 2015 at 5:21 PM, Arthur O'Dwyer <span dir=3D"ltr"><<a hr=
ef=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@g=
mail.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">YMMV; I find <font face=3D"courier new, monospace">std::"Hell=
o"s</font> to be more readable. (Intuitively: <font face=3D"courier ne=
w, monospace"><b>std::</b>"Hello"s</font> is a <font face=3D"cour=
ier new, monospace"><b>std::</b>string</font>. The prefix remains a prefix,=
and doesn't switch into an internal position.)<div>Also, I feel like t=
here would be a potential ambiguity with e.g. <font face=3D"courier new, mo=
nospace">"Hello"a::b</font> =E2=80=94 is that the <font face=3D"c=
ourier new, monospace">b</font> belonging to <font face=3D"courier new, mon=
ospace">"Hello"a</font>, or is it <font face=3D"courier new, mono=
space">"Hello"b</font> evaluated with respect to the <font face=
=3D"courier new, monospace">a</font> namespace? (Notice that there may also=
be a member <font face=3D"courier new, monospace">b</font> of the <font fa=
ce=3D"courier new, monospace">a</font> namespace, which is <i>completely</i=
> unrelated.) At the moment I <i>think</i> it's impossible to create an=
actual grammatical ambiguity there, but it <i>feels</i> dangerous.</div></=
div></blockquote><div><br></div><div>The <i>nested-name-specifier</i>-after=
-literal form is also unusable for various kinds of <i>ud-suffix</i>. For i=
nstance:</div><div><br></div><div>=C2=A0 std::complex<float> x =3D 1.=
0std::if; // error, 'if' is a keyword</div><div>=C2=A0 my::filesize=
=3D 33my::_MB; // error, '_MB' is reserved</div><div><br></div><di=
v>Putting the <i>nested-name-specifier</i> before the <i>user-defined-liter=
al</i> token seems like the better choice to me.</div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div>On the other hand, conside=
r the attempt to create an <font face=3D"courier new, monospace">X::wstring=
</font> via the expression <font face=3D"courier new, monospace">X::LR"=
;(Hello)"s</font> (respectively <font face=3D"courier new, monospace">=
LR"(Hello)"X::s</font>). How does this interact with the declarat=
ion of a variable named <font face=3D"courier new, monospace">X::LR</font> =
(respectively=C2=A0<font face=3D"courier new, monospace">X::s</font>)?</div=
></div></blockquote><div><br></div><div>I don't think this is any diffe=
rent from the existing situation if you wrote LR"(Hello)"s inside=
namespace X: you get a raw string literal token. I think this works fine w=
ith either approach.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div>Then consider the parsing nightmare that is <font face=
=3D"courier new, monospace">units::42m</font> resp. <font face=3D"courier n=
ew, monospace">42units::m</font>. (Those expressions' respective readab=
ility strikes me as a good argument in favor of Roland's <font face=3D"=
courier new, monospace">units::42m</font> syntax and against David's al=
ternative suggestion.)<br></div></div></blockquote><div><br></div><div>I to=
o find the prefix form more readable.</div><div><br></div><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>User-defined literals are a mess added =
on top of the pre-existing mess of literal prefixes and suffixes, and perha=
ps the best thing to do is just stay far away from them...?</div><div><br><=
/div><div><span class=3D""><br>On Thursday, June 18, 2015 at 6:29:02 AM UTC=
-7, David Rodr=C3=ADguez Ibeas wrote:</span><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><span class=3D""><div dir=3D"ltr">Would it make sense to reorder t=
he literal use?<br><br>I find this "Hello"std::s more readable th=
an std::"Hello"s. I have the feeling that this would also have le=
ss impact on the language (the user defined suffix can be qualified, vs. ha=
ving to define qualified-literals), it also places the value (which I imagi=
ne more important), rather than having to visually scan for the literal ins=
ide of the <namespace::><literal><suffix> sequence; and i=
t places the suffix together with the namespace that needs to be checked...=
</div></span><div><br><div class=3D"gmail_quote">On Wed, Jun 17, 2015 at 9:=
46 PM, Richard Smith <span dir=3D"ltr"><<a rel=3D"nofollow">ric...@metaf=
oo.co.uk</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"><div><div class=3D"gmail_quote"><span><span class=3D"">On Wed, Jun=
17, 2015 at 1:38 PM, Roland Bock <span dir=3D"ltr"><<a rel=3D"nofollow"=
>rb...@eudoxos.de</a>></span> wrote:<br></span><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF"><span><span class=3D"">
<div>On 2015-06-17 20:44, Richard Smith
wrote:<br>
</div>
</span><blockquote type=3D"cite">
<div dir=3D"ltr">
<div>
<div class=3D"gmail_quote"><span class=3D"">On Wed, Jun 17, 2015 =
at 12:19 AM,
Roland Bock <span dir=3D"ltr"><<a rel=3D"nofollow">rb...@eud=
oxos.de</a>></span>
wrote:<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF"><span><span class=
=3D"">
<div>On 2015-06-16 23:42, Richard Smith wrote:<br>
</div>
</span><span class=3D""><blockquote type=3D"cite">
<div dir=3D"ltr">
<div>
<div class=3D"gmail_quote">On Tue, Jun 16, 2015 at
1:12 AM, Roland Bock <span dir=3D"ltr"><<a rel=
=3D"nofollow">rb...@eudoxos.de</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 text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>Boost::Hana provides a user-defined
literal that I would like to use to
define a compile time string in a
header.<br>
<br>
See <a href=3D"http://ldionne.com/hana/stru=
ctboost_1_1hana_1_1String.html#ad77f7afff008c2ce15739ad16a8bf0a8" rel=3D"no=
follow" target=3D"_blank">http://ldionne.com/hana/structboost_1_1hana_1_1St=
ring.html#ad77f7afff008c2ce15739ad16a8bf0a8</a><br>
<br>
I would really like to say <br>
<br>
struct A<br>
{<br>
=C2=A0=C2=A0 using name_t =3D decltype(&quo=
t;sample"_s);<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>If we remove the (now-redundant)
restriction on lambdas in unevaluated
operands, you could write:</div>
</div>
</div>
</div>
</blockquote>
</span></span><span class=3D""> Are there plans/proposals t=
o do that? I stumbled
over this restriction quite a few times.</span></div>
</blockquote><span class=3D"">
<div><br>
</div>
<div>I don't think it's on the core issues list. We
discussed it while working on core issue 1607, but I think
we thought it would be best handled separately.</div>
</span></div>
</div>
</div>
</blockquote></span><span class=3D"">
Can you give me a pointer as to why the restriction is redundant
now?<br></span></div></blockquote><div><br></div></span><span class=3D"=
"><div>See core issue 1607. The purpose of the restriction was to avoid lam=
bda-expressions appearing in a signature (so that implementations don't=
need to implement declaration / statement SFINAE and don't need to man=
gle them), but it was neither necessary nor sufficient for that. The new ru=
les in core issue 1607 don't need this restriction to implement that in=
tent.</div></span></div></div></div><div><div><span class=3D"">
<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></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span class=3D""><br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank">http://groups.google.com=
/a/isocpp.org/group/std-proposals/</a>.<br>
</span></div></div></blockquote></div><br></div>
</blockquote></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<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" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a1133f7e2409db90518d480fb--
.
Author: David Krauss <potswa@gmail.com>
Date: Fri, 19 Jun 2015 10:07:49 +0800
Raw View
--Apple-Mail=_2A86F67E-65DB-4BEA-867D-93013FAC819C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9306=E2=80=9319, at 9:04 AM, Richard Smith <richard@metafoo=
..co.uk> wrote:
>=20
> Putting the nested-name-specifier before the user-defined-literal token s=
eems like the better choice to me.
That still demands that translation phase 6, merging adjacent string litera=
ls, can recognize the qualifiers. Currently that step can be done together =
with preprocessing.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_2A86F67E-65DB-4BEA-867D-93013FAC819C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=
=E2=80=9319, at 9:04 AM, Richard Smith <<a href=3D"mailto:richard@metafo=
o.co.uk" class=3D"">richard@metafoo.co.uk</a>> wrote:</div><br class=3D"=
Apple-interchange-newline"><div class=3D""><div style=3D"font-family: Helve=
tica; font-size: 12px; font-style: normal; font-variant: normal; font-weigh=
t: normal; letter-spacing: normal; line-height: normal; orphans: auto; text=
-align: start; text-indent: 0px; text-transform: none; white-space: normal;=
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D=
"">Putting the<span class=3D"Apple-converted-space"> </span><i class=
=3D"">nested-name-specifier</i><span class=3D"Apple-converted-space"> =
</span>before the<span class=3D"Apple-converted-space"> </span><i clas=
s=3D"">user-defined-literal</i><span class=3D"Apple-converted-space"> =
</span>token seems like the better choice to me.</div></div></blockquote></=
div><br class=3D""><div class=3D"">That still demands that translation phas=
e 6, merging adjacent string literals, can recognize the qualifiers. Curren=
tly that step can be done together with preprocessing.</div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_2A86F67E-65DB-4BEA-867D-93013FAC819C--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Thu, 18 Jun 2015 20:39:30 -0700
Raw View
--bcaec52d52ddfad8e40518d6ab61
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thu, Jun 18, 2015 at 7:07 PM, David Krauss <potswa@gmail.com> wrote:
>
> On 2015=E2=80=9306=E2=80=9319, at 9:04 AM, Richard Smith <richard@metafoo=
..co.uk> wrote:
>
> Putting the *nested-name-specifier* before the *user-defined-literal* tok=
en
> seems like the better choice to me.
>
>
> That still demands that translation phase 6, merging adjacent string
> literals, can recognize the qualifiers. Currently that step can be done
> together with preprocessing.
>
I don't think that's absolutely necessary; allowing std::"foo"s "bar" (or
std::"foo" "bar"s) but not std::"foo"s std::"bar"s doesn't seem like a
disaster to me, and seems better than moving string literal concatenation
into phase 7. (This is another reason to prefer prefix over suffix; the
same thing doesn't work out too well for the suffix form.)
But I agree this is a problem, and for me at least it weighs somewhat
against the proposed change.
--=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/.
--bcaec52d52ddfad8e40518d6ab61
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, Jun 18, 2015 at 7:07 PM, David Krauss <span dir=3D"ltr"><<a href=3D"=
mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word=
"><span class=3D""><br><div><blockquote type=3D"cite"><div>On 2015=E2=80=93=
06=E2=80=9319, at 9:04 AM, Richard Smith <<a href=3D"mailto:richard@meta=
foo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>> wrote:</div><br>=
<div><div style=3D"font-family:Helvetica;font-size:12px;font-style:normal;f=
ont-variant:normal;font-weight:normal;letter-spacing:normal;line-height:nor=
mal;text-align:start;text-indent:0px;text-transform:none;white-space:normal=
;word-spacing:0px">Putting the<span>=C2=A0</span><i>nested-name-specifier</=
i><span>=C2=A0</span>before the<span>=C2=A0</span><i>user-defined-literal</=
i><span>=C2=A0</span>token seems like the better choice to me.</div></div><=
/blockquote></div><br></span><div>That still demands that translation phase=
6, merging adjacent string literals, can recognize the qualifiers. Current=
ly that step can be done together with preprocessing.</div></div></blockquo=
te><div>=C2=A0</div><div>I don't think that's absolutely necessary;=
allowing std::"foo"s "bar" (or std::"foo" &q=
uot;bar"s) but not std::"foo"s std::"bar"s doesn&#=
39;t seem like a disaster to me, and seems better than moving string litera=
l concatenation into phase 7. (This is another reason to prefer prefix over=
suffix; the same thing doesn't work out too well for the suffix form.)=
</div><div><br></div><div>But I agree this is a problem, and for me at leas=
t it weighs somewhat against the proposed change.</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 />
--bcaec52d52ddfad8e40518d6ab61--
.
Author: Tomasz <tomaszkam@gmail.com>
Date: Thu, 18 Jun 2015 21:44:02 -0700 (PDT)
Raw View
------=_Part_401_471117319.1434689043011
Content-Type: multipart/alternative;
boundary="----=_Part_402_296573944.1434689043011"
------=_Part_402_296573944.1434689043011
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu pi=C4=85tek, 19 czerwca 2015 02:21:54 UTC+2 u=C5=BCytkownik Arthur O=
'Dwyer=20
napisa=C5=82:
>
>
> User-defined literals are a mess added on top of the pre-existing mess of=
=20
> literal prefixes and suffixes, and perhaps the best thing to do is just=
=20
> stay far away from them...?
>
I do not agree with that point. As I understand user defined literals was=
=20
developed mainly for the library writers to provide support equivalent as=
=20
one for build-in types for the types that they provide. However in the=20
current form they are not really usable - the client of the multiple=20
libraries are unable to resolve ambiguity caused by having same suffix in=
=20
multiple used libraries. And we have only avoided the problem by reserving=
=20
names that does not start "_" for standard library - such solution is not=
=20
viable for other libraries, because if they decided to choose a short=20
prefix then there is no guarantee that other library will not use it, and=
=20
using long unambiguous prefixes defeat the point of using them, and also=20
put as again in pre-namespace world. As C++ aims to be language for witting=
=20
libraries and does not provide standard library with everything in it, then=
=20
we should provide equal support for other libraries like for standard one,=
=20
including support for reasonable (short) user defined literals.
Also, the user cannot simply invoke operator"" literal instead of using=20
123litterals, because they will need to know which form is used:
operator"" literal(123);
operator"" literal("123");
operator"" literal<'1', '2', '3'>(); //The 3rd form is hardly to be=20
considered usable outside of automatic compiler calls.
>
>
> On Thursday, June 18, 2015 at 6:29:02 AM UTC-7, David Rodr=C3=ADguez Ibea=
s=20
> wrote:
>>
>> Would it make sense to reorder the literal use?
>>
>> I find this "Hello"std::s more readable than std::"Hello"s. I have the=
=20
>> feeling that this would also have less impact on the language (the user=
=20
>> defined suffix can be qualified, vs. having to define qualified-literals=
),=20
>> it also places the value (which I imagine more important), rather than=
=20
>> having to visually scan for the literal inside of the=20
>> <namespace::><literal><suffix> sequence; and it places the suffix togeth=
er=20
>> with the namespace that needs to be checked...
>>
>> On Wed, Jun 17, 2015 at 9:46 PM, Richard Smith <ric...@metafoo.co.uk>=20
>> wrote:
>>
>>> On Wed, Jun 17, 2015 at 1:38 PM, Roland Bock <rb...@eudoxos.de> wrote:
>>>
>>>> On 2015-06-17 20:44, Richard Smith wrote:
>>>> =20
>>>> On Wed, Jun 17, 2015 at 12:19 AM, Roland Bock <rb...@eudoxos.de>=20
>>>> wrote:
>>>>
>>>>> On 2015-06-16 23:42, Richard Smith wrote:
>>>>> =20
>>>>> On Tue, Jun 16, 2015 at 1:12 AM, Roland Bock <rb...@eudoxos.de>=20
>>>>> wrote:
>>>>>
>>>>>> Boost::Hana provides a user-defined literal that I would like to=20
>>>>>> use to define a compile time string in a header.
>>>>>>
>>>>>> See=20
>>>>>> http://ldionne.com/hana/structboost_1_1hana_1_1String.html#ad77f7aff=
f008c2ce15739ad16a8bf0a8
>>>>>>
>>>>>> I would really like to say=20
>>>>>>
>>>>>> struct A
>>>>>> {
>>>>>> using name_t =3D decltype("sample"_s);
>>>>>> =20
>>>>>
>>>>> If we remove the (now-redundant) restriction on lambdas in=20
>>>>> unevaluated operands, you could write:
>>>>> =20
>>>>> Are there plans/proposals to do that? I stumbled over this=20
>>>>> restriction quite a few times.
>>>>>
>>>>
>>>> I don't think it's on the core issues list. We discussed it while=20
>>>> working on core issue 1607, but I think we thought it would be best ha=
ndled=20
>>>> separately.
>>>> =20
>>>> Can you give me a pointer as to why the restriction is redundant now?
>>>>
>>>
>>> See core issue 1607. The purpose of the restriction was to avoid=20
>>> lambda-expressions appearing in a signature (so that implementations do=
n't=20
>>> need to implement declaration / statement SFINAE and don't need to mang=
le=20
>>> them), but it was neither necessary nor sufficient for that. The new ru=
les=20
>>> in core issue 1607 don't need this restriction to implement that intent=
..
>>>
>>> --=20
>>>
>>> ---=20
>>> You received this message because you are subscribed to the Google=20
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> Visit this group at=20
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>>
--=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_402_296573944.1434689043011
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>W dniu pi=C4=85tek, 19 czerwca 2015 02:21:54 UTC+2=
u=C5=BCytkownik Arthur O'Dwyer napisa=C5=82:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><br><div>User-defined literals are a mess a=
dded on top of the pre-existing mess of literal prefixes and suffixes, and =
perhaps the best thing to do is just stay far away from them...?</div></div=
></blockquote><div><br>I do not agree with that point. As I understand user=
defined literals was developed mainly for the library writers to provide s=
upport equivalent as one for build-in types for the types that they provide=
.. However in the current form they are not really usable - the client of th=
e multiple libraries are unable to resolve ambiguity caused by having same =
suffix in multiple used libraries. And we have only avoided the problem by =
reserving names that does not start "_" for standard library - such solutio=
n is not viable for other libraries, because if they decided to choose a sh=
ort prefix then there is no guarantee that other library will not use it, a=
nd using long unambiguous prefixes defeat the point of using them, and also=
put as again in pre-namespace world. As C++ aims to be language for wittin=
g libraries and does not provide standard library with everything in it, th=
en we should provide equal support for other libraries like for standard on=
e, including support for reasonable (short) user defined literals.<br><br>A=
lso, the user cannot simply invoke operator"" literal instead of using 123l=
itterals, because they will need to know which form is used:<br>operator"" =
literal(123);<br>operator"" literal("123");<br>operator"" literal<'1', '=
2', '3'>(); //The 3rd form is hardly to be considered usable outside of =
automatic compiler calls.<br></div><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"><div><br></div><div><br>On Thursday, June 18, 2015 a=
t 6:29:02 AM UTC-7, David Rodr=C3=ADguez Ibeas wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr">Would it make sense to reorder the liter=
al use?<br><br>I find this "Hello"std::s more readable than std::"Hello"s. =
I have the feeling that this would also have less impact on the language (t=
he user defined suffix can be qualified, vs. having to define qualified-lit=
erals), it also places the value (which I imagine more important), rather t=
han having to visually scan for the literal inside of the <namespace::&g=
t;<literal><suffix> sequence; and it places the suffix together=
with the namespace that needs to be checked...</div><div><br><div class=3D=
"gmail_quote">On Wed, Jun 17, 2015 at 9:46 PM, Richard Smith <span dir=3D"l=
tr"><<a rel=3D"nofollow">ric...@metafoo.co.uk</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"><div><div class=3D"gmail_quo=
te"><span>On Wed, Jun 17, 2015 at 1:38 PM, Roland Bock <span dir=3D"ltr">&l=
t;<a rel=3D"nofollow">rb...@eudoxos.de</a>></span> wrote:<br><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF"><span>
<div>On 2015-06-17 20:44, Richard Smith
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>
<div class=3D"gmail_quote">On Wed, Jun 17, 2015 at 12:19 AM,
Roland Bock <span dir=3D"ltr"><<a rel=3D"nofollow">rb...@eud=
oxos.de</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 text=3D"#000000" bgcolor=3D"#FFFFFF"><span>
<div>On 2015-06-16 23:42, Richard Smith wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>
<div class=3D"gmail_quote">On Tue, Jun 16, 2015 at
1:12 AM, Roland Bock <span dir=3D"ltr"><<a rel=
=3D"nofollow">rb...@eudoxos.de</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 text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>Boost::Hana provides a user-defined
literal that I would like to use to
define a compile time string in a
header.<br>
<br>
See <a href=3D"http://ldionne.com/hana/stru=
ctboost_1_1hana_1_1String.html#ad77f7afff008c2ce15739ad16a8bf0a8" rel=3D"no=
follow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com=
/url?q\75http%3A%2F%2Fldionne.com%2Fhana%2Fstructboost_1_1hana_1_1String.ht=
ml%23ad77f7afff008c2ce15739ad16a8bf0a8\46sa\75D\46sntz\0751\46usg\75AFQjCNH=
DkIzQ9evLICl3UR5amXZWF5U79A';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\75http%3A%2F%2Fldionne.com%2Fhana%2Fstructboost_1_1hana=
_1_1String.html%23ad77f7afff008c2ce15739ad16a8bf0a8\46sa\75D\46sntz\0751\46=
usg\75AFQjCNHDkIzQ9evLICl3UR5amXZWF5U79A';return true;">http://ldionne.com/=
hana/<wbr>structboost_1_1hana_1_1String.<wbr>html#<wbr>ad77f7afff008c2ce157=
39ad16a8bf<wbr>0a8</a><br>
<br>
I would really like to say <br>
<br>
struct A<br>
{<br>
using name_t =3D decltype("sam=
ple"_s);<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>If we remove the (now-redundant)
restriction on lambdas in unevaluated
operands, you could write:</div>
</div>
</div>
</div>
</blockquote>
</span> Are there plans/proposals to do that? I stumbled
over this restriction quite a few times.</div>
</blockquote>
<div><br>
</div>
<div>I don't think it's on the core issues list. We
discussed it while working on core issue 1607, but I think
we thought it would be best handled separately.</div>
</div>
</div>
</div>
</blockquote></span>
Can you give me a pointer as to why the restriction is redundant
now?<br></div></blockquote><div><br></div></span><div>See core issue 16=
07. The purpose of the restriction was to avoid lambda-expressions appearin=
g in a signature (so that implementations don't need to implement declarati=
on / statement SFINAE and don't need to mangle them), but it was neither ne=
cessary nor sufficient for that. The new rules in core issue 1607 don't nee=
d this restriction to implement that intent.</div></div></div></div><div><d=
iv>
<p></p>
-- <br>
<br>
--- <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 rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=
=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';return true=
;" onclick=3D"this.href=3D'http://groups.google.com/a/isocpp.org/group/std-=
proposals/';return true;">http://groups.google.com/a/<wbr>isocpp.org/group/=
std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div></div></blockquote></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_402_296573944.1434689043011--
------=_Part_401_471117319.1434689043011--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Thu, 18 Jun 2015 22:20:01 -0700
Raw View
--047d7bacb0ee6ea7270518d813d5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thu, Jun 18, 2015 at 9:44 PM, Tomasz <tomaszkam@gmail.com> wrote:
> W dniu pi=C4=85tek, 19 czerwca 2015 02:21:54 UTC+2 u=C5=BCytkownik Arthur=
O'Dwyer
> napisa=C5=82:
>>
>>
>> User-defined literals are a mess added on top of the pre-existing mess o=
f
>> literal prefixes and suffixes, and perhaps the best thing to do is just
>> stay far away from them...?
>>
>
> I do not agree with that point.
>
[...] However in the current form they are not really usable [...] unable
> to resolve ambiguity [...] we have only avoided the problem by reserving
> names that does not start "_" for standard library - such solution is not
> viable for other libraries [...] the user cannot simply invoke operator""
> literal instead of using 123litterals, because they will need to know whi=
ch
> form is used:
> operator"" literal(123);
> operator"" literal("123");
> operator"" literal<'1', '2', '3'>(); //The 3rd form is hardly to be
> considered usable outside of automatic compiler calls.
>
It sounds to me as if you *do* agree with my point. :D
Here's a thought experiment: What if, instead of having to write something
like std::"Hello"s to construct a string, we could use the more
functional-style notation std::s("Hello")? Such "functional-notation
literals" could reuse the existing rules for overload resolution (we could
get rid of the three different forms of operator"") and wouldn't lead us
into any weird corner cases in the grammar. We could even exploit function
overloading to make std::s(42) mean "42 seconds" and std::s("Hello") mean
"a string with value Hello"... although from the programmer's point of view
it might be preferable in practice to disambiguate by spelling out the
words =E2=80=94 std::s*econds*(42) and std::s*tring*("Hello") respectively =
=E2=80=94 so
we'd like to make that possible, too.
Now what if I told you that the capability for this elegant form of literal
notation has existed in C++ since 1998?! :)
I'll admit, UDLs did make it possible for 42_c to mean
std::integral_constant<int,42>{}; that is, UDLs are pretty much the only
way (besides a macro) to wrap a value in angle brackets without actually
writing a pair of angle brackets in the code. But if we'd started with that
goal actually in mind, would we have settled on UDLs as the right way to
achieve it?
=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/.
--047d7bacb0ee6ea7270518d813d5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Jun 18, 2015 at 9:44 PM, Tomasz <span dir=3D"ltr">=
<<a href=3D"mailto:tomaszkam@gmail.com" target=3D"_blank">tomaszkam@gmai=
l.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex"><div dir=3D"ltr">W dniu pi=C4=85tek, 19 czerwca =
2015 02:21:54 UTC+2 u=C5=BCytkownik Arthur O'Dwyer napisa=C5=82:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-=
left:1ex"><div dir=3D"ltr"><br><div>User-defined literals are a mess added =
on top of the pre-existing mess of literal prefixes and suffixes, and perha=
ps the best thing to do is just stay far away from them...?</div></div></bl=
ockquote><div><br>I do not agree with that point.</div></div></blockquote><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div> [...] However in the current form th=
ey are not really usable [...] unable to resolve ambiguity [...] we have on=
ly avoided the problem by reserving names that does not start "_"=
for standard library - such solution is not viable for other libraries [..=
..]=C2=A0the user cannot simply invoke operator"" literal instead =
of using 123litterals, because they will need to know which form is used:<b=
r>operator"" literal(123);<br>operator"" literal("=
123");<br>operator"" literal<'1', '2', &#=
39;3'>(); //The 3rd form is hardly to be considered usable outside o=
f automatic compiler calls.</div></div></blockquote><div><br></div><div>It =
sounds to me as if you <i>do</i> agree with my point. :D</div><div><br></di=
v><div>Here's a thought experiment: What if, instead of having to write=
something like=C2=A0<font face=3D"monospace, monospace">std::"Hello&q=
uot;s</font>=C2=A0to construct a string, we could use the more functional-s=
tyle notation <font face=3D"monospace, monospace">std::s("Hello")=
</font>? Such "functional-notation literals" could reuse the exis=
ting rules for overload resolution (we could get rid of the three different=
forms of <font face=3D"monospace, monospace">operator""</font>) =
and wouldn't lead us into any weird corner cases in the grammar. We cou=
ld even exploit function overloading to make <font face=3D"monospace, monos=
pace">std::s(42)</font> mean "42 seconds" and <font face=3D"monos=
pace, monospace">std::s("Hello")</font> mean "a string with =
value Hello"... although from the programmer's point of view it mi=
ght be preferable in practice to disambiguate by spelling out the words =E2=
=80=94 <font face=3D"monospace, monospace">std::s<b>econds</b>(42)</font> a=
nd <font face=3D"monospace, monospace">std::s<b>tring</b>("Hello"=
)</font> respectively =E2=80=94 so we'd like to make that possible, too=
..</div><div>Now what if I told you that the capability for this elegant for=
m of literal notation has existed in C++ since 1998?! :)</div><div><br></di=
v><div>I'll admit, UDLs did make it possible for <font face=3D"monospac=
e, monospace">42_c</font> to mean <font face=3D"monospace, monospace">std::=
integral_constant<int,42>{}</font>; that is, UDLs are pretty much the=
only way (besides a macro) to wrap a value in angle brackets without actua=
lly writing a pair of angle brackets in the code. But if we'd started w=
ith that goal actually in mind, would we have settled on UDLs as the right =
way to achieve it?</div><div><br></div><div>=E2=80=93Arthur</div></div></di=
v></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 />
--047d7bacb0ee6ea7270518d813d5--
.
Author: =?UTF-8?Q?Tomasz_Kami=C5=84ski?= <tomaszkam@gmail.com>
Date: Fri, 19 Jun 2015 11:14:35 +0200
Raw View
--001a113dccec511f600518db5a14
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Using funciton syntax namespace::literal(value), i.e. std::s("Hello") will
cause confilicts with the objects/functions named as literal declared in
the namespace. Notice that you currently can define both function or object
named s and operator""s in single namespace.
2015-06-19 7:20 GMT+02:00 Arthur O'Dwyer <arthur.j.odwyer@gmail.com>:
> On Thu, Jun 18, 2015 at 9:44 PM, Tomasz <tomaszkam@gmail.com> wrote:
>
>> W dniu pi=C4=85tek, 19 czerwca 2015 02:21:54 UTC+2 u=C5=BCytkownik Arthu=
r O'Dwyer
>> napisa=C5=82:
>>>
>>>
>>> User-defined literals are a mess added on top of the pre-existing mess
>>> of literal prefixes and suffixes, and perhaps the best thing to do is j=
ust
>>> stay far away from them...?
>>>
>>
>> I do not agree with that point.
>>
> [...] However in the current form they are not really usable [...] unable
>> to resolve ambiguity [...] we have only avoided the problem by reserving
>> names that does not start "_" for standard library - such solution is no=
t
>> viable for other libraries [...] the user cannot simply invoke operator"=
"
>> literal instead of using 123litterals, because they will need to know wh=
ich
>> form is used:
>> operator"" literal(123);
>> operator"" literal("123");
>> operator"" literal<'1', '2', '3'>(); //The 3rd form is hardly to be
>> considered usable outside of automatic compiler calls.
>>
>
> It sounds to me as if you *do* agree with my point. :D
>
> Here's a thought experiment: What if, instead of having to write somethin=
g
> like std::"Hello"s to construct a string, we could use the more
> functional-style notation std::s("Hello")? Such "functional-notation
> literals" could reuse the existing rules for overload resolution (we coul=
d
> get rid of the three different forms of operator"") and wouldn't lead us
> into any weird corner cases in the grammar. We could even exploit functio=
n
> overloading to make std::s(42) mean "42 seconds" and std::s("Hello") mean
> "a string with value Hello"... although from the programmer's point of vi=
ew
> it might be preferable in practice to disambiguate by spelling out the
> words =E2=80=94 std::s*econds*(42) and std::s*tring*("Hello") respectivel=
y =E2=80=94 so
> we'd like to make that possible, too.
> Now what if I told you that the capability for this elegant form of
> literal notation has existed in C++ since 1998?! :)
>
> I'll admit, UDLs did make it possible for 42_c to mean
> std::integral_constant<int,42>{}; that is, UDLs are pretty much the only
> way (besides a macro) to wrap a value in angle brackets without actually
> writing a pair of angle brackets in the code. But if we'd started with th=
at
> goal actually in mind, would we have settled on UDLs as the right way to
> achieve it?
>
> =E2=80=93Arthur
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/hAnVRTlsQZY/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/.
>
--=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/.
--001a113dccec511f600518db5a14
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Using funciton syntax namespace::literal(value), i.e. std:=
:s("Hello") will cause confilicts with the objects/functions name=
d as literal declared in the namespace. Notice that you currently can defin=
e both function or object named s and operator""s in single names=
pace. <br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2=
015-06-19 7:20 GMT+02:00 Arthur O'Dwyer <span dir=3D"ltr"><<a href=
=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gma=
il.com</a>></span>:<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"><=
span class=3D"">On Thu, Jun 18, 2015 at 9:44 PM, Tomasz <span dir=3D"ltr">&=
lt;<a href=3D"mailto:tomaszkam@gmail.com" target=3D"_blank">tomaszkam@gmail=
..com</a>></span> wrote:<br></span><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">W dni=
u pi=C4=85tek, 19 czerwca 2015 02:21:54 UTC+2 u=C5=BCytkownik Arthur O'=
Dwyer napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 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"><br><div>User-defined =
literals are a mess added on top of the pre-existing mess of literal prefix=
es and suffixes, and perhaps the best thing to do is just stay far away fro=
m them...?</div></div></blockquote><div><br>I do not agree with that point.=
</div></div></blockquote></span><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div> [..=
..] However in the current form they are not really usable [...] unable to r=
esolve ambiguity [...] we have only avoided the problem by reserving names =
that does not start "_" for standard library - such solution is n=
ot viable for other libraries [...]=C2=A0the user cannot simply invoke oper=
ator"" literal instead of using 123litterals, because they will n=
eed to know which form is used:<span class=3D""><br>operator"" li=
teral(123);<br>operator"" literal("123");<br>operator&q=
uot;" literal<'1', '2', '3'>(); //The 3r=
d form is hardly to be considered usable outside of automatic compiler call=
s.</span></div></div></blockquote><div><br></div><div>It sounds to me as if=
you <i>do</i> agree with my point. :D</div><div><br></div><div>Here's =
a thought experiment: What if, instead of having to write something like=C2=
=A0<font face=3D"monospace, monospace">std::"Hello"s</font>=C2=A0=
to construct a string, we could use the more functional-style notation <fon=
t face=3D"monospace, monospace">std::s("Hello")</font>? Such &quo=
t;functional-notation literals" could reuse the existing rules for ove=
rload resolution (we could get rid of the three different forms of <font fa=
ce=3D"monospace, monospace">operator""</font>) and wouldn't l=
ead us into any weird corner cases in the grammar. We could even exploit fu=
nction overloading to make <font face=3D"monospace, monospace">std::s(42)</=
font> mean "42 seconds" and <font face=3D"monospace, monospace">s=
td::s("Hello")</font> mean "a string with value Hello".=
... although from the programmer's point of view it might be preferable =
in practice to disambiguate by spelling out the words =E2=80=94 <font face=
=3D"monospace, monospace">std::s<b>econds</b>(42)</font> and <font face=3D"=
monospace, monospace">std::s<b>tring</b>("Hello")</font> respecti=
vely =E2=80=94 so we'd like to make that possible, too.</div><div>Now w=
hat if I told you that the capability for this elegant form of literal nota=
tion has existed in C++ since 1998?! :)</div><div><br></div><div>I'll a=
dmit, UDLs did make it possible for <font face=3D"monospace, monospace">42_=
c</font> to mean <font face=3D"monospace, monospace">std::integral_constant=
<int,42>{}</font>; that is, UDLs are pretty much the only way (beside=
s a macro) to wrap a value in angle brackets without actually writing a pai=
r of angle brackets in the code. But if we'd started with that goal act=
ually in mind, would we have settled on UDLs as the right way to achieve it=
?</div><span class=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div>=
=E2=80=93Arthur</div></font></span></div></div></div><div class=3D"HOEnZb">=
<div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/hAnVRTlsQZY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/hAnVRTlsQZY=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a113dccec511f600518db5a14--
.
Author: =?UTF-8?Q?Tomasz_Kami=C5=84ski?= <tomaszkam@gmail.com>
Date: Fri, 19 Jun 2015 11:23:10 +0200
Raw View
--047d7b4725ee040ed20518db79f2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Using the literal is only way to intialize variable class integer class
(like big int) with arbitrally large number. Using
bigint("123456767435343453454") requires parsing at runtime, and
bigint(123456767435343453454) rerquires that the given number will fit into
largest integer type, i.e. defeat purpose of using bigint.
2015-06-19 11:14 GMT+02:00 Tomasz Kami=C5=84ski <tomaszkam@gmail.com>:
> Using funciton syntax namespace::literal(value), i.e. std::s("Hello") wil=
l
> cause confilicts with the objects/functions named as literal declared in
> the namespace. Notice that you currently can define both function or obje=
ct
> named s and operator""s in single namespace.
>
> 2015-06-19 7:20 GMT+02:00 Arthur O'Dwyer <arthur.j.odwyer@gmail.com>:
>
>> On Thu, Jun 18, 2015 at 9:44 PM, Tomasz <tomaszkam@gmail.com> wrote:
>>
>>> W dniu pi=C4=85tek, 19 czerwca 2015 02:21:54 UTC+2 u=C5=BCytkownik Arth=
ur O'Dwyer
>>> napisa=C5=82:
>>>>
>>>>
>>>> User-defined literals are a mess added on top of the pre-existing mess
>>>> of literal prefixes and suffixes, and perhaps the best thing to do is =
just
>>>> stay far away from them...?
>>>>
>>>
>>> I do not agree with that point.
>>>
>> [...] However in the current form they are not really usable [...] unabl=
e
>>> to resolve ambiguity [...] we have only avoided the problem by reservin=
g
>>> names that does not start "_" for standard library - such solution is n=
ot
>>> viable for other libraries [...] the user cannot simply invoke operator=
""
>>> literal instead of using 123litterals, because they will need to know w=
hich
>>> form is used:
>>> operator"" literal(123);
>>> operator"" literal("123");
>>> operator"" literal<'1', '2', '3'>(); //The 3rd form is hardly to be
>>> considered usable outside of automatic compiler calls.
>>>
>>
>> It sounds to me as if you *do* agree with my point. :D
>>
>> Here's a thought experiment: What if, instead of having to write
>> something like std::"Hello"s to construct a string, we could use the
>> more functional-style notation std::s("Hello")? Such
>> "functional-notation literals" could reuse the existing rules for overlo=
ad
>> resolution (we could get rid of the three different forms of operator"")
>> and wouldn't lead us into any weird corner cases in the grammar. We coul=
d
>> even exploit function overloading to make std::s(42) mean "42 seconds"
>> and std::s("Hello") mean "a string with value Hello"... although from
>> the programmer's point of view it might be preferable in practice to
>> disambiguate by spelling out the words =E2=80=94 std::s*econds*(42) and =
std::s
>> *tring*("Hello") respectively =E2=80=94 so we'd like to make that possib=
le, too.
>> Now what if I told you that the capability for this elegant form of
>> literal notation has existed in C++ since 1998?! :)
>>
>> I'll admit, UDLs did make it possible for 42_c to mean
>> std::integral_constant<int,42>{}; that is, UDLs are pretty much the only
>> way (besides a macro) to wrap a value in angle brackets without actually
>> writing a pair of angle brackets in the code. But if we'd started with t=
hat
>> goal actually in mind, would we have settled on UDLs as the right way to
>> achieve it?
>>
>> =E2=80=93Arthur
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/hAnVRTlsQZY=
/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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/.
>>
>
>
--=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/.
--047d7b4725ee040ed20518db79f2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Using the literal is only way to intialize variable class =
integer class (like big int) with arbitrally large number. Using bigint(&qu=
ot;123456767435343453454") requires parsing at runtime, and bigint(123=
456767435343453454) rerquires that the given number will fit into largest i=
nteger type, i.e. defeat purpose of using bigint.<br></div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">2015-06-19 11:14 GMT+02:00 Tomasz=
Kami=C5=84ski <span dir=3D"ltr"><<a href=3D"mailto:tomaszkam@gmail.com"=
target=3D"_blank">tomaszkam@gmail.com</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">Using funciton syntax namespace::literal(val=
ue), i.e. std::s("Hello") will cause confilicts with the objects/=
functions named as literal declared in the namespace. Notice that you curre=
ntly can define both function or object named s and operator""s i=
n single namespace. <br></div><div class=3D"HOEnZb"><div class=3D"h5"><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">2015-06-19 7:20 GMT+02=
:00 Arthur O'Dwyer <span dir=3D"ltr"><<a href=3D"mailto:arthur.j.odw=
yer@gmail.com" target=3D"_blank">arthur.j.odwyer@gmail.com</a>></span>:<=
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"><span>On Thu, Jun 18, 20=
15 at 9:44 PM, Tomasz <span dir=3D"ltr"><<a href=3D"mailto:tomaszkam@gma=
il.com" target=3D"_blank">tomaszkam@gmail.com</a>></span> wrote:<br></sp=
an><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex"><div dir=3D"ltr">W dniu pi=C4=85tek, 19 czerwca 2015 02:21:54 UTC+2 u=
=C5=BCytkownik Arthur O'Dwyer napisa=C5=82:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c=
olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D=
"ltr"><br><div>User-defined literals are a mess added on top of the pre-exi=
sting mess of literal prefixes and suffixes, and perhaps the best thing to =
do is just stay far away from them...?</div></div></blockquote><div><br>I d=
o not agree with that point.</div></div></blockquote></span><blockquote cla=
ss=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> [...] However in the current form they are not rea=
lly usable [...] unable to resolve ambiguity [...] we have only avoided the=
problem by reserving names that does not start "_" for standard =
library - such solution is not viable for other libraries [...]=C2=A0the us=
er cannot simply invoke operator"" literal instead of using 123li=
tterals, because they will need to know which form is used:<span><br>operat=
or"" literal(123);<br>operator"" literal("123"=
;);<br>operator"" literal<'1', '2', '3'=
;>(); //The 3rd form is hardly to be considered usable outside of automa=
tic compiler calls.</span></div></div></blockquote><div><br></div><div>It s=
ounds to me as if you <i>do</i> agree with my point. :D</div><div><br></div=
><div>Here's a thought experiment: What if, instead of having to write =
something like=C2=A0<font face=3D"monospace, monospace">std::"Hello&qu=
ot;s</font>=C2=A0to construct a string, we could use the more functional-st=
yle notation <font face=3D"monospace, monospace">std::s("Hello")<=
/font>? Such "functional-notation literals" could reuse the exist=
ing rules for overload resolution (we could get rid of the three different =
forms of <font face=3D"monospace, monospace">operator""</font>) a=
nd wouldn't lead us into any weird corner cases in the grammar. We coul=
d even exploit function overloading to make <font face=3D"monospace, monosp=
ace">std::s(42)</font> mean "42 seconds" and <font face=3D"monosp=
ace, monospace">std::s("Hello")</font> mean "a string with v=
alue Hello"... although from the programmer's point of view it mig=
ht be preferable in practice to disambiguate by spelling out the words =E2=
=80=94 <font face=3D"monospace, monospace">std::s<b>econds</b>(42)</font> a=
nd <font face=3D"monospace, monospace">std::s<b>tring</b>("Hello"=
)</font> respectively =E2=80=94 so we'd like to make that possible, too=
..</div><div>Now what if I told you that the capability for this elegant for=
m of literal notation has existed in C++ since 1998?! :)</div><div><br></di=
v><div>I'll admit, UDLs did make it possible for <font face=3D"monospac=
e, monospace">42_c</font> to mean <font face=3D"monospace, monospace">std::=
integral_constant<int,42>{}</font>; that is, UDLs are pretty much the=
only way (besides a macro) to wrap a value in angle brackets without actua=
lly writing a pair of angle brackets in the code. But if we'd started w=
ith that goal actually in mind, would we have settled on UDLs as the right =
way to achieve it?</div><span><font color=3D"#888888"><div><br></div><div>=
=E2=80=93Arthur</div></font></span></div></div></div><div><div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/hAnVRTlsQZY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/hAnVRTlsQZY=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--047d7b4725ee040ed20518db79f2--
.
Author: David Krauss <potswa@mac.com>
Date: Fri, 19 Jun 2015 20:05:05 +0800
Raw View
--Apple-Mail=_F15BD1E5-9563-46DD-BA4B-FF19A6A3DA1F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Maybe the problem is that breaking a token into a character sequence is a f=
undamental capability that shouldn=E2=80=99t be tied to the special UDL syn=
tax.
Why not let make_bigint< "1234" >() do it? (And, on the way, allow bigintli=
b::operator "" _big< "1234" >() as equivalent to 1234_big.)
> On 2015=E2=80=9306=E2=80=9319, at 5:23 PM, Tomasz Kami=C5=84ski <tomaszka=
m@gmail.com> wrote:
>=20
> Using the literal is only way to intialize variable class integer class (=
like big int) with arbitrally large number. Using bigint("12345676743534345=
3454") requires parsing at runtime, and bigint(123456767435343453454) rerqu=
ires that the given number will fit into largest integer type, i.e. defeat =
purpose of using bigint.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_F15BD1E5-9563-46DD-BA4B-FF19A6A3DA1F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div class=3D"">Ma=
ybe the problem is that breaking a token into a character sequence is a fun=
damental capability that shouldn=E2=80=99t be tied to the special UDL synta=
x.</div><div class=3D""><br class=3D""></div><div class=3D"">Why not let <f=
ont face=3D"Courier" class=3D"">make_bigint< "1234" >()</font> do it?=
(And, on the way, allow <font face=3D"Courier" class=3D"">bigintlib::opera=
tor "" _big< "1234" >()</font> as equivalent to <font face=3D"Co=
urier" class=3D"">1234_big</font>.)</div><br class=3D""><div><blockquote ty=
pe=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=E2=80=9319, at 5:=
23 PM, Tomasz Kami=C5=84ski <<a href=3D"mailto:tomaszkam@gmail.com" clas=
s=3D"">tomaszkam@gmail.com</a>> wrote:</div><br class=3D"Apple-interchan=
ge-newline"><div class=3D""><div dir=3D"ltr" class=3D"">Using the literal i=
s only way to intialize variable class integer class (like big int) with ar=
bitrally large number. Using bigint("123456767435343453454") requires parsi=
ng at runtime, and bigint(123456767435343453454) rerquires that the given n=
umber will fit into largest integer type, i.e. defeat purpose of using bigi=
nt.<br class=3D""></div></div></blockquote></div><br class=3D""></body></ht=
ml>
<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 />
--Apple-Mail=_F15BD1E5-9563-46DD-BA4B-FF19A6A3DA1F--
.
Author: =?UTF-8?Q?Tomasz_Kami=C5=84ski?= <tomaszkam@gmail.com>
Date: Fri, 19 Jun 2015 15:04:19 +0200
Raw View
--001a113dcceceba6620518de8f12
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I do not consider the make_bigint< "1234" >(), to be as readable and user
friendly as 1234_big, which I consider as argument for having user-defined
literals in the language. But I belive that requires to support some form
of qualified literals type, to allow library creators to provide resonable
literal for thier types, without causing ambiguity problems for users that
combines multiple libraries in single program. Reserving certain preffix
for suffix is not an scalable option.
2015-06-19 14:05 GMT+02:00 David Krauss <potswa@mac.com>:
> Maybe the problem is that breaking a token into a character sequence is a
> fundamental capability that shouldn=E2=80=99t be tied to the special UDL =
syntax.
>
> Why not let make_bigint< "1234" >() do it? (And, on the way, allow bigint=
lib::operator
> "" _big< "1234" >() as equivalent to 1234_big.)
>
> On 2015=E2=80=9306=E2=80=9319, at 5:23 PM, Tomasz Kami=C5=84ski <tomaszka=
m@gmail.com> wrote:
>
> Using the literal is only way to intialize variable class integer class
> (like big int) with arbitrally large number. Using
> bigint("123456767435343453454") requires parsing at runtime, and
> bigint(123456767435343453454) rerquires that the given number will fit in=
to
> largest integer type, i.e. defeat purpose of using bigint.
>
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/hAnVRTlsQZY/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/.
>
--=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/.
--001a113dcceceba6620518de8f12
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-family:arial,helvetica,sans-serif">I d=
o not consider the </span><font face=3D"Courier"><span style=3D"font-famil=
y:arial,helvetica,sans-serif">make_bigint< "1234" >(), to b=
e as readable and user friendly as 1234_big, which I consider as argument f=
or having user-defined literals in the language. But I belive that requires=
to support some form of qualified literals type, to allow library creators=
to provide resonable literal for thier types, without causing ambiguity pr=
oblems for users that combines multiple libraries in single program. Reserv=
ing certain preffix for suffix is not an scalable option.</span><br></font>=
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2015-06-19 =
14:05 GMT+02:00 David Krauss <span dir=3D"ltr"><<a href=3D"mailto:potswa=
@mac.com" target=3D"_blank">potswa@mac.com</a>></span>:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div style=3D"word-wrap:break-word"><div>Maybe the proble=
m is that breaking a token into a character sequence is a fundamental capab=
ility that shouldn=E2=80=99t be tied to the special UDL syntax.</div><div><=
br></div><div>Why not let <font face=3D"Courier">make_bigint< "1234=
" >()</font> do it? (And, on the way, allow <font face=3D"Courier">=
bigintlib::operator "" _big< "1234" >()</font>=C2=
=A0as equivalent to <font face=3D"Courier">1234_big</font>.)</div><span cla=
ss=3D""><br><div><blockquote type=3D"cite"><div>On 2015=E2=80=9306=E2=80=93=
19, at 5:23 PM, Tomasz Kami=C5=84ski <<a href=3D"mailto:tomaszkam@gmail.=
com" target=3D"_blank">tomaszkam@gmail.com</a>> wrote:</div><br><div><di=
v dir=3D"ltr">Using the literal is only way to intialize variable class int=
eger class (like big int) with arbitrally large number. Using bigint("=
123456767435343453454") requires parsing at runtime, and bigint(123456=
767435343453454) rerquires that the given number will fit into largest inte=
ger type, i.e. defeat purpose of using bigint.<br></div></div></blockquote>=
</div><br></span></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/hAnVRTlsQZY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/hAnVRTlsQZY=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a113dcceceba6620518de8f12--
.
Author: Sam Kellett <samkellett@gmail.com>
Date: Fri, 19 Jun 2015 14:24:52 +0100
Raw View
--001a1134933262c8bd0518ded945
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 19 June 2015 at 14:04, Tomasz Kami=C5=84ski <tomaszkam@gmail.com> wrote:
> I do not consider the make_bigint< "1234" >(), to be as readable and user
> friendly as 1234_big, which I consider as argument for having user-define=
d
> literals in the language. But I belive that requires to support some form
> of qualified literals type, to allow library creators to provide resonabl=
e
> literal for thier types, without causing ambiguity problems for users tha=
t
> combines multiple libraries in single program. Reserving certain preffix
> for suffix is not an scalable option.
>
>
This is just an idea that popped into my head, but would it be reasonable
to split up the tokens of a literal so that the namespace comes in between
the UDL prefix and the specified suffix?
For example:
"delta"_boost::hana::s
namespace hana =3D boost::hana;
"delta"_hana::s
1234_bigintlib::big
I dunno, seems a more logical place for the namespace to go rather than the
beginning (like, where else does that happen?!).
--=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/.
--001a1134933262c8bd0518ded945
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 1=
9 June 2015 at 14:04, Tomasz Kami=C5=84ski <span dir=3D"ltr"><<a href=3D=
"mailto:tomaszkam@gmail.com" target=3D"_blank">tomaszkam@gmail.com</a>><=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span styl=
e=3D"font-family:arial,helvetica,sans-serif">I do not consider the </span>=
<font face=3D"Courier"><span style=3D"font-family:arial,helvetica,sans-seri=
f">make_bigint< "1234" >(), to be as readable and user frie=
ndly as 1234_big, which I consider as argument for having user-defined lite=
rals in the language. But I belive that requires to support some form of qu=
alified literals type, to allow library creators to provide resonable liter=
al for thier types, without causing ambiguity problems for users that combi=
nes multiple libraries in single program. Reserving certain preffix for suf=
fix is not an scalable option.</span><br></font></div><br></blockquote><div=
><br></div><div>This is just an idea that popped into my head, but would it=
be reasonable to split up the tokens of a literal so that the namespace co=
mes in between the UDL prefix and the specified suffix?<br><br></div><div>F=
or example:<br><br></div><div>=C2=A0=C2=A0=C2=A0 "delta"_boost::h=
ana::s<br><br></div><div>=C2=A0=C2=A0=C2=A0 namespace hana =3D boost::hana;=
<br></div><div>=C2=A0=C2=A0=C2=A0 "delta"_hana::s</div><div><br><=
/div><div>=C2=A0=C2=A0=C2=A0 1234_bigintlib::big<br><br></div><div>I dunno,=
seems a more logical place for the namespace to go rather than the beginni=
ng (like, where else does that happen?!). <br></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 />
--001a1134933262c8bd0518ded945--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Fri, 19 Jun 2015 15:36:38 +0200
Raw View
This is a multi-part message in MIME format.
--------------070004000308000804040608
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 2015-06-19 07:20, Arthur O'Dwyer wrote:
> On Thu, Jun 18, 2015 at 9:44 PM, Tomasz <tomaszkam@gmail.com
> <mailto:tomaszkam@gmail.com>> wrote:
>
> W dniu pi=C4=85tek, 19 czerwca 2015 02:21:54 UTC+2 u=C5=BCytkownik Ar=
thur
> O'Dwyer napisa=C5=82:
>
>
> User-defined literals are a mess added on top of the
> pre-existing mess of literal prefixes and suffixes, and
> perhaps the best thing to do is just stay far away from them...?
>
>
> I do not agree with that point.
>
> [...] However in the current form they are not really usable [...]
> unable to resolve ambiguity [...] we have only avoided the problem
> by reserving names that does not start "_" for standard library -
> such solution is not viable for other libraries [...] the user
> cannot simply invoke operator"" literal instead of using
> 123litterals, because they will need to know which form is used:
> operator"" literal(123);
> operator"" literal("123");
> operator"" literal<'1', '2', '3'>(); //The 3rd form is hardly to
> be considered usable outside of automatic compiler calls.
>
>
> It sounds to me as if you /do/ agree with my point. :D
>
> Here's a thought experiment: What if, instead of having to write
> something like std::"Hello"s to construct a string, we could use the
> more functional-style notation std::s("Hello")? Such
> "functional-notation literals" could reuse the existing rules for
> overload resolution (we could get rid of the three different forms of
> operator"") and wouldn't lead us into any weird corner cases in the
> grammar. We could even exploit function overloading to make std::s(42)
> mean "42 seconds" and std::s("Hello") mean "a string with value
> Hello"... although from the programmer's point of view it might be
> preferable in practice to disambiguate by spelling out the words =E2=80=
=94
> std::s*econds*(42) and std::s*tring*("Hello") respectively =E2=80=94 so w=
e'd
> like to make that possible, too.
> Now what if I told you that the capability for this elegant form of
> literal notation has existed in C++ since 1998?! :)
The difference being that in case of a string UDL, the compiler adds a
second argument (the size).
>
> I'll admit, UDLs did make it possible for 42_c to mean
> std::integral_constant<int,42>{}; that is, UDLs are pretty much the
> only way (besides a macro) to wrap a value in angle brackets without
> actually writing a pair of angle brackets in the code. But if we'd
> started with that goal actually in mind, would we have settled on UDLs
> as the right way to achieve it?
Considering that my starting point was boost::hana::operator""_s which
turns "delta" into boost::hana::string<'d','e','l','t','a'>{}, this
certainly is a very valid point :-)
For that use case I'd be happy with anything that I could use like this,
too:
struct A
{
static constexpr auto name =3D make_compile_time_string("whatever");
};
or
struct B
{
using name_t =3D make_compile_time_string<"whatever">;
};
make_compile_time_string should NOT be a macro, of course :-)
Best,
Roland
--=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/.
--------------070004000308000804040608
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">On 2015-06-19 07:20, Arthur O'Dwyer
wrote:<br>
</div>
<blockquote
cite=3D"mid:CADvuK0Lx_s1+pYVRek=3DPV7bTHTGmaODXXxsM53xQHvSHCtWvLw@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">On Thu, Jun 18, 2015 at 9:44 PM, Tomasz <span
dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:tomaszkam@gmail.com" target=3D"_blank">tomaszkam=
@gmail.com</a>></span>
wrote:<br>
<div class=3D"gmail_extra">
<div class=3D"gmail_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-=
style:solid;padding-left:1ex">
<div dir=3D"ltr">W dniu pi=C4=85tek, 19 czerwca 2015 02:21:54
UTC+2 u=C5=BCytkownik Arthur O'Dwyer napisa=C5=82:
<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"><br>
<div>User-defined literals are a mess added on top
of the pre-existing mess of literal prefixes and
suffixes, and perhaps the best thing to do is just
stay far away from them...?</div>
</div>
</blockquote>
<div><br>
I do not agree with that point.</div>
</div>
</blockquote>
<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> [...] However in the current form they are not
really usable [...] unable to resolve ambiguity [...]
we have only avoided the problem by reserving names
that does not start "_" for standard library - such
solution is not viable for other libraries [...]=C2=A0the
user cannot simply invoke operator"" literal instead
of using 123litterals, because they will need to know
which form is used:<br>
operator"" literal(123);<br>
operator"" literal("123");<br>
operator"" literal<'1', '2', '3'>(); //The 3rd
form is hardly to be considered usable outside of
automatic compiler calls.</div>
</div>
</blockquote>
<div><br>
</div>
<div>It sounds to me as if you <i>do</i> agree with my
point. :D</div>
<div><br>
</div>
<div>Here's a thought experiment: What if, instead of having
to write something like=C2=A0<font face=3D"monospace, monospa=
ce">std::"Hello"s</font>=C2=A0to
construct a string, we could use the more functional-style
notation <font face=3D"monospace, monospace">std::s("Hello")<=
/font>?
Such "functional-notation literals" could reuse the
existing rules for overload resolution (we could get rid
of the three different forms of <font face=3D"monospace,
monospace">operator""</font>) and wouldn't lead us into
any weird corner cases in the grammar. We could even
exploit function overloading to make <font
face=3D"monospace, monospace">std::s(42)</font> mean "42
seconds" and <font face=3D"monospace, monospace">std::s("Hell=
o")</font>
mean "a string with value Hello"... although from the
programmer's point of view it might be preferable in
practice to disambiguate by spelling out the words =E2=80=94 =
<font
face=3D"monospace, monospace">std::s<b>econds</b>(42)</font=
>
and <font face=3D"monospace, monospace">std::s<b>tring</b>("H=
ello")</font>
respectively =E2=80=94 so we'd like to make that possible, to=
o.</div>
<div>Now what if I told you that the capability for this
elegant form of literal notation has existed in C++ since
1998?! :)</div>
</div>
</div>
</div>
</blockquote>
The difference being that in case of a string UDL, the compiler adds
a second argument (the size).<br>
<br>
<blockquote
cite=3D"mid:CADvuK0Lx_s1+pYVRek=3DPV7bTHTGmaODXXxsM53xQHvSHCtWvLw@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div><br>
</div>
<div>I'll admit, UDLs did make it possible for <font
face=3D"monospace, monospace">42_c</font> to mean <font
face=3D"monospace, monospace">std::integral_constant<int=
,42>{}</font>;
that is, UDLs are pretty much the only way (besides a
macro) to wrap a value in angle brackets without actually
writing a pair of angle brackets in the code. But if we'd
started with that goal actually in mind, would we have
settled on UDLs as the right way to achieve it?</div>
</div>
</div>
</div>
</blockquote>
<br>
Considering that my starting point was boost::hana::operator""_s
which turns "delta" into
boost::hana::string<'d','e','l','t','a'>{}, this certainly is
a very valid point :-)<br>
<br>
For that use case I'd be happy with anything that I could use like
this, too:<br>
<br>
struct A<br>
{<br>
=C2=A0=C2=A0 static constexpr auto name =3D
make_compile_time_string("whatever");<br>
};<br>
<br>
or <br>
<br>
struct B<br>
{<br>
=C2=A0=C2=A0 using name_t =3D make_compile_time_string<"whatever">=
;;<br>
};<br>
<br>
make_compile_time_string should NOT be a macro, of course :-)<br>
<br>
<br>
Best,<br>
<br>
Roland<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--------------070004000308000804040608--
.
Author: Tomasz <tomaszkam@gmail.com>
Date: Fri, 19 Jun 2015 07:37:59 -0700 (PDT)
Raw View
------=_Part_470_1319516865.1434724679116
Content-Type: multipart/alternative;
boundary="----=_Part_471_56327486.1434724679116"
------=_Part_471_56327486.1434724679116
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu pi=C4=85tek, 19 czerwca 2015 15:24:55 UTC+2 u=C5=BCytkownik Sam Kell=
ett=20
napisa=C5=82:
>
> I dunno, seems a more logical place for the namespace to go rather than=
=20
> the beginning (like, where else does that happen?!).=20
>
If I have function in the namespace, and I want to call it, I place the=20
namespace before its name (std::begin(c)). If I have constant or variable,=
=20
I also place the namespace before it (std::placeholders::_1), so then if I=
=20
have a object created using literal ("hello"s), then I should place=20
namespace before it to qualify (std::"hello"s). There is no entity named s=
=20
in the std::literals::string_literals namespace.
--=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_471_56327486.1434724679116
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>W dniu pi=C4=85tek, 19 czerwca 2015 15:24:55 UTC+2 u=
=C5=BCytkownik Sam Kellett napisa=C5=82:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>I dunno, se=
ems a more logical place for the namespace to go rather than the beginning =
(like, where else does that happen?!). <br></div></div></div></div></blockq=
uote><div><br>If I have function in the namespace, and I want to call it, I=
place the namespace before its name (std::begin(c)). If I have constant or=
variable, I also place the namespace before it (std::placeholders::_1), so=
then if I have a object created using literal ("hello"s), then I should pl=
ace namespace before it to qualify (std::"hello"s). There is no entity name=
d s in the std::literals::string_literals namespace.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_471_56327486.1434724679116--
------=_Part_470_1319516865.1434724679116--
.
Author: Max Truxa <me@maxtruxa.com>
Date: Sun, 21 Jun 2015 23:16:44 -0700 (PDT)
Raw View
------=_Part_2235_486191883.1434953804186
Content-Type: text/plain; charset=UTF-8
std::""s is just illogical. Even going by your own logic. It's s that is in std not ""s.
--
---
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_2235_486191883.1434953804186--
.
Author: Tomasz <tomaszkam@gmail.com>
Date: Mon, 22 Jun 2015 00:18:59 -0700 (PDT)
Raw View
------=_Part_2827_2029519292.1434957539996
Content-Type: multipart/alternative;
boundary="----=_Part_2828_1647975343.1434957539996"
------=_Part_2828_1647975343.1434957539996
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu poniedzia=C5=82ek, 22 czerwca 2015 08:16:44 UTC+2 u=C5=BCytkownik Ma=
x Truxa=20
napisa=C5=82:
>
> std::""s is just illogical. Even going by your own logic. It's s that is=
=20
> in std not ""s.
We define operator""s in the namespace std, not the s itself. Please=20
remember that we allow operator ""if to be defined, while there cannot be=
=20
entity named if in any namespace. So the syntax std::if would be=20
incompatible with complex literals. the std::""s, suggest that we want tu=
=20
use operator ""s from std::namespace.
--=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_2828_1647975343.1434957539996
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>W dniu poniedzia=C5=82ek, 22 czerwca 2015 08:16:44 UTC=
+2 u=C5=BCytkownik Max Truxa napisa=C5=82:<blockquote class=3D"gmail_quote"=
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;">std::""s is just illogical. Even going by your own logic. It's =
s that is in std not ""s.</blockquote><div><br>We define operator""s in the=
namespace std, not the s itself. Please remember that we allow operator ""=
if to be defined, while there cannot be entity named if in any namespace. S=
o the syntax std::if would be incompatible with complex literals. the std::=
""s, suggest that we want tu use operator ""s from std::namespace.<br></div=
></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_2828_1647975343.1434957539996--
------=_Part_2827_2029519292.1434957539996--
.
Author: David Krauss <potswa@mac.com>
Date: Mon, 22 Jun 2015 15:47:42 +0800
Raw View
--Apple-Mail=_B64782E3-644B-4724-AD12-408CCA8EA914
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9306=E2=80=9322, at 3:18 PM, Tomasz <tomaszkam@gmail.com> w=
rote:
>=20
> We define operator""s in the namespace std, not the s itself. Please reme=
mber that we allow operator ""if to be defined
More precisely, operator""if is defined in [complex.literals] =C2=A726.4.10=
/4. Users can=E2=80=99t declare things like that, though, because UDL names=
not beginning with an underscore are reserved to the standard.
> , while there cannot be entity named if in any namespace. So the syntax s=
td::if would be incompatible with complex literals. the std::""s, suggest t=
hat we want tu use operator ""s from std::namespace.
There=E2=80=99s no grammatical ambiguity in the case of if, because that ke=
yword can only appear at the beginning of a statement. The only keyword I c=
an think of that can follow :: is template. It=E2=80=99s ugly, though.
UDLs are supposed to provide convenience. Is it really worth reconciling th=
ese tiny identifiers with namespace qualification? Regardless of what a par=
ser can handle, awkwardness negates their purpose. Maybe it=E2=80=99s bette=
r just to ensure that there=E2=80=99s always a qualification-friendly ordin=
ary function call to accomplish the same task.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_B64782E3-644B-4724-AD12-408CCA8EA914
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=
=E2=80=9322, at 3:18 PM, Tomasz <<a href=3D"mailto:tomaszkam@gmail.com" =
class=3D"">tomaszkam@gmail.com</a>> wrote:</div><br class=3D"Apple-inter=
change-newline"><div class=3D""><div dir=3D"ltr" class=3D"">We define opera=
tor""s in the namespace std, not the s itself. Please remember that we allo=
w operator ""if to be defined</div></div></blockquote><div><br class=3D""><=
/div><div>More precisely, <font face=3D"Courier" class=3D"">operator""if</f=
ont> <i class=3D"">is</i> defined in [complex.literals] =C2=A726.4.10/=
4. Users can=E2=80=99t declare things like that, though, because UDL names =
not beginning with an underscore are reserved to the standard.</div><br cla=
ss=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div dir=3D"lt=
r" class=3D""><div class=3D"">, while there cannot be entity named if in an=
y namespace. So the syntax std::if would be incompatible with complex liter=
als. the std::""s, suggest that we want tu use operator ""s from std::names=
pace.<br class=3D""></div></div></div></blockquote><br class=3D""></div><di=
v>There=E2=80=99s no grammatical ambiguity in the case of <font face=3D"Cou=
rier" class=3D"">if</font>, because that keyword can only appear at the beg=
inning of a statement. The only keyword I can think of that can follow =
;<font face=3D"Courier" class=3D"">::</font> is <font face=3D"Courier" clas=
s=3D"">template</font>. It=E2=80=99s ugly, though.</div><br class=3D""><div=
class=3D"">UDLs are supposed to provide convenience. Is it really worth re=
conciling these tiny identifiers with namespace qualification? Regardless o=
f what a parser can handle, awkwardness negates their purpose. Maybe it=E2=
=80=99s better just to ensure that there=E2=80=99s always a qualification-f=
riendly ordinary function call to accomplish the same task.</div></body></h=
tml>
<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 />
--Apple-Mail=_B64782E3-644B-4724-AD12-408CCA8EA914--
.
Author: David Krauss <potswa@mac.com>
Date: Mon, 22 Jun 2015 16:15:25 +0800
Raw View
--Apple-Mail=_BCD0444D-B273-4B55-B0E2-DE97D30CE7FE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9306=E2=80=9322, at 3:47 PM, David Krauss <potswa@mac.com> =
wrote:
>=20
> The only keyword I can think of that can follow :: is template.
Oh, and operator. Who could forget operator "" operator. Let it return a ca=
llable type and you can have R"operator()operator"operator().
Also, some implementations also accept the alternative spellings of punctua=
tion, such as or. The standard is a bit ambiguous about whether these form =
UDLs, since they are forbidden from being identifiers, but only as long as =
they form separate tokens. The intent is probably that they should be reser=
ved.
Point is, qualified lookup is equally hacked whether you allow a literal to=
ken or a keyword on the right-hand side.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_BCD0444D-B273-4B55-B0E2-DE97D30CE7FE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=
=E2=80=9322, at 3:47 PM, David Krauss <<a href=3D"mailto:potswa@mac.com"=
class=3D"">potswa@mac.com</a>> wrote:</div><br class=3D"Apple-interchan=
ge-newline"><div class=3D""><span style=3D"font-family: Helvetica; font-siz=
e: 12px; font-style: normal; font-variant: normal; font-weight: normal; let=
ter-spacing: normal; line-height: normal; orphans: auto; text-align: start;=
text-indent: 0px; text-transform: none; white-space: normal; widows: auto;=
word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: i=
nline !important;" class=3D"">The only keyword I can think of that can foll=
ow </span><font face=3D"Courier" class=3D"" style=3D"font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; letter-spaci=
ng: normal; line-height: normal; orphans: auto; text-align: start; text-ind=
ent: 0px; text-transform: none; white-space: normal; widows: auto; word-spa=
cing: 0px; -webkit-text-stroke-width: 0px;">::</font><span style=3D"font-fa=
mily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal;=
font-weight: normal; letter-spacing: normal; line-height: normal; orphans:=
auto; text-align: start; text-indent: 0px; text-transform: none; white-spa=
ce: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px=
; float: none; display: inline !important;" class=3D""><span class=3D"Apple=
-converted-space"> </span>is<span class=3D"Apple-converted-space">&nbs=
p;</span></span><font face=3D"Courier" class=3D"" style=3D"font-size: 12px;=
font-style: normal; font-variant: normal; font-weight: normal; letter-spac=
ing: normal; line-height: normal; orphans: auto; text-align: start; text-in=
dent: 0px; text-transform: none; white-space: normal; widows: auto; word-sp=
acing: 0px; -webkit-text-stroke-width: 0px;">template</font><span style=3D"=
font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: normal; o=
rphans: auto; text-align: start; text-indent: 0px; text-transform: none; wh=
ite-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-wid=
th: 0px; float: none; display: inline !important;" class=3D"">.</span></div=
></blockquote></div><br class=3D""><div class=3D"">Oh, and <span style=
=3D"font-family: Courier;" class=3D"">operator</span>. Who could forget&nbs=
p;<font face=3D"Courier" class=3D"">operator "" operator</font>. Let it ret=
urn a callable type and you can have <font face=3D"Courier" class=3D""=
>R"operator()operator"operator()</font>.</div><div class=3D""><br class=3D"=
"></div><div class=3D"">Also, some implementations also accept the alternat=
ive spellings of punctuation, such as <font face=3D"Courier" class=3D"">or<=
/font>. The standard is a bit ambiguous about whether these form UDLs, sinc=
e they are forbidden from being identifiers, but only as long as they form =
separate tokens. The intent is probably that they should be reserved.</div>=
<div class=3D""><br class=3D""></div><div class=3D"">Point is, qualified lo=
okup is equally hacked whether you allow a literal token or a keyword on th=
e right-hand side.</div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_BCD0444D-B273-4B55-B0E2-DE97D30CE7FE--
.
Author: Myriachan <myriachan@gmail.com>
Date: Tue, 23 Jun 2015 21:47:44 -0700 (PDT)
Raw View
------=_Part_3284_880561749.1435121264949
Content-Type: multipart/alternative;
boundary="----=_Part_3285_1291503966.1435121264949"
------=_Part_3285_1291503966.1435121264949
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, June 22, 2015 at 12:48:13 AM UTC-7, David Krauss wrote:
>
> On 2015=E2=80=9306=E2=80=9322, at 3:18 PM, Tomasz <toma...@gmail.com <jav=
ascript:>> wrote:
>
>
> We define operator""s in the namespace std, not the s itself. Please=20
> remember that we allow operator ""if to be defined
>
>
> More precisely, operator""if *is* defined in [complex.literals]=20
> =C2=A726.4.10/4. Users can=E2=80=99t declare things like that, though, be=
cause UDL names=20
> not beginning with an underscore are reserved to the standard.
>
> =20
And Clang enforces this rule as an error >.<
On Thursday, June 18, 2015 at 9:44:03 PM UTC-7, Tomasz wrote:
>
> operator"" literal<'1', '2', '3'>(); //The 3rd form is hardly to be=20
> considered usable outside of automatic compiler calls.
>
=20
Although orthogonal to this discussion, I wish we were allowed to pass=20
literal strings or constant-expression char arrays to variadic char=20
templates. It'd be a neat solution to the decades-long annoyance that=20
literal strings can't be template parameters.
Melissa
--=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_3285_1291503966.1435121264949
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, June 22, 2015 at 12:48:13 AM UTC-7, David Krauss wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word">On =
2015=E2=80=9306=E2=80=9322, at 3:18 PM, Tomasz <<a href=3D"javascript:" =
target=3D"_blank" gdf-obfuscated-mailto=3D"vhY_w2_tWigJ" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">toma...@gmail.com</a>> wrote:<div><blockq=
uote type=3D"cite"><br><div><div dir=3D"ltr">We define operator""s in the n=
amespace std, not the s itself. Please remember that we allow operator ""if=
to be defined</div></div></blockquote><div><br></div><div>More precisely, =
<font face=3D"Courier">operator""if</font> <i>is</i> defined in [compl=
ex.literals] =C2=A726.4.10/4. Users can=E2=80=99t declare things like that,=
though, because UDL names not beginning with an underscore are reserved to=
the standard.</div></div><br></div></blockquote><div> </div><div>And =
Clang enforces this rule as an error >.<<br><br><br>On Thursday, June=
18, 2015 at 9:44:03 PM UTC-7, Tomasz wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr">operator"" literal<'1', '2', '3'>(); /=
/The 3rd form is hardly to be considered usable outside of automatic compil=
er calls.<br></div></blockquote><div> <br>Although orthogonal to this =
discussion, I wish we were allowed to pass literal strings or constant-expr=
ession char arrays to variadic char templates. It'd be a neat solutio=
n to the decades-long annoyance that literal strings can't be template para=
meters.<br></div><br>Melissa<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_3285_1291503966.1435121264949--
------=_Part_3284_880561749.1435121264949--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 24 Jun 2015 13:50:38 +0800
Raw View
--Apple-Mail=_256542C0-8156-4CBF-8974-6A4EE3AB831E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9306=E2=80=9324, at 12:47 PM, Myriachan <myriachan@gmail.co=
m> wrote:
>=20
> Although orthogonal to this discussion, I wish we were allowed to pass li=
teral strings or constant-expression char arrays to variadic char templates=
.. It'd be a neat solution to the decades-long annoyance that literal strin=
gs can't be template parameters.
Not orthogonal, I suggested that earlier.
Another approach, perhaps less intrusive to template parameter passing, is =
to let the string-literal/array argument initialize a template type paramet=
er with a variadic character list in a partial specialization.
template< char ... c >
struct narrow_string;
template< char32_t ... c >
struct wide_string;
template< typename str >
struct my_string_metafn;
template< char ... c >
struct my_string_metafn< narrow_string < c ... > > { =E2=80=A6 };
template< char32_t ... c >
struct my_string_metafn< wide_string < c ... > > { =E2=80=A6 };
my_string_metafn< "hello" >::type foo;
my_string_metafn< U"hello" >::type bar;
This provides for 1-to-1 mapping of arguments to parameters and encourages =
encapsulation of variadic lists.
This is also similar to the pure-library approach of defining operator""cs =
for compile-time strings, and then always use those strings as the starting=
point. This was the direction things were going at Urbana. Anyone who want=
s to let a library do string transformations will need to say using std::op=
erator""cs, and pass them as function arguments or through decltype. Unless=
the proposals get more ambitious, it seems unlikely for compile-time strin=
gs to be tied closer to the core language for now. But the avenue is still =
open.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_256542C0-8156-4CBF-8974-6A4EE3AB831E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=
=E2=80=9324, at 12:47 PM, Myriachan <<a href=3D"mailto:myriachan@gmail.c=
om" class=3D"">myriachan@gmail.com</a>> wrote:</div><br class=3D"Apple-i=
nterchange-newline"><div class=3D""><span style=3D"font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: nor=
mal; letter-spacing: normal; line-height: normal; orphans: auto; text-align=
: start; text-indent: 0px; text-transform: none; white-space: normal; widow=
s: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; di=
splay: inline !important;" class=3D"">Although orthogonal to this discussio=
n, I wish we were allowed to pass literal strings or constant-expression ch=
ar arrays to variadic char templates. It'd be a neat solution to the =
decades-long annoyance that literal strings can't be template parameters.</=
span><br class=3D"Apple-interchange-newline"></div></blockquote></div><br c=
lass=3D""><div class=3D"">Not orthogonal, I suggested that earlier.</div><d=
iv class=3D""><br class=3D""></div><div class=3D"">Another approach, perhap=
s less intrusive to template parameter passing, is to let the string-litera=
l/array argument initialize a template type parameter with a variadic chara=
cter list in a partial specialization.</div><div class=3D""><br class=3D"">=
</div><div class=3D""><font face=3D"Courier" class=3D"">template< char .=
... c ></font></div><div class=3D""><font face=3D"Courier" class=3D"">str=
uct narrow_string;</font></div><div class=3D""><font face=3D"Courier" class=
=3D""><br class=3D""></font></div><div class=3D""><font face=3D"Courier" cl=
ass=3D"">template< char32_t ... c ></font></div><div class=3D""><font=
face=3D"Courier" class=3D"">struct wide_string;</font></div><div class=3D"=
"><font face=3D"Courier" class=3D""><br class=3D""></font></div><div class=
=3D""><font face=3D"Courier" class=3D"">template< typename str ></fon=
t></div><div class=3D""><font face=3D"Courier" class=3D"">struct my_string_=
metafn;</font></div><div class=3D""><font face=3D"Courier" class=3D""><br c=
lass=3D""></font></div><div class=3D""><font face=3D"Courier" class=3D"">te=
mplate< char ... c ></font></div><div class=3D""><font face=3D"Courie=
r" class=3D"">struct my_string_metafn< </font><span style=3D"font-f=
amily: Courier;" class=3D"">narrow_string</span> <font face=3D"Courier=
" class=3D"">< c ... > > { =E2=80=A6 };</font></div><div class=3D"=
"><font face=3D"Courier" class=3D""><br class=3D""></font></div><div class=
=3D""><div class=3D""><font face=3D"Courier" class=3D"">template< char32=
_t ... c ></font></div><div class=3D""><font face=3D"Courier" class=3D""=
>struct my_string_metafn< </font><span style=3D"font-family: Courie=
r;" class=3D"">wide_string</span> <font face=3D"Courier" class=3D"">&l=
t; c ... > > { =E2=80=A6 };</font></div></div><div class=3D""><font f=
ace=3D"Courier" class=3D""><br class=3D""></font></div><div class=3D""><fon=
t face=3D"Courier" class=3D"">my_string_metafn< "hello" >::type foo;<=
/font></div><div class=3D""><div class=3D""><font face=3D"Courier" class=3D=
"">my_string_metafn< U"hello" >::type bar;</font></div></div><div cla=
ss=3D""><font face=3D"Courier" class=3D""><br class=3D""></font></div><div =
class=3D"">This provides for 1-to-1 mapping of arguments to parameters and =
encourages encapsulation of variadic lists.</div><div class=3D""><br class=
=3D""></div><div class=3D"">This is also similar to the pure-library approa=
ch of defining <font face=3D"Courier" class=3D"">operator""cs</font>&n=
bsp;for compile-time strings, and then always use those strings as the star=
ting point. This was the direction things were going at Urbana. Anyone who =
wants to let a library do string transformations will need to say <font fac=
e=3D"Courier" class=3D"">using std::</font><span style=3D"font-family: Cour=
ier;" class=3D"">operator""cs</span>, and pass them as function arguments o=
r through <font face=3D"Courier" class=3D"">decltype</font>. Unless th=
e proposals get more ambitious, it seems unlikely for compile-time strings =
to be tied closer to the core language for now. But the avenue is still ope=
n.</div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_256542C0-8156-4CBF-8974-6A4EE3AB831E--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Wed, 24 Jun 2015 10:07:09 +0200
Raw View
This is a multi-part message in MIME format.
--------------070809060005090408030302
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 2015-06-24 07:50, David Krauss wrote:
>
>> On 2015=E2=80=9306=E2=80=9324, at 12:47 PM, Myriachan <myriachan@gmail.c=
om
>> <mailto:myriachan@gmail.com>> wrote:
>>
>> Although orthogonal to this discussion, I wish we were allowed to
>> pass literal strings or constant-expression char arrays to variadic
>> char templates. It'd be a neat solution to the decades-long
>> annoyance that literal strings can't be template parameters.
>
> Not orthogonal, I suggested that earlier.
Anything "official" / links? How was the feedback?
>
> Another approach, perhaps less intrusive to template parameter
> passing, is to let the string-literal/array argument initialize a
> template type parameter with a variadic character list in a partial
> specialization.
>
> template< char ... c >
> struct narrow_string;
>
> template< char32_t ... c >
> struct wide_string;
>
> template< typename str >
> struct my_string_metafn;
>
> template< char ... c >
> struct my_string_metafn< narrow_string < c ... > > { =E2=80=A6 };
>
> template< char32_t ... c >
> struct my_string_metafn< wide_string < c ... > > { =E2=80=A6 };
>
> my_string_metafn< "hello" >::type foo;
> my_string_metafn< U"hello" >::type bar;
>
> This provides for 1-to-1 mapping of arguments to parameters and
> encourages encapsulation of variadic lists.
Not sure if I understand this correctly. Wouldn't the compiler have to
turn "hello" into std::narrow_string<'h','e','l','l','o'> automatically
here?
>
> This is also similar to the pure-library approach of
> defining operator""cs for compile-time strings, and then always use
> those strings as the starting point. This was the direction things
> were going at Urbana. Anyone who wants to let a library do string
> transformations will need to say using std::operator""cs, and pass
> them as function arguments or through decltype.
And then we're back to square one, if I want to do this in a header and
initialize a static constexpr member of a class... :-(
> Unless the proposals get more ambitious, it seems unlikely for
> compile-time strings to be tied closer to the core language for now.
> But the avenue is still open.
Is there a proposal for std::operator""cs already?
Best,
Roland
--=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/.
--------------070809060005090408030302
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">On 2015-06-24 07:50, David Krauss
wrote:<br>
</div>
<blockquote
cite=3D"mid:C641CD3B-32F8-4371-BE97-DA9C45E97319@gmail.com"
type=3D"cite">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf=
-8">
<br class=3D"">
<div>
<blockquote type=3D"cite" class=3D"">
<div class=3D"">On 2015=E2=80=9306=E2=80=9324, at 12:47 PM, Myria=
chan <<a
moz-do-not-send=3D"true" href=3D"mailto:myriachan@gmail.com"
class=3D"">myriachan@gmail.com</a>> wrote:</div>
<br class=3D"Apple-interchange-newline">
<div class=3D""><span style=3D"font-family: Helvetica; font-size:
12px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: auto; text-align: start; text-indent:
0px; text-transform: none; white-space: normal; widows:
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;
float: none; display: inline !important;" class=3D"">Although
orthogonal to this discussion, I wish we were allowed to
pass literal strings or constant-expression char arrays to
variadic char templates.=C2=A0 It'd be a neat solution to the
decades-long annoyance that literal strings can't be
template parameters.</span><br
class=3D"Apple-interchange-newline">
</div>
</blockquote>
</div>
<br class=3D"">
<div class=3D"">Not orthogonal, I suggested that earlier.</div>
</blockquote>
Anything "official" / links? How was the feedback?<br>
<br>
<blockquote
cite=3D"mid:C641CD3B-32F8-4371-BE97-DA9C45E97319@gmail.com"
type=3D"cite">
<div class=3D""><br class=3D"">
</div>
<div class=3D"">Another approach, perhaps less intrusive to template
parameter passing, is to let the string-literal/array argument
initialize a template type parameter with a variadic character
list in a partial specialization.</div>
<div class=3D""><br class=3D"">
</div>
<div class=3D""><font class=3D"" face=3D"Courier">template< char .=
...
c ></font></div>
<div class=3D""><font class=3D"" face=3D"Courier">struct narrow_strin=
g;</font></div>
<div class=3D""><font class=3D"" face=3D"Courier"><br class=3D"">
</font></div>
<div class=3D""><font class=3D"" face=3D"Courier">template< char32=
_t
... c ></font></div>
<div class=3D""><font class=3D"" face=3D"Courier">struct wide_string;=
</font></div>
<div class=3D""><font class=3D"" face=3D"Courier"><br class=3D"">
</font></div>
<div class=3D""><font class=3D"" face=3D"Courier">template< typena=
me
str ></font></div>
<div class=3D""><font class=3D"" face=3D"Courier">struct
my_string_metafn;</font></div>
<div class=3D""><font class=3D"" face=3D"Courier"><br class=3D"">
</font></div>
<div class=3D""><font class=3D"" face=3D"Courier">template< char .=
...
c ></font></div>
<div class=3D""><font class=3D"" face=3D"Courier">struct
my_string_metafn<=C2=A0</font><span style=3D"font-family:
Courier;" class=3D"">narrow_string</span>=C2=A0<font class=3D""
face=3D"Courier">< c ... > > { =E2=80=A6 };</font></div>
<div class=3D""><font class=3D"" face=3D"Courier"><br class=3D"">
</font></div>
<div class=3D"">
<div class=3D""><font class=3D"" face=3D"Courier">template<
char32_t ... c ></font></div>
<div class=3D""><font class=3D"" face=3D"Courier">struct
my_string_metafn<=C2=A0</font><span style=3D"font-family:
Courier;" class=3D"">wide_string</span>=C2=A0<font class=3D""
face=3D"Courier">< c ... > > { =E2=80=A6 };</font></di=
v>
</div>
<div class=3D""><font class=3D"" face=3D"Courier"><br class=3D"">
</font></div>
<div class=3D""><font class=3D"" face=3D"Courier">my_string_metafn<=
;
"hello" >::type foo;</font></div>
<div class=3D"">
<div class=3D""><font class=3D"" face=3D"Courier">my_string_metafn&=
lt;
U"hello" >::type bar;</font></div>
</div>
<div class=3D""><font class=3D"" face=3D"Courier"><br class=3D"">
</font></div>
<div class=3D"">This provides for 1-to-1 mapping of arguments to
parameters and encourages encapsulation of variadic lists.</div>
</blockquote>
Not sure if I understand this correctly. Wouldn't the compiler have
to turn "hello" into std::narrow_string<'h','e','l','l','o'>
automatically here?<br>
<br>
<blockquote
cite=3D"mid:C641CD3B-32F8-4371-BE97-DA9C45E97319@gmail.com"
type=3D"cite">
<div class=3D""><br class=3D"">
</div>
<div class=3D"">This is also similar to the pure-library approach of
defining=C2=A0<font class=3D"" face=3D"Courier">operator""cs</font>=
=C2=A0for
compile-time strings, and then always use those strings as the
starting point. This was the direction things were going at
Urbana. Anyone who wants to let a library do string
transformations will need to say <font class=3D"" face=3D"Courier">=
using
std::</font><span style=3D"font-family: Courier;" class=3D"">oper=
ator""cs</span>,
and pass them as function arguments or through=C2=A0<font class=3D"=
"
face=3D"Courier">decltype</font>.</div>
</blockquote>
And then we're back to square one, if I want to do this in a header
and initialize a static constexpr member of a class... :-(<br>
<br>
<br>
<blockquote
cite=3D"mid:C641CD3B-32F8-4371-BE97-DA9C45E97319@gmail.com"
type=3D"cite">
<div class=3D""> Unless the proposals get more ambitious, it seems
unlikely for compile-time strings to be tied closer to the core
language for now. But the avenue is still open.</div>
</blockquote>
<br>
Is there a proposal for <font class=3D"" face=3D"Courier">std::</font><=
span
style=3D"font-family: Courier;" class=3D"">operator""cs </span>alread=
y?<br>
<br>
Best,<br>
<br>
Roland<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--------------070809060005090408030302--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 24 Jun 2015 16:41:11 +0800
Raw View
--Apple-Mail=_FA9DA2EE-451F-4628-9B53-B3D591B747B7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9306=E2=80=9324, at 4:07 PM, Roland Bock <rbock@eudoxos.de>=
wrote:
>=20
> On 2015-06-24 07:50, David Krauss wrote:
>>=20
>>> On 2015=E2=80=9306=E2=80=9324, at 12:47 PM, Myriachan <myriachan@gmail.=
com <mailto:myriachan@gmail.com>> wrote:
>>>=20
>>> Although orthogonal to this discussion, I wish we were allowed to pass =
literal strings or constant-expression char arrays to variadic char templat=
es. It'd be a neat solution to the decades-long annoyance that literal str=
ings can't be template parameters.
>>=20
>> Not orthogonal, I suggested that earlier.
> Anything "official" / links? How was the feedback?
I just mean, a few messages earlier in this thread. =E2=80=9CWhy not let ma=
ke_bigint< "1234" >() do it?=E2=80=9D That=E2=80=99s all.
> Not sure if I understand this correctly. Wouldn't the compiler have to tu=
rn "hello" into std::narrow_string<'h','e','l','l','o'> automatically here?
Yes, but I think that=E2=80=99s better than turning "hello" into 'h','e','l=
','l','o'. Not least because we seem to be dropping the NUL termination, wh=
ich tends to suggest that the sequence should be inside something. (This is=
also the behavior of literal operator templates. It looks like a strike ag=
ainst named char arrays.)
> And then we're back to square one, if I want to do this in a header and i=
nitialize a static constexpr member of a class... :-(
constexpr lambdas look pretty likely for C++17.
> Is there a proposal for std::operator""cs already?
There=E2=80=99s N4121 which called it operator""sl, and N3933 which was pre=
sented but missed the deadline. It was very similar.
Reviewing N4121, it doesn=E2=80=99t encode the string in the type. You can =
still unpack it using an index_sequence, though.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_FA9DA2EE-451F-4628-9B53-B3D591B747B7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=
=E2=80=9324, at 4:07 PM, Roland Bock <<a href=3D"mailto:rbock@eudoxos.de=
" class=3D"">rbock@eudoxos.de</a>> wrote:</div><br class=3D"Apple-interc=
hange-newline"><div class=3D"">
=20
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
" class=3D"">
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF" class=3D"">
<div class=3D"moz-cite-prefix">On 2015-06-24 07:50, David Krauss
wrote:<br class=3D"">
</div>
<blockquote cite=3D"mid:C641CD3B-32F8-4371-BE97-DA9C45E97319@gmail.com"=
type=3D"cite" class=3D"">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf=
-8" class=3D"">
<br class=3D"">
<div class=3D"">
<blockquote type=3D"cite" class=3D"">
<div class=3D"">On 2015=E2=80=9306=E2=80=9324, at 12:47 PM, Myria=
chan <<a moz-do-not-send=3D"true" href=3D"mailto:myriachan@gmail.com" cl=
ass=3D"">myriachan@gmail.com</a>> wrote:</div>
<br class=3D"Apple-interchange-newline">
<div class=3D""><span style=3D"font-family: Helvetica; font-size:
12px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: auto; text-align: start; text-indent:
0px; text-transform: none; white-space: normal; widows:
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;
float: none; display: inline !important;" class=3D"">Although
orthogonal to this discussion, I wish we were allowed to
pass literal strings or constant-expression char arrays to
variadic char templates. It'd be a neat solution to the
decades-long annoyance that literal strings can't be
template parameters.</span><br class=3D"Apple-interchange-new=
line">
</div>
</blockquote>
</div>
<br class=3D"">
<div class=3D"">Not orthogonal, I suggested that earlier.</div>
</blockquote>
Anything "official" / links? How was the feedback?<br class=3D""></div>=
</div></blockquote><div><br class=3D""></div><div>I just mean, a few messag=
es earlier in this thread. =E2=80=9CWhy not let <font face=3D"Courier"=
class=3D"">make_bigint< "1234" >()</font> do it?=E2=80=9D That=
=E2=80=99s all.</div><br class=3D""><blockquote type=3D"cite" class=3D""><d=
iv text=3D"#000000" bgcolor=3D"#FFFFFF" class=3D"">Not sure if I understand=
this correctly. Wouldn't the compiler have
to turn "hello" into std::narrow_string<'h','e','l','l','o'>
automatically here?<br class=3D""></div></blockquote><div><br class=3D"=
"></div><div>Yes, but I think that=E2=80=99s better than turning <font face=
=3D"Courier" class=3D"">"hello"</font> into <font face=3D"Courier" class=3D=
"">'h','e','l','l','o'</font>. Not least because we seem to be dropping the=
NUL termination, which tends to suggest that the sequence should be inside=
something. (This is also the behavior of literal operator templates. It lo=
oks like a strike against named <font face=3D"Courier" class=3D"">char</fon=
t> arrays.)</div><div><br class=3D""></div><blockquote type=3D"cite" class=
=3D""><div class=3D""><div text=3D"#000000" bgcolor=3D"#FFFFFF" class=3D"">=
And then we're back to square one, if I want to do this in a header
and initialize a static constexpr member of a class... :-(<br class=3D"=
"></div></div></blockquote><div><br class=3D""></div><div>constexpr lambdas=
look pretty likely for C++17.</div><div><br class=3D""></div><blockquote t=
ype=3D"cite" class=3D""><div class=3D""><div text=3D"#000000" bgcolor=3D"#F=
FFFFF" class=3D"">
Is there a proposal for <font class=3D"" face=3D"Courier">std::</font><=
span style=3D"font-family: Courier;" class=3D"">operator""cs </span>already=
?<br class=3D""></div></div></blockquote><div><br class=3D""></div><div>The=
re=E2=80=99s N4121 which called it <font face=3D"Courier" class=3D"">operat=
or""sl</font>, and N3933 which was presented but missed the deadline. It wa=
s very similar.</div></div><br class=3D""><div class=3D"">Reviewing N4121, =
it doesn=E2=80=99t encode the string in the type. You can still unpack it u=
sing an <font face=3D"Courier" class=3D"">index_sequence</font>, though.</d=
iv></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_FA9DA2EE-451F-4628-9B53-B3D591B747B7--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Wed, 24 Jun 2015 11:24:19 +0200
Raw View
This is a multi-part message in MIME format.
--------------030004060207080403060204
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 2015-06-24 10:41, David Krauss wrote:
>
>> On 2015=E2=80=9306=E2=80=9324, at 4:07 PM, Roland Bock <rbock@eudoxos.de
>> <mailto:rbock@eudoxos.de>> wrote:
>>
>> On 2015-06-24 07:50, David Krauss wrote:
>>>
>>>> On 2015=E2=80=9306=E2=80=9324, at 12:47 PM, Myriachan <myriachan@gmail=
..com
>>>> <mailto:myriachan@gmail.com>> wrote:
>>>>
>>>> Although orthogonal to this discussion, I wish we were allowed to
>>>> pass literal strings or constant-expression char arrays to variadic
>>>> char templates. It'd be a neat solution to the decades-long
>>>> annoyance that literal strings can't be template parameters.
>>>
>>> Not orthogonal, I suggested that earlier.
>> Anything "official" / links? How was the feedback?
>
> I just mean, a few messages earlier in this thread. =E2=80=9CWhy not
> let make_bigint< "1234" >() do it?=E2=80=9D That=E2=80=99s all.
Ah, I misread that somehow.
>
>> Not sure if I understand this correctly. Wouldn't the compiler have
>> to turn "hello" into std::narrow_string<'h','e','l','l','o'>
>> automatically here?
>
> Yes, but I think that=E2=80=99s better than turning "hello" into
> 'h','e','l','l','o'. Not least because we seem to be dropping the NUL
> termination, which tends to suggest that the sequence should be inside
> something. (This is also the behavior of literal operator templates.
> It looks like a strike against named char arrays.)
On the other hand, if the compile turned hello" into
'h','e','l','l','o', the developer could choose between passing "hello"
into something that expects a parameter pack of chars or packing it into
a type for partial specialization.
namespace std
{
template< char ... c >
struct narrow_string;
template< char32_t ... c >
struct wide_string;
}
namespace my
{
template<char...c> compile_time_string;
template<typename T> sample;
}
int main()
{
auto cs =3D my::compile_time_string<"hello">;
auto s =3D my::sample<std::narrow_string<"hello">>;
}
Personally I would prefer having that choice, rather than having to
transform narrow_string into my::compile_time_string.
>
>> And then we're back to square one, if I want to do this in a header
>> and initialize a static constexpr member of a class... :-(
>
> constexpr lambdas look pretty likely for C++17.
That would certainly help :-)
>
>> Is there a proposal for std::operator""cs already?
>
> There=E2=80=99s N4121 which called it operator""sl, and N3933 which was
> presented but missed the deadline. It was very similar.
>
> Reviewing N4121, it doesn=E2=80=99t encode the string in the type. You ca=
n
> still unpack it using an index_sequence, though.
Thanks for the pointers, will look into those.
--=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/.
--------------030004060207080403060204
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">On 2015-06-24 10:41, David Krauss
wrote:<br>
</div>
<blockquote
cite=3D"mid:C8744793-73C6-4BB2-B676-3380D0E29BF1@gmail.com"
type=3D"cite">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf=
-8">
<br class=3D"">
<div>
<blockquote type=3D"cite" class=3D"">
<div class=3D"">On 2015=E2=80=9306=E2=80=9324, at 4:07 PM, Roland=
Bock <<a
moz-do-not-send=3D"true" href=3D"mailto:rbock@eudoxos.de"
class=3D"">rbock@eudoxos.de</a>> wrote:</div>
<br class=3D"Apple-interchange-newline">
<div class=3D"">
<meta content=3D"text/html; charset=3Dutf-8"
http-equiv=3D"Content-Type" class=3D"">
<div text=3D"#000000" bgcolor=3D"#FFFFFF" class=3D"">
<div class=3D"moz-cite-prefix">On 2015-06-24 07:50, David
Krauss wrote:<br class=3D"">
</div>
<blockquote
cite=3D"mid:C641CD3B-32F8-4371-BE97-DA9C45E97319@gmail.com"
type=3D"cite" class=3D"">
<meta http-equiv=3D"Content-Type" content=3D"text/html;
charset=3Dutf-8" class=3D"">
<br class=3D"">
<div class=3D"">
<blockquote type=3D"cite" class=3D"">
<div class=3D"">On 2015=E2=80=9306=E2=80=9324, at 12:47=
PM, Myriachan
<<a moz-do-not-send=3D"true"
href=3D"mailto:myriachan@gmail.com" class=3D"">myri=
achan@gmail.com</a>>
wrote:</div>
<br class=3D"Apple-interchange-newline">
<div class=3D""><span style=3D"font-family: Helvetica;
font-size: 12px; font-style: normal;
font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal;
orphans: auto; text-align: start; text-indent:
0px; text-transform: none; white-space: normal;
widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px; float: none;
display: inline !important;" class=3D"">Although
orthogonal to this discussion, I wish we were
allowed to pass literal strings or
constant-expression char arrays to variadic char
templates.=C2=A0 It'd be a neat solution to the
decades-long annoyance that literal strings
can't be template parameters.</span><br
class=3D"Apple-interchange-newline">
</div>
</blockquote>
</div>
<br class=3D"">
<div class=3D"">Not orthogonal, I suggested that earlier.</=
div>
</blockquote>
Anything "official" / links? How was the feedback?<br
class=3D"">
</div>
</div>
</blockquote>
<div><br class=3D"">
</div>
<div>I just mean, a few messages earlier in this thread. =E2=80=9CW=
hy
not let=C2=A0<font class=3D"" face=3D"Courier">make_bigint< "1=
234"
>()</font>=C2=A0do it?=E2=80=9D That=E2=80=99s all.</div>
</div>
</blockquote>
Ah, I misread that somehow.<br>
<br>
<blockquote
cite=3D"mid:C8744793-73C6-4BB2-B676-3380D0E29BF1@gmail.com"
type=3D"cite">
<div><br class=3D"">
<blockquote type=3D"cite" class=3D"">
<div text=3D"#000000" bgcolor=3D"#FFFFFF" class=3D"">Not sure if =
I
understand this correctly. Wouldn't the compiler have to
turn "hello" into
std::narrow_string<'h','e','l','l','o'> automatically
here?<br class=3D"">
</div>
</blockquote>
<div><br class=3D"">
</div>
<div>Yes, but I think that=E2=80=99s better than turning <font clas=
s=3D""
face=3D"Courier">"hello"</font> into <font class=3D""
face=3D"Courier">'h','e','l','l','o'</font>. Not least because
we seem to be dropping the NUL termination, which tends to
suggest that the sequence should be inside something. (This is
also the behavior of literal operator templates. It looks like
a strike against named <font class=3D"" face=3D"Courier">char</fo=
nt>
arrays.)</div>
</div>
</blockquote>
On the other hand, if the compile turned <font class=3D""
face=3D"Courier">hello"</font> into <font class=3D"" face=3D"Courier"=
>'h','e','l','l','o'</font>,
the developer could choose between passing "hello" into something
that expects a parameter pack of chars or packing it into a type for
partial specialization.<br>
<br>
<tt>namespace std</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt>
<div class=3D""><tt><font class=3D"">=C2=A0=C2=A0 template< char ...=
c ></font></tt></div>
<div class=3D""><tt><font class=3D"">=C2=A0=C2=A0 struct narrow_string;=
</font></tt></div>
<div class=3D""><tt><font class=3D""><br class=3D"">
</font></tt></div>
<div class=3D""><tt><font class=3D"">=C2=A0=C2=A0 template< char32_t=
... c ></font></tt></div>
<div class=3D""><tt><font class=3D"">=C2=A0=C2=A0 struct wide_string;<b=
r>
</font><font class=3D"">}<br>
</font></tt></div>
<tt><br>
</tt><tt>namespace my</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 template<char...c> compile_time_string;</tt=
><tt><br>
</tt><tt>=C2=A0=C2=A0 template<typename T> sample;</tt><tt><br>
</tt><tt>}</tt><tt><br>
</tt><tt><br>
</tt><tt>int main</tt><tt>()</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 auto cs =3D my::compile_time_string<"hello">=
;;</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 auto s =3D
my::sample<std::narrow_string<"hello">>;</tt><tt><br>
</tt><tt>}</tt><tt><br>
</tt><tt><br>
</tt>Personally I would prefer having that choice, rather than
having to transform narrow_string into my::compile_time_string.<br>
<br>
<blockquote
cite=3D"mid:C8744793-73C6-4BB2-B676-3380D0E29BF1@gmail.com"
type=3D"cite">
<div>
<div><br class=3D"">
</div>
<blockquote type=3D"cite" class=3D"">
<div class=3D"">
<div text=3D"#000000" bgcolor=3D"#FFFFFF" class=3D"">And then
we're back to square one, if I want to do this in a header
and initialize a static constexpr member of a class... :-(<br
class=3D"">
</div>
</div>
</blockquote>
<div><br class=3D"">
</div>
<div>constexpr lambdas look pretty likely for C++17.</div>
</div>
</blockquote>
That would certainly help :-)<br>
<br>
<blockquote
cite=3D"mid:C8744793-73C6-4BB2-B676-3380D0E29BF1@gmail.com"
type=3D"cite">
<div>
<div><br class=3D"">
</div>
<blockquote type=3D"cite" class=3D"">
<div class=3D"">
<div text=3D"#000000" bgcolor=3D"#FFFFFF" class=3D""> Is there =
a
proposal for <font class=3D"" face=3D"Courier">std::</font><s=
pan
style=3D"font-family: Courier;" class=3D"">operator""cs </s=
pan>already?<br
class=3D"">
</div>
</div>
</blockquote>
<div><br class=3D"">
</div>
<div>There=E2=80=99s N4121 which called it <font class=3D""
face=3D"Courier">operator""sl</font>, and N3933 which was
presented but missed the deadline. It was very similar.</div>
</div>
<br class=3D"">
<div class=3D"">Reviewing N4121, it doesn=E2=80=99t encode the string=
in the
type. You can still unpack it using an <font class=3D""
face=3D"Courier">index_sequence</font>, though.</div>
</blockquote>
Thanks for the pointers, will look into those.<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--------------030004060207080403060204--
.