------=_Part_770_1012005775.1436085476651
Content-Type: multipart/alternative;
 boundary="----=_Part_771_710576185.1436085476651"

------=_Part_771_710576185.1436085476651
Content-Type: text/plain; charset=UTF-8

Hi,
What ever happened to N3599? As I understand it, it was proposed for
inclusion in C++14. Does anyone know why it didn't get included?

Templated string literal operators was actually the first literal operator
I tried to implement when C++11 came out. I was disappointed that it didn't
work. It seems like an oversight in the standard. I just discovered N3599
today after looking at the code for Super Template Tetris lol. N3599 has
already been implemented for clang and gcc. Is there any momentum behind
this proposal for C++17?

-Kal

--

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

<div dir=3D"ltr">Hi,<div>What ever happened to N3599? As I understand it, i=
t was proposed for inclusion in C++14. Does anyone know why it didn't get i=
ncluded?</div><div><br></div><div>Templated string literal operators was ac=
tually the first literal operator I tried to implement when C++11 came out.=
 I was disappointed that it didn't work. It seems like an oversight in the =
standard. I just discovered N3599 today after looking at the code for Super=
 Template Tetris lol. N3599 has already been implemented for clang and gcc.=
 Is there any momentum behind this proposal for C++17?</div><div><br></div>=
<div>-Kal</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_771_710576185.1436085476651--
------=_Part_770_1012005775.1436085476651--

.

On 07/05/2015 10:37 AM, b17c0de@gmail.com wrote:
> Hi,
> What ever happened to N3599? As I understand it, it was proposed for inclusion in C++14. Does anyone know why it didn't get included?

See here:

http://cplusplus.github.io/EWG/ewg-active.html#66

I'd guess you should talk to Smith and Vandevoorde to see whether
they've come up with a revised version.

Jens

--

---
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_6234_301492993.1436124623164
Content-Type: multipart/alternative;
 boundary="----=_Part_6235_1278810078.1436124623164"

------=_Part_6235_1278810078.1436124623164
Content-Type: text/plain; charset=UTF-8

Thanks for the link. Does anyone know the specifics of "Revise with
additional machinery for compile time string processing" or why people were
otherwise against the original proposal?

On Sunday, July 5, 2015 at 8:54:47 PM UTC+2, Jens Maurer wrote:
>
> On 07/05/2015 10:37 AM, b17...@gmail.com <javascript:> wrote:
> > Hi,
> > What ever happened to N3599? As I understand it, it was proposed for
> inclusion in C++14. Does anyone know why it didn't get included?
>
> See here:
>
> http://cplusplus.github.io/EWG/ewg-active.html#66
>
> I'd guess you should talk to Smith and Vandevoorde to see whether
> they've come up with a revised version.
>
> Jens
>

--

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

<div dir=3D"ltr">Thanks for the link. Does anyone know the specifics of "Re=
vise with additional machinery for compile time string processing" or why p=
eople were otherwise against the original proposal?<div><br>On Sunday, July=
 5, 2015 at 8:54:47 PM UTC+2, Jens Maurer wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">On 07/05/2015 10:37 AM, <a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"F8wB43aM4OwJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javasc=
ript:';return true;">b17...@gmail.com</a> wrote:
<br>&gt; Hi,
<br>&gt; What ever happened to N3599? As I understand it, it was proposed f=
or inclusion in C++14. Does anyone know why it didn't get included?
<br>
<br>See here:
<br>
<br><a href=3D"http://cplusplus.github.io/EWG/ewg-active.html#66" target=3D=
"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com=
/url?q\75http%3A%2F%2Fcplusplus.github.io%2FEWG%2Fewg-active.html%2366\46sa=
\75D\46sntz\0751\46usg\75AFQjCNFtXK8aRhdUYsMwcu-EE2HdBdGKGA';return true;" =
onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fcplusplu=
s.github.io%2FEWG%2Fewg-active.html%2366\46sa\75D\46sntz\0751\46usg\75AFQjC=
NFtXK8aRhdUYsMwcu-EE2HdBdGKGA';return true;">http://cplusplus.github.io/<wb=
r>EWG/ewg-active.html#66</a>
<br>
<br>I'd guess you should talk to Smith and Vandevoorde to see whether
<br>they've come up with a revised version.
<br>
<br>Jens
<br></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_6235_1278810078.1436124623164--
------=_Part_6234_301492993.1436124623164--

.

------=_Part_6358_966885803.1436159192733
Content-Type: multipart/alternative;
 boundary="----=_Part_6359_440934172.1436159192733"

------=_Part_6359_440934172.1436159192733
Content-Type: text/plain; charset=UTF-8

We absolutely need templated string literals, and IMHO we don't need
additional machinery for compile-time
string processing. I would personally take the proposal as-is. We will then
implement additional machinery as
needed on a per-library basis.

Louis


On Sunday, 5 July 2015 21:30:23 UTC+2, b17...@gmail.com wrote:
>
> Thanks for the link. Does anyone know the specifics of "Revise with
> additional machinery for compile time string processing" or why people were
> otherwise against the original proposal?
>
> On Sunday, July 5, 2015 at 8:54:47 PM UTC+2, Jens Maurer wrote:
>>
>> On 07/05/2015 10:37 AM, b17...@gmail.com wrote:
>> > Hi,
>> > What ever happened to N3599? As I understand it, it was proposed for
>> inclusion in C++14. Does anyone know why it didn't get included?
>>
>> See here:
>>
>> http://cplusplus.github.io/EWG/ewg-active.html#66
>>
>> I'd guess you should talk to Smith and Vandevoorde to see whether
>> they've come up with a revised version.
>>
>> Jens
>>
>

--

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

<div dir=3D"ltr"><div>We absolutely need templated string literals, and IMH=
O we don't need additional machinery for compile-time</div><div>string proc=
essing. I would personally take the proposal as-is. We will then implement =
additional machinery as</div><div>needed on a per-library basis.</div><div>=
<br></div><div>Louis</div><br><br>On Sunday, 5 July 2015 21:30:23 UTC+2, b1=
7...@gmail.com  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">Thanks for the link. Does anyone know the specifics of "Revise wit=
h additional machinery for compile time string processing" or why people we=
re otherwise against the original proposal?<div><br>On Sunday, July 5, 2015=
 at 8:54:47 PM UTC+2, Jens Maurer wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex">On 07/05/2015 10:37 AM, <a rel=3D"nofollow">b17...@gmail.com</a> wrote=
:
<br>&gt; Hi,
<br>&gt; What ever happened to N3599? As I understand it, it was proposed f=
or inclusion in C++14. Does anyone know why it didn't get included?
<br>
<br>See here:
<br>
<br><a href=3D"http://cplusplus.github.io/EWG/ewg-active.html#66" rel=3D"no=
follow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com=
/url?q\75http%3A%2F%2Fcplusplus.github.io%2FEWG%2Fewg-active.html%2366\46sa=
\75D\46sntz\0751\46usg\75AFQjCNFtXK8aRhdUYsMwcu-EE2HdBdGKGA';return true;" =
onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fcplusplu=
s.github.io%2FEWG%2Fewg-active.html%2366\46sa\75D\46sntz\0751\46usg\75AFQjC=
NFtXK8aRhdUYsMwcu-EE2HdBdGKGA';return true;">http://cplusplus.github.io/<wb=
r>EWG/ewg-active.html#66</a>
<br>
<br>I'd guess you should talk to Smith and Vandevoorde to see whether
<br>they've come up with a revised version.
<br>
<br>Jens
<br></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_6359_440934172.1436159192733--
------=_Part_6358_966885803.1436159192733--

.

--Apple-Mail=_2AD4B729-9042-4D85-8487-7A72CFF64500
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9307=E2=80=9306, at 1:06 PM, Louis Dionne <ldionne.2@gmail.=
com> wrote:
>=20
> We absolutely need templated string literals, and IMHO we don't need addi=
tional machinery for compile-time
> string processing. I would personally take the proposal as-is. We will th=
en implement additional machinery as
> needed on a per-library basis.

Who is =E2=80=9Cwe=E2=80=9D? Having everyone reinvent the wheel is asking f=
or poor interoperability, poor performance, poor reliability=E2=80=A6

The core language issue I wonder about, for compile-time string processing,=
 is text encoding support. Should there be feature-test macros so metaprogr=
ams can tell what character set is in use? Something like std::char_traits =
(or new members in char_traits itself?) How to differentiate u8"" literals =
from unprefixed ones?

Libraries that don=E2=80=99t care about portability should be satisfied wit=
h the status quo: rough compatibility between popular implementations that =
volunteer to be cutting-edge. The standard shouldn=E2=80=99t compromise on =
quality just to =E2=80=9Cget something out the door.=E2=80=9D

--=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=_2AD4B729-9042-4D85-8487-7A72CFF64500
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=9307=
=E2=80=9306, at 1:06 PM, Louis Dionne &lt;<a href=3D"mailto:ldionne.2@gmail=
..com" class=3D"">ldionne.2@gmail.com</a>&gt; wrote:</div><br class=3D"Apple=
-interchange-newline"><div class=3D""><div style=3D"font-family: Helvetica;=
 font-size: 12px; font-style: normal; font-variant: normal; font-weight: no=
rmal; letter-spacing: normal; line-height: normal; orphans: auto; text-alig=
n: start; text-indent: 0px; text-transform: none; white-space: normal; wido=
ws: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D"">We=
 absolutely need templated string literals, and IMHO we don't need addition=
al machinery for compile-time</div><div style=3D"font-family: Helvetica; fo=
nt-size: 12px; font-style: normal; font-variant: normal; font-weight: norma=
l; 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"">strin=
g processing. I would personally take the proposal as-is. We will then impl=
ement additional machinery as</div><div style=3D"font-family: Helvetica; fo=
nt-size: 12px; font-style: normal; font-variant: normal; font-weight: norma=
l; 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"">neede=
d on a per-library basis.</div></div></blockquote></div><br class=3D""><div=
 class=3D"">Who is =E2=80=9Cwe=E2=80=9D? Having everyone reinvent the wheel=
 is asking for poor interoperability, poor performance, poor reliability=E2=
=80=A6</div><div class=3D""><br class=3D""></div><div class=3D"">The core l=
anguage issue I wonder about, for compile-time string processing, is text e=
ncoding support. Should there be feature-test macros so metaprograms can te=
ll what character set is in use? Something like <font face=3D"Courier" clas=
s=3D"">std::char_traits</font>&nbsp;(or new members in <font face=3D"Courie=
r" class=3D"">char_traits</font> itself?) How to differentiate <font face=
=3D"Courier" class=3D"">u8""</font> literals from unprefixed ones?</div><di=
v class=3D""><br class=3D""></div><div class=3D"">Libraries that don=E2=80=
=99t care about portability should be satisfied with the status quo: rough =
compatibility between popular implementations that volunteer to be cutting-=
edge. The standard shouldn=E2=80=99t compromise on quality just to =E2=80=
=9Cget something out the door.=E2=80=9D</div><div class=3D""><br class=3D""=
></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_2AD4B729-9042-4D85-8487-7A72CFF64500--

.

On Monday 06 July 2015 13:21:24 David Krauss wrote:
> The core language issue I wonder about, for compile-time string processin=
g,
> is text encoding support. Should there be feature-test macros so
> metaprograms can tell what character set is in use? Something like
> std::char_traits (or new members in char_traits itself?) How to
> differentiate u8"" literals from unprefixed ones?

Unless the proposal for char8_t comes about, I'd dismiss this as a=20
possibility. 8-bit characters have arbitrary encoding, regardless of whethe=
r=20
they were "" or u8"".

If you want to know the encoding, use char16_t and char32_t. Don't add the=
=20
overloads for 8-bit and for wchar_t.

> The standard shouldn=E2=80=99t compromise on quality just to =E2=80=9Cget=
 something out the
> door.=E2=80=9D

There's no good solution for that. Moreover, it's also pretty much orthogon=
al=20
to the current issue. There's no way to share my UTF-8 files with colleague=
s=20
using Visual Studio. I don't see willingness to solve that problem which is=
 at=20
a much lower level.

(BOMs are not a good idea)

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=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_743_28183427.1436160829566
Content-Type: multipart/alternative;
 boundary="----=_Part_744_1232455249.1436160829566"

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

There's at least me, Roland Bock (with sqlpp11), and Matt Bierner it seems.=
=20
But I also talked with many
more people at conferences like C++Now who would have needed compile-time=
=20
strings badly.

Let me clarify. I'm not opposed to additional machinery, and I would even=
=20
like it if we had more tools
to manipulate compile-time strings. However, 90% of the use cases are super=
=20
simple, and what we
need is nothing more than the Clang/GCC provided templated string literal.=
=20
Considering this is a
low hanging fruit and that more can be added later, it would be sad to=20
delay it 6 more years just
because this 10% of use cases is not covered yet.

Louis

On Monday, 6 July 2015 07:21:44 UTC+2, David Krauss wrote:
>
>
> On 2015=E2=80=9307=E2=80=9306, at 1:06 PM, Louis Dionne <ldio...@gmail.co=
m <javascript:>>=20
> wrote:
>
> We absolutely need templated string literals, and IMHO we don't need=20
> additional machinery for compile-time
> string processing. I would personally take the proposal as-is. We will=20
> then implement additional machinery as
> needed on a per-library basis.
>
>
> Who is =E2=80=9Cwe=E2=80=9D? Having everyone reinvent the wheel is asking=
 for poor=20
> interoperability, poor performance, poor reliability=E2=80=A6
>
> The core language issue I wonder about, for compile-time string=20
> processing, is text encoding support. Should there be feature-test macros=
=20
> so metaprograms can tell what character set is in use? Something like=20
> std::char_traits (or new members in char_traits itself?) How to=20
> differentiate u8"" literals from unprefixed ones?
>
> Libraries that don=E2=80=99t care about portability should be satisfied w=
ith the=20
> status quo: rough compatibility between popular implementations that=20
> volunteer to be cutting-edge. The standard shouldn=E2=80=99t compromise o=
n quality=20
> just to =E2=80=9Cget something out the door.=E2=80=9D
>
>

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

<div dir=3D"ltr"><div>There's at least me, Roland Bock (with sqlpp11), and =
Matt Bierner it seems. But I also talked with many</div><div>more people at=
 conferences like C++Now who would have needed compile-time strings badly.<=
/div><div><br></div><div>Let me clarify. I'm not opposed to additional mach=
inery, and I would even like it if we had more tools</div><div>to manipulat=
e compile-time strings. However, 90% of the use cases are super simple, and=
 what we</div><div>need is nothing more than the Clang/GCC provided templat=
ed string literal. Considering this is a</div><div>low hanging fruit and th=
at more can be added later, it would be sad to delay it 6 more years just</=
div><div>because this 10% of use cases is not covered yet.</div><div><br></=
div><div>Louis</div><br>On Monday, 6 July 2015 07:21:44 UTC+2, David Krauss=
  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wra=
p:break-word"><br><div><blockquote type=3D"cite"><div>On 2015=E2=80=9307=E2=
=80=9306, at 1:06 PM, Louis Dionne &lt;<a href=3D"javascript:" target=3D"_b=
lank" gdf-obfuscated-mailto=3D"3vPLVkJBahgJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascr=
ipt:';return true;">ldio...@gmail.com</a>&gt; wrote:</div><br><div><div sty=
le=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-variant:n=
ormal;font-weight:normal;letter-spacing:normal;line-height:normal;text-alig=
n:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing=
:0px">We absolutely need templated string literals, and IMHO we don't need =
additional machinery for compile-time</div><div style=3D"font-family:Helvet=
ica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal=
;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;=
text-transform:none;white-space:normal;word-spacing:0px">string processing.=
 I would personally take the proposal as-is. We will then implement additio=
nal machinery as</div><div style=3D"font-family:Helvetica;font-size:12px;fo=
nt-style:normal;font-variant:normal;font-weight:normal;letter-spacing:norma=
l;line-height:normal;text-align:start;text-indent:0px;text-transform:none;w=
hite-space:normal;word-spacing:0px">needed on a per-library basis.</div></d=
iv></blockquote></div><br><div>Who is =E2=80=9Cwe=E2=80=9D? Having everyone=
 reinvent the wheel is asking for poor interoperability, poor performance, =
poor reliability=E2=80=A6</div><div><br></div><div>The core language issue =
I wonder about, for compile-time string processing, is text encoding suppor=
t. Should there be feature-test macros so metaprograms can tell what charac=
ter set is in use? Something like <font face=3D"Courier">std::char_traits</=
font>&nbsp;(or new members in <font face=3D"Courier">char_traits</font> its=
elf?) How to differentiate <font face=3D"Courier">u8""</font> literals from=
 unprefixed ones?</div><div><br></div><div>Libraries that don=E2=80=99t car=
e about portability should be satisfied with the status quo: rough compatib=
ility between popular implementations that volunteer to be cutting-edge. Th=
e standard shouldn=E2=80=99t compromise on quality just to =E2=80=9Cget som=
ething out the door.=E2=80=9D</div><div><br></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_744_1232455249.1436160829566--
------=_Part_743_28183427.1436160829566--

.

--Apple-Mail=_202A3FD0-6A0F-4FC5-9FAC-F12836B4CCAD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9307=E2=80=9306, at 1:32 PM, Thiago Macieira <thiago@maciei=
ra.org> wrote:
>=20
> Unless the proposal for char8_t comes about, I'd dismiss this as a=20
> possibility. 8-bit characters have arbitrary encoding, regardless of whet=
her=20
> they were "" or u8=E2=80=9D".

What do you mean, arbitrary? Unprefixed strings use the execution character=
 set. u8 strings use UTF-8. The same goes for character literals, now that =
the u8 prefix exists there too, although multibyte characters must be treat=
ed as substrings either way.

Is there a problem with letting unsigned char stand-in for char8_t? I mean,=
 changing types has its own problems either way, but I don=E2=80=99t see th=
e advantage of an additional type.

> If you want to know the encoding, use char16_t and char32_t. Don't add th=
e=20
> overloads for 8-bit and for wchar_t.

UTF-8 is popular enough to warrant a feature test like __cpp_execution_char=
set_utf8, if nothing else exists.

> There's no good solution for that. Moreover, it's also pretty much orthog=
onal=20
> to the current issue. There's no way to share my UTF-8 files with colleag=
ues=20
> using Visual Studio. I don't see willingness to solve that problem which =
is at=20
> a much lower level.
>=20
> (BOMs are not a good idea)

Microsoft doesn=E2=80=99t represent the whole industry. I=E2=80=99m not say=
ing the standard needs to be perfect, but compile-time string processing sh=
ould support text consistently with the rest of the language.

Perhaps the perceived orthogonality comes from the different use-cases of c=
ompile-time parsing. Source-code-Ilke strings can be used for metaprogrammi=
ng, and text-like strings can be used more conventionally, for the program=
=E2=80=99s output. Anywhere that a string is really a string (not a number =
or a function), it=E2=80=99s a pretty good idea to shoot for expressive par=
ity with runtime strings.

--=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=_202A3FD0-6A0F-4FC5-9FAC-F12836B4CCAD
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=9307=
=E2=80=9306, at 1:32 PM, Thiago Macieira &lt;<a href=3D"mailto:thiago@macie=
ira.org" class=3D"">thiago@macieira.org</a>&gt; wrote:</div><br class=3D"Ap=
ple-interchange-newline"><div class=3D"">Unless the proposal for char8_t co=
mes about, I'd dismiss this as a <br class=3D"">possibility. 8-bit characte=
rs have arbitrary encoding, regardless of whether <br class=3D"">they were =
"" or u8=E2=80=9D".<br class=3D""></div></blockquote><div><br class=3D""></=
div><div>What do you mean, arbitrary? Unprefixed strings use the execution =
character set. <font face=3D"Courier" class=3D"">u8</font> strings use UTF-=
8. The same goes for character literals, now that the <font face=3D"Courier=
" class=3D"">u8</font> prefix exists there too, although multibyte characte=
rs must be treated as substrings either way.</div><div><br class=3D""></div=
><div>Is there a problem with letting <font face=3D"Courier" class=3D"">uns=
igned char</font> stand-in for <font face=3D"Courier" class=3D"">char8_t</f=
ont>? I mean, changing types has its own problems either way, but I don=E2=
=80=99t see the advantage of an additional type.</div><br class=3D""><block=
quote type=3D"cite" class=3D""><div class=3D"">If you want to know the enco=
ding, use char16_t and char32_t. Don't add the <br class=3D"">overloads for=
 8-bit and for wchar_t.<br class=3D""></div></blockquote><div><br class=3D"=
"></div><div>UTF-8 is popular enough to warrant a feature test like <font f=
ace=3D"Courier" class=3D"">__cpp_execution_charset_utf8</font>, if nothing =
else exists.</div><div><br class=3D""></div><blockquote type=3D"cite" class=
=3D""><div class=3D"">There's no good solution for that. Moreover, it's als=
o pretty much orthogonal <br class=3D"">to the current issue. There's no wa=
y to share my UTF-8 files with colleagues <br class=3D"">using Visual Studi=
o. I don't see willingness to solve that problem which is at <br class=3D""=
>a much lower level.<br class=3D""><br class=3D"">(BOMs are not a good idea=
)<br class=3D""></div></blockquote></div><br class=3D""><div class=3D"">Mic=
rosoft doesn=E2=80=99t represent the whole industry. I=E2=80=99m not saying=
 the standard needs to be perfect, but compile-time string processing shoul=
d support text consistently with the rest of the language.</div><div class=
=3D""><br class=3D""></div><div class=3D"">Perhaps the perceived orthogonal=
ity comes from the different use-cases of compile-time parsing. Source-code=
-Ilke strings can be used for metaprogramming, and text-like strings can be=
 used more conventionally, for the program=E2=80=99s output. Anywhere that =
a string is really a string (not a number or a function), it=E2=80=99s a pr=
etty good idea to shoot for expressive parity with runtime strings.</div><d=
iv class=3D""><br class=3D""></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_202A3FD0-6A0F-4FC5-9FAC-F12836B4CCAD--

.

--Apple-Mail=_0790604B-3A9F-4697-9D17-7A6251BD5317
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

EWG in Urbana voted between N4121, which proposed a class basic_string_lite=
ral< charT, traits, N > and N4236, which proposed to further develop the Cl=
ang/GCC UDL template extension. The decision was strongly in favor of N4121=
, which means the extension is a dead end. And, there=E2=80=99s a slot ther=
e for the traits I mentioned :) .

If you=E2=80=99re interested in future-proof compile-time string processing=
, the better methodology is to forgo the literal operator template extensio=
n and unpack the characters from an ordinary string literal, using std::ind=
ex_sequence, as outlined in N4121.


> On 2015=E2=80=9307=E2=80=9306, at 1:33 PM, Louis Dionne <ldionne.2@gmail.=
com <mailto:ldionne.2@gmail.com>> wrote:
>=20
> There's at least me, Roland Bock (with sqlpp11), and Matt Bierner it seem=
s. But I also talked with many
> more people at conferences like C++Now who would have needed compile-time=
 strings badly.
>=20
> Let me clarify. I'm not opposed to additional machinery, and I would even=
 like it if we had more tools
> to manipulate compile-time strings. However, 90% of the use cases are sup=
er simple, and what we
> need is nothing more than the Clang/GCC provided templated string literal=
.. Considering this is a
> low hanging fruit and that more can be added later, it would be sad to de=
lay it 6 more years just
> because this 10% of use cases is not covered yet.
>=20
> Louis

--=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=_0790604B-3A9F-4697-9D17-7A6251BD5317
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"><meta http-equiv=3D"Content-Type" content=3D"text/html charset=3D=
utf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: spac=
e; -webkit-line-break: after-white-space;" class=3D""><div class=3D"">EWG i=
n Urbana voted between N4121, which proposed a <font face=3D"Courier" class=
=3D"">class basic_string_literal&lt; charT, traits, N &gt;</font> and N4236=
, which proposed to further develop the Clang/GCC UDL template extension. T=
he decision was strongly in favor of N4121, which means the extension is a =
dead end. And, there=E2=80=99s a slot there for the traits I mentioned :) .=
</div><div class=3D""><br class=3D""></div><div class=3D"">If you=E2=80=99r=
e interested in future-proof compile-time string processing, the better met=
hodology is to forgo the literal operator template extension and unpack the=
 characters from an ordinary string literal, using <font face=3D"Courier" c=
lass=3D"">std::index_sequence</font>, as outlined in N4121.</div><div class=
=3D""><br class=3D""></div><div class=3D""><div class=3D""><br class=3D""><=
div class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=
=E2=80=9307=E2=80=9306, at 1:33 PM, Louis Dionne &lt;<a href=3D"mailto:ldio=
nne.2@gmail.com" class=3D"">ldionne.2@gmail.com</a>&gt; wrote:</div><br cla=
ss=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" 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;" class=3D""><div class=3D"">There's at least me, Roland Bock (with=
 sqlpp11), and Matt Bierner it seems. But I also talked with many</div><div=
 class=3D"">more people at conferences like C++Now who would have needed co=
mpile-time strings badly.</div><div class=3D""><br class=3D""></div><div cl=
ass=3D"">Let me clarify. I'm not opposed to additional machinery, and I wou=
ld even like it if we had more tools</div><div class=3D"">to manipulate com=
pile-time strings. However, 90% of the use cases are super simple, and what=
 we</div><div class=3D"">need is nothing more than the Clang/GCC provided t=
emplated string literal. Considering this is a</div><div class=3D"">low han=
ging fruit and that more can be added later, it would be sad to delay it 6 =
more years just</div><div class=3D"">because this 10% of use cases is not c=
overed yet.</div><div class=3D""><br class=3D""></div><div class=3D"">Louis=
</div></div></div></blockquote></div><br class=3D""></div></div></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_0790604B-3A9F-4697-9D17-7A6251BD5317--

.

On 2015-07-06 08:15, David Krauss wrote:
>
>> On 2015=E2=80=9307=E2=80=9306, at 1:32 PM, Thiago Macieira <thiago@macie=
ira.org
>> <mailto:thiago@macieira.org>> wrote:
>>
>> Unless the proposal for char8_t comes about, I'd dismiss this as a
>> possibility. 8-bit characters have arbitrary encoding, regardless of
>> whether
>> they were "" or u8=E2=80=9D".
>
> What do you mean, arbitrary? Unprefixed strings use the execution
> character set. u8 strings use UTF-8. The same goes for character
> literals, now that the u8 prefix exists there too, although multibyte
> characters must be treated as substrings either way.
>
> Is there a problem with letting unsigned char stand-in for char8_t? I
> mean, changing types has its own problems either way, but I don=E2=80=99t=
 see
> the advantage of an additional type.
>

unsigned char is already likely to be the base of uint8_t. And used as a=20
generic 'byte' type in low-lwvwl code. Giving it yet another use can=20
give us "interesting" overload problems.

Not that I favor a 4th 8-bit character type either...


Bo Persson


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

.

On Monday 06 July 2015 14:15:38 David Krauss wrote:
> > On 2015=E2=80=9307=E2=80=9306, at 1:32 PM, Thiago Macieira <thiago@maci=
eira.org> wrote:
> >=20
> > Unless the proposal for char8_t comes about, I'd dismiss this as a
> > possibility. 8-bit characters have arbitrary encoding, regardless of
> > whether they were "" or u8=E2=80=9D".
>=20
> What do you mean, arbitrary? Unprefixed strings use the execution charact=
er
> set. u8 strings use UTF-8. The same goes for character literals, now that
> the u8 prefix exists there too, although multibyte characters must be
> treated as substrings either way.

The problem is that the information is lost as the UTF-8 string is stored i=
n a=20
char[] array. Neither the template version nor any char-based function, for=
=20
that matter, can now whether you meant UTF-8 or the execution charset.

The only solution in my view for this problem is to force the execution=20
charset to UTF-8. On most OS except for Windows, that's already the case. T=
he=20
trouble is just convincing Windows and Microsoft compilers to be like that.

> Is there a problem with letting unsigned char stand-in for char8_t? I mea=
n,
> changing types has its own problems either way, but I don=E2=80=99t see t=
he
> advantage of an additional type.

That's the proposal I was talking about.

> > If you want to know the encoding, use char16_t and char32_t. Don't add =
the
> > overloads for 8-bit and for wchar_t.
>=20
> UTF-8 is popular enough to warrant a feature test like
> __cpp_execution_charset_utf8, if nothing else exists.

Isn't the execution charset, by definition, a runtime feature? I don't thin=
k a=20
macro would serve here.

> > There's no good solution for that. Moreover, it's also pretty much
> > orthogonal to the current issue. There's no way to share my UTF-8 files
> > with colleagues using Visual Studio. I don't see willingness to solve
> > that problem which is at a much lower level.
> >=20
> > (BOMs are not a good idea)
>=20
> Microsoft doesn=E2=80=99t represent the whole industry. I=E2=80=99m not s=
aying the standard
> needs to be perfect, but compile-time string processing should support te=
xt
> consistently with the rest of the language.

That's the problem! The rest of the language does not have almost any featu=
res=20
to do that. This lack of features elsewhere should not hold back a feature=
=20
that is otherwise useful.

Don't get me wrong. I do think we should fix the woeful lack of UTF-8 and=
=20
Unicode support in the language. Compared to QString and QTextCodec, suppor=
t=20
in the Standard Library is laughable.

> Perhaps the perceived orthogonality comes from the different use-cases of
> compile-time parsing. Source-code-Ilke strings can be used for
> metaprogramming, and text-like strings can be used more conventionally, f=
or
> the program=E2=80=99s output. Anywhere that a string is really a string (=
not a
> number or a function), it=E2=80=99s a pretty good idea to shoot for expre=
ssive
> parity with runtime strings.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

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

.

On 2015-07-06 09:26, Thiago Macieira wrote:
> On Monday 06 July 2015 14:15:38 David Krauss wrote:
>>> On 2015=E2=80=9307=E2=80=9306, at 1:32 PM, Thiago Macieira <thiago@maci=
eira.org> wrote:
>>>
>>> Unless the proposal for char8_t comes about, I'd dismiss this as a
>>> possibility. 8-bit characters have arbitrary encoding, regardless of
>>> whether they were "" or u8=E2=80=9D".
>>
>> What do you mean, arbitrary? Unprefixed strings use the execution charac=
ter
>> set. u8 strings use UTF-8. The same goes for character literals, now tha=
t
>> the u8 prefix exists there too, although multibyte characters must be
>> treated as substrings either way.
>
> The problem is that the information is lost as the UTF-8 string is stored=
 in a
> char[] array. Neither the template version nor any char-based function, f=
or
> that matter, can now whether you meant UTF-8 or the execution charset.
>
> The only solution in my view for this problem is to force the execution
> charset to UTF-8. On most OS except for Windows, that's already the case.=
 The
> trouble is just convincing Windows and Microsoft compilers to be like tha=
t.
>

You have another player using EBCDIC. Not likely to give up on that either.

Not everyting is a desktop!


Bo Persson



--=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_6601_120288579.1436171411727
Content-Type: multipart/alternative;
 boundary="----=_Part_6602_908035426.1436171411727"

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

N4121 is interesting. But it seems to me that N4121 and N3599 are=20
orthogonal proposals. I mean templated string UDLs are useful on their own=
=20
with or without basic_string_literal. I don't think there is any need to=20
combine them as in N4236. Seems like it can be kept fairly simple, along=20
the lines of what N3599 proposes.

On Monday, July 6, 2015 at 8:41:25 AM UTC+2, David Krauss wrote:
>
> EWG in Urbana voted between N4121, which proposed a class=20
> basic_string_literal< charT, traits, N > and N4236, which proposed to=20
> further develop the Clang/GCC UDL template extension. The decision was=20
> strongly in favor of N4121, which means the extension is a dead end. And,=
=20
> there=E2=80=99s a slot there for the traits I mentioned :) .
>
> If you=E2=80=99re interested in future-proof compile-time string processi=
ng, the=20
> better methodology is to forgo the literal operator template extension an=
d=20
> unpack the characters from an ordinary string literal, using=20
> std::index_sequence, as outlined in N4121.
>
>
> On 2015=E2=80=9307=E2=80=9306, at 1:33 PM, Louis Dionne <ldio...@gmail.co=
m <javascript:>>=20
> wrote:
>
> There's at least me, Roland Bock (with sqlpp11), and Matt Bierner it=20
> seems. But I also talked with many
> more people at conferences like C++Now who would have needed compile-time=
=20
> strings badly.
>
> Let me clarify. I'm not opposed to additional machinery, and I would even=
=20
> like it if we had more tools
> to manipulate compile-time strings. However, 90% of the use cases are=20
> super simple, and what we
> need is nothing more than the Clang/GCC provided templated string literal=
..=20
> Considering this is a
> low hanging fruit and that more can be added later, it would be sad to=20
> delay it 6 more years just
> because this 10% of use cases is not covered yet.
>
> Louis
>
>
>

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

<div dir=3D"ltr">N4121 is interesting. But it seems to me that&nbsp;N4121 a=
nd&nbsp;N3599 are orthogonal proposals. I mean templated string UDLs are us=
eful on their own with or without&nbsp;<span style=3D"font-family: Courier;=
">basic_string_literal</span>. I don't think there is any need to combine t=
hem as in&nbsp;N4236.&nbsp;Seems like it can be kept fairly simple, along t=
he lines of what N3599 proposes.<br><br>On Monday, July 6, 2015 at 8:41:25 =
AM UTC+2, David Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div style=3D"word-wrap:break-word"><div>EWG in Urbana voted between N4121, =
which proposed a <font face=3D"Courier">class basic_string_literal&lt; char=
T, traits, N &gt;</font> and N4236, which proposed to further develop the C=
lang/GCC UDL template extension. The decision was strongly in favor of N412=
1, which means the extension is a dead end. And, there=E2=80=99s a slot the=
re for the traits I mentioned :) .</div><div><br></div><div>If you=E2=80=99=
re interested in future-proof compile-time string processing, the better me=
thodology is to forgo the literal operator template extension and unpack th=
e characters from an ordinary string literal, using <font face=3D"Courier">=
std::index_sequence</font>, as outlined in N4121.</div><div><br></div><div>=
<div><br><div><blockquote type=3D"cite"><div>On 2015=E2=80=9307=E2=80=9306,=
 at 1:33 PM, Louis Dionne &lt;<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"B42sDOJpWU0J" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';retur=
n true;">ldio...@gmail.com</a>&gt; wrote:</div><br><div><div dir=3D"ltr" st=
yle=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-variant:=
normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-ali=
gn:start;text-indent:0px;text-transform:none;white-space:normal;word-spacin=
g:0px"><div>There's at least me, Roland Bock (with sqlpp11), and Matt Biern=
er it seems. But I also talked with many</div><div>more people at conferenc=
es like C++Now who would have needed compile-time strings badly.</div><div>=
<br></div><div>Let me clarify. I'm not opposed to additional machinery, and=
 I would even like it if we had more tools</div><div>to manipulate compile-=
time strings. However, 90% of the use cases are super simple, and what we</=
div><div>need is nothing more than the Clang/GCC provided templated string =
literal. Considering this is a</div><div>low hanging fruit and that more ca=
n be added later, it would be sad to delay it 6 more years just</div><div>b=
ecause this 10% of use cases is not covered yet.</div><div><br></div><div>L=
ouis</div></div></div></blockquote></div><br></div></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_6602_908035426.1436171411727--
------=_Part_6601_120288579.1436171411727--

.

--Apple-Mail=_AC89866F-FC82-4934-961C-0A07C23A07FC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9307=E2=80=9306, at 3:26 PM, Thiago Macieira <thiago@maciei=
ra.org> wrote:
>=20
> The problem is that the information is lost as the UTF-8 string is stored=
 in a=20
> char[] array. Neither the template version nor any char-based function, f=
or=20
> that matter, can now whether you meant UTF-8 or the execution charset.

Fortunately, the std::string_literal proposal favored by EWG provides for t=
raits which could record the encoding. It should be on track for a Fundamen=
tals TS (e.g., Fundamentals v2), along with string_view. Maybe char_traits =
itself deserves a revision, too.

> Isn't the execution charset, by definition, a runtime feature? I don't th=
ink a=20
> macro would serve here.

The execution character set is the one used to encode string literals.

>> Microsoft doesn=E2=80=99t represent the whole industry. I=E2=80=99m not =
saying the standard
>> needs to be perfect, but compile-time string processing should support t=
ext
>> consistently with the rest of the language.
>=20
> That's the problem! The rest of the language does not have almost any fea=
tures=20
> to do that. This lack of features elsewhere should not hold back a featur=
e=20
> that is otherwise useful.

The standard allows the platform to define the text encoding of string lite=
rals. I=E2=80=99m only saying that compile-time string processing should po=
rtably cooperate with that.

You seem to be focusing on runtime interoperability, i.e. foreign text enco=
dings. I=E2=80=99m only talking about dealing with native strings at compil=
e time.

> Don't get me wrong. I do think we should fix the woeful lack of UTF-8 and=
=20
> Unicode support in the language. Compared to QString and QTextCodec, supp=
ort=20
> in the Standard Library is laughable.

Why not make 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/.

--Apple-Mail=_AC89866F-FC82-4934-961C-0A07C23A07FC
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=9307=
=E2=80=9306, at 3:26 PM, Thiago Macieira &lt;<a href=3D"mailto:thiago@macie=
ira.org" class=3D"">thiago@macieira.org</a>&gt; wrote:</div><br class=3D"Ap=
ple-interchange-newline"><div class=3D"">The problem is that the informatio=
n is lost as the UTF-8 string is stored in a <br class=3D"">char[] array. N=
either the template version nor any char-based function, for&nbsp;</div></b=
lockquote><blockquote type=3D"cite" class=3D""><div class=3D"">that matter,=
 can now whether you meant UTF-8 or the execution charset.<br class=3D""></=
div></blockquote><div><br class=3D""></div><div>Fortunately, the <font face=
=3D"Courier" class=3D"">std::string_literal</font> proposal favored by EWG =
provides for traits which could record the encoding. It should be on track =
for a Fundamentals TS (e.g., Fundamentals v2), along with <font face=3D"Cou=
rier" class=3D"">string_view</font>. Maybe <font face=3D"Courier" class=3D"=
">char_traits</font> itself deserves a revision, too.</div><br class=3D""><=
blockquote type=3D"cite" class=3D""><div class=3D"">Isn't the execution cha=
rset, by definition, a runtime feature? I don't think a <br class=3D"">macr=
o would serve here.<br class=3D""></div></blockquote><div><br class=3D""></=
div><div>The execution character set is the one used to encode string liter=
als.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D=
""><blockquote type=3D"cite" class=3D"">Microsoft doesn=E2=80=99t represent=
 the whole industry. I=E2=80=99m not saying the standard<br class=3D"">need=
s to be perfect, but compile-time string processing should support text<br =
class=3D"">consistently with the rest of the language.<br class=3D""></bloc=
kquote><br class=3D"">That's the problem! The rest of the language does not=
 have almost any features <br class=3D"">to do that. This lack of features =
elsewhere should not hold back a feature <br class=3D"">that is otherwise u=
seful.<br class=3D""></div></blockquote><div><br class=3D""></div><div>The =
standard allows the platform to define the text encoding of string literals=
.. I=E2=80=99m only saying that compile-time string processing should portab=
ly cooperate with that.</div><div><br class=3D""></div><div>You seem to be =
focusing on runtime interoperability, i.e. foreign text encodings. I=E2=80=
=99m only talking about dealing with native strings at compile time.</div><=
br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">Don't ge=
t me wrong. I do think we should fix the woeful lack of UTF-8 and <br class=
=3D"">Unicode support in the language. Compared to QString and QTextCodec, =
support <br class=3D"">in the Standard Library is laughable.<br class=3D"">=
</div></blockquote><div><br class=3D""></div><div>Why not make proposals?</=
div><div><br class=3D""></div></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_AC89866F-FC82-4934-961C-0A07C23A07FC--

.

This is a multi-part message in MIME format.
--------------090406000008030001060807
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Since I saw my name coming up and I started a discussion about
namespace-qualified use of UDLs:

I need compile-time strings.
And they should be painless and maintainer-friendly to use.


Specifically, I need

struct A
{
   static constexpr auto x =3D foo("hello");
};

or

struct B
{
   using x_t =3D decltype(bar("hello"));
};

in a header. x or x_t must be compile-time comparable.

a) UDLs are not a good solution, unless there were a way to namespace
qualify them: I cannot use "using namespace XYC" to pull in a literal in
a header.
b) I do not want to have to think about whether "hello" is 5 characters
long. When I change it to "good morning", it should still compile,
without me having to count characters. Thus, if I understand it
correctly, N4121 does not seem to be a good option, too.
c) foo and bar should not be macros, of course.

I would be all for N4121 if we could get rid of the size parameter.

struct C
{
    static constexpr auto x =3D std::string_literal("hello"); // without <5=
>
};

This would be nice.


BTW, could I then do something like the following?

template<typename T>
struct my_name;

my_name<std::string_literal("hello")>


Best,

Roland


On 2015-07-06 08:41, David Krauss wrote:
> EWG in Urbana voted between N4121, which proposed a class
> basic_string_literal< charT, traits, N > and N4236, which proposed to
> further develop the Clang/GCC UDL template extension. The decision was
> strongly in favor of N4121, which means the extension is a dead end.
> And, there=E2=80=99s a slot there for the traits I mentioned :) .
>
> If you=E2=80=99re interested in future-proof compile-time string processi=
ng,
> the better methodology is to forgo the literal operator template
> extension and unpack the characters from an ordinary string literal,
> using std::index_sequence, as outlined in N4121.
>
>
>> On 2015=E2=80=9307=E2=80=9306, at 1:33 PM, Louis Dionne <ldionne.2@gmail=
..com
>> <mailto:ldionne.2@gmail.com>> wrote:
>>
>> There's at least me, Roland Bock (with sqlpp11), and Matt Bierner it
>> seems. But I also talked with many
>> more people at conferences like C++Now who would have needed
>> compile-time strings badly.
>>
>> Let me clarify. I'm not opposed to additional machinery, and I would
>> even like it if we had more tools
>> to manipulate compile-time strings. However, 90% of the use cases are
>> super simple, and what we
>> need is nothing more than the Clang/GCC provided templated string
>> literal. Considering this is a
>> low hanging fruit and that more can be added later, it would be sad
>> to delay it 6 more years just
>> because this 10% of use cases is not covered yet.
>>
>> Louis
>
> --=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 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/.

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

--------------090406000008030001060807
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">Since I saw my name coming up and I
      started a discussion about namespace-qualified use of UDLs:<br>
      <br>
      I need compile-time strings.<br>
      And they should be painless and maintainer-friendly to use.<br>
      <br>
      <br>
      Specifically, I need<br>
      <br>
      <font face=3D"Courier New, Courier, monospace">struct A<br>
        {<br>
        =C2=A0=C2=A0 static constexpr auto x =3D foo("hello");<br>
        };<br>
        <br>
        or <br>
      </font><br>
      <font face=3D"Courier New, Courier, monospace">struct B<br>
        {<br>
        =C2=A0=C2=A0 using x_t =3D decltype(bar("hello"));<br>
        };<br>
      </font><br>
      in a header. x or x_t must be compile-time comparable.<br>
      <br>
      a) UDLs are not a good solution, unless there were a way to
      namespace qualify them: I cannot use "using namespace XYC" to pull
      in a literal in a header.<br>
      b) I do not want to have to think about whether "hello" is 5
      characters long. When I change it to "good morning", it should
      still compile, without me having to count characters. Thus, if I
      understand it correctly, N4121 does not seem to be a good option,
      too.<br>
      c) foo and bar should not be macros, of course.<br>
      <br>
      I would be all for N4121 if we could get rid of the size
      parameter.<br>
      <br>
      <font face=3D"Courier New, Courier, monospace">struct C<br>
        {<br>
        =C2=A0=C2=A0=C2=A0 static constexpr auto x =3D std::string_literal(=
"hello"); //
        without &lt;5&gt;<br>
        };</font><br>
      <br>
      This would be nice.<br>
      <br>
      <br>
      BTW, could I then do something like the following?<br>
      <br>
      template&lt;typename T&gt;<br>
      struct my_name;<br>
      <br>
      my_name&lt;<font face=3D"Courier New, Courier, monospace">std::string=
_literal("hello")&gt;</font><br>
      <br>
      <br>
      Best,<br>
      <br>
      Roland<br>
      <br>
      <br>
      On 2015-07-06 08:41, David Krauss wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:11F6955E-6EDE-4326-9079-38F4748850FF@gmail.com"
      type=3D"cite">
      <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf=
-8">
      <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf=
-8">
      <div class=3D"">EWG in Urbana voted between N4121, which proposed a
        <font class=3D"" face=3D"Courier">class basic_string_literal&lt;
          charT, traits, N &gt;</font> and N4236, which proposed to
        further develop the Clang/GCC UDL template extension. The
        decision was strongly in favor of N4121, which means the
        extension is a dead end. And, there=E2=80=99s a slot there for the
        traits I mentioned :) .</div>
      <div class=3D""><br class=3D"">
      </div>
      <div class=3D"">If you=E2=80=99re interested in future-proof compile-=
time
        string processing, the better methodology is to forgo the
        literal operator template extension and unpack the characters
        from an ordinary string literal, using <font class=3D""
          face=3D"Courier">std::index_sequence</font>, as outlined in
        N4121.</div>
      <div class=3D""><br class=3D"">
      </div>
      <div class=3D"">
        <div class=3D""><br class=3D"">
          <div class=3D"">
            <blockquote type=3D"cite" class=3D"">
              <div class=3D"">On 2015=E2=80=9307=E2=80=9306, at 1:33 PM, Lo=
uis Dionne &lt;<a
                  moz-do-not-send=3D"true"
                  href=3D"mailto:ldionne.2@gmail.com" class=3D"">ldionne.2@=
gmail.com</a>&gt;
                wrote:</div>
              <br class=3D"Apple-interchange-newline">
              <div class=3D"">
                <div dir=3D"ltr" 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;" class=3D"">
                  <div class=3D"">There's at least me, Roland Bock (with
                    sqlpp11), and Matt Bierner it seems. But I also
                    talked with many</div>
                  <div class=3D"">more people at conferences like C++Now
                    who would have needed compile-time strings badly.</div>
                  <div class=3D""><br class=3D"">
                  </div>
                  <div class=3D"">Let me clarify. I'm not opposed to
                    additional machinery, and I would even like it if we
                    had more tools</div>
                  <div class=3D"">to manipulate compile-time strings.
                    However, 90% of the use cases are super simple, and
                    what we</div>
                  <div class=3D"">need is nothing more than the Clang/GCC
                    provided templated string literal. Considering this
                    is a</div>
                  <div class=3D"">low hanging fruit and that more can be
                    added later, it would be sad to delay it 6 more
                    years just</div>
                  <div class=3D"">because this 10% of use cases is not
                    covered yet.</div>
                  <div class=3D""><br class=3D"">
                  </div>
                  <div class=3D"">Louis</div>
                </div>
              </div>
            </blockquote>
          </div>
          <br class=3D"">
        </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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--------------090406000008030001060807--

.

--Apple-Mail=_3C9A1A4D-B196-4CD6-89C8-92F165EE40F4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9307=E2=80=9306, at 4:30 PM, b17c0de@gmail.com wrote:
>=20
> N4121 is interesting. But it seems to me that N4121 and N3599 are orthogo=
nal proposals. I mean templated string UDLs are useful on their own with or=
 without basic_string_literal. I don't think there is any need to combine t=
hem as in N4236. Seems like it can be kept fairly simple, along the lines o=
f what N3599 proposes.

You can also get a char non-type parameter pack from a basic_string_literal=
, provided that it can bind to a template non-type parameter of reference t=
ype. so the feature would need justification for being a core language feat=
ure instead of a library. And, one main reason N4121 was favored was that i=
t=E2=80=99s faster (more efficient for the compiler) to process char array =
values instead of parameter packs. It=E2=80=99s also easier for the program=
mer, since arrays are manipulated by constexpr functions but packs require =
TMP.

Parameter packs provide the benefit of a distinct C++ type per string, but =
at a significant cost in compiler efficiency. A better way toward string-to=
-type mapping would be to allow temporary objects of literal type to bind t=
o template const& parameters. There=E2=80=99s a knot to be untied there, re=
lating to linkage and object uniqueness, but that problem needs solving any=
way. It=E2=80=99s the better way forward.

--=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=_3C9A1A4D-B196-4CD6-89C8-92F165EE40F4
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=9307=
=E2=80=9306, at 4:30 PM, <a href=3D"mailto:b17c0de@gmail.com" class=3D"">b1=
7c0de@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><di=
v class=3D""><div dir=3D"ltr" class=3D"">N4121 is interesting. But it seems=
 to me that&nbsp;N4121 and&nbsp;N3599 are orthogonal proposals. I mean temp=
lated string UDLs are useful on their own with or without&nbsp;<span style=
=3D"font-family: Courier;" class=3D"">basic_string_literal</span>. I don't =
think there is any need to combine them as in&nbsp;N4236.&nbsp;Seems like i=
t can be kept fairly simple, along the lines of what N3599 proposes.<br cla=
ss=3D""></div></div></blockquote><div><br class=3D""></div><div>You can als=
o get a <font face=3D"Courier" class=3D"">char</font> non-type parameter pa=
ck from a <font face=3D"Courier" class=3D"">basic_string_literal</font>, pr=
ovided that it can bind to a template non-type parameter of reference type.=
 so the feature would need justification for being a core language feature =
instead of a library. And, one main reason N4121 was favored was that it=E2=
=80=99s faster (more efficient for the compiler) to process char array valu=
es instead of parameter packs. It=E2=80=99s also easier for the programmer,=
 since arrays are manipulated by constexpr functions but packs require TMP.=
</div><div><br class=3D""></div><div>Parameter packs provide the benefit of=
 a distinct C++ type per string, but at a significant cost in compiler effi=
ciency. A better way toward string-to-type mapping would be to allow tempor=
ary objects of literal type to bind to template <font face=3D"Courier" clas=
s=3D"">const&amp;</font> parameters. There=E2=80=99s a knot to be untied th=
ere, relating to linkage and object uniqueness, but that problem needs solv=
ing anyway. It=E2=80=99s the better way forward.</div><div><br class=3D""><=
/div></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_3C9A1A4D-B196-4CD6-89C8-92F165EE40F4--

.

--Apple-Mail=_CF1425C1-0ED9-46EA-9C7A-3A6CA96B4895
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9307=E2=80=9306, at 4:39 PM, Roland Bock <rbock@eudoxos.de>=
 wrote:
>=20
> I would be all for N4121 if we could get rid of the size parameter.

N4121 needs that because it=E2=80=99s a container class. Getting rid of the=
 size parameter requires some other constexpr way of obtaining storage. Tha=
t pretty much boils down to predynamic storage, as far as I can tell, which=
 is still generally regarded pie in the sky.

Hopefully string_view will work over string_literal at compile time, to rou=
ghly the same effect. Completely ignoring the underlying string_literal and=
 using only the view sounds like a job for generalized lifetime extension.

--=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=_CF1425C1-0ED9-46EA-9C7A-3A6CA96B4895
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=9307=
=E2=80=9306, at 4:39 PM, Roland Bock &lt;<a href=3D"mailto:rbock@eudoxos.de=
" class=3D"">rbock@eudoxos.de</a>&gt; wrote:</div><br class=3D"Apple-interc=
hange-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: sta=
rt; text-indent: 0px; text-transform: none; white-space: normal; widows: au=
to; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rg=
b(255, 255, 255); float: none; display: inline !important;" class=3D"">I wo=
uld be all for N4121 if we could get rid of the size parameter.</span><br s=
tyle=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-v=
ariant: normal; font-weight: normal; letter-spacing: normal; line-height: n=
ormal; orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-st=
roke-width: 0px;" class=3D""></div></blockquote></div><br class=3D""><div c=
lass=3D"">N4121 needs that because it=E2=80=99s a container class. Getting =
rid of the size parameter requires some other <font face=3D"Courier" class=
=3D"">constexpr</font> way of obtaining storage. That pretty much boils dow=
n to predynamic storage, as far as I can tell, which is still generally reg=
arded pie in the sky.</div><div class=3D""><br class=3D""></div><div class=
=3D"">Hopefully <font face=3D"Courier" class=3D"">string_view</font> will w=
ork over <font face=3D"Courier" class=3D"">string_literal</font> at compile=
 time, to roughly the same effect. Completely ignoring the underlying <font=
 face=3D"Courier" class=3D"">string_literal</font> and using only the view =
sounds like a job for generalized lifetime extension.</div><div class=3D"">=
<br class=3D""></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_CF1425C1-0ED9-46EA-9C7A-3A6CA96B4895--

.

On Monday 06 July 2015 09:32:54 Bo Persson wrote:
> > The only solution in my view for this problem is to force the execution
> > charset to UTF-8. On most OS except for Windows, that's already the case.
> > The trouble is just convincing Windows and Microsoft compilers to be like
> > that.
> You have another player using EBCDIC. Not likely to give up on that either.

That's right, but that one already faces problems with people who assume that
everything is ASCII.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

On Monday 06 July 2015 16:37:52 David Krauss wrote:
> > Don't get me wrong. I do think we should fix the woeful lack of UTF-8 and
> > Unicode support in the language. Compared to QString and QTextCodec,
> > support  in the Standard Library is laughable.
>
> Why not make proposals?

I'm not interested. I might try and find the time to write a proposal about the
PMF math and I'm following closely string_literal, reflection, etc., but
writing for the runtime standard library has no appeal to me.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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_619_1099599029.1436197927452
Content-Type: multipart/alternative;
 boundary="----=_Part_620_1864097968.1436197927452"

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

I want to create a constexpr object from a UDL string. Like:

constexpr UUID =3D "123e4567-e89b-12d3-a456-426655440000"_uuid;

How can this be done with basic_string_literal without an addition to=20
string UDLs?

Am Montag, 6. Juli 2015 10:52:07 UTC+2 schrieb David Krauss:
>
>
> On 2015=E2=80=9307=E2=80=9306, at 4:30 PM, b17...@gmail.com <javascript:>=
 wrote:
>
> N4121 is interesting. But it seems to me that N4121 and N3599 are=20
> orthogonal proposals. I mean templated string UDLs are useful on their ow=
n=20
> with or without basic_string_literal. I don't think there is any need to=
=20
> combine them as in N4236. Seems like it can be kept fairly simple, along=
=20
> the lines of what N3599 proposes.
>
>
> You can also get a char non-type parameter pack from a=20
> basic_string_literal, provided that it can bind to a template non-type=20
> parameter of reference type. so the feature would need justification for=
=20
> being a core language feature instead of a library. And, one main reason=
=20
> N4121 was favored was that it=E2=80=99s faster (more efficient for the co=
mpiler) to=20
> process char array values instead of parameter packs. It=E2=80=99s also e=
asier for=20
> the programmer, since arrays are manipulated by constexpr functions but=
=20
> packs require TMP.
>
> Parameter packs provide the benefit of a distinct C++ type per string, bu=
t=20
> at a significant cost in compiler efficiency. A better way toward=20
> string-to-type mapping would be to allow temporary objects of literal typ=
e=20
> to bind to template const& parameters. There=E2=80=99s a knot to be untie=
d there,=20
> relating to linkage and object uniqueness, but that problem needs solving=
=20
> anyway. It=E2=80=99s the better way forward.
>
>

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

<div dir=3D"ltr">I want to create a constexpr object from a UDL string. Lik=
e:<br><br>constexpr UUID =3D "123e4567-e89b-12d3-a456-426655440000"_uuid;<b=
r><br>How can this be done with basic_string_literal without an addition to=
 string UDLs?<br><br>Am Montag, 6. Juli 2015 10:52:07 UTC+2 schrieb David K=
rauss:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:=
break-word"><br><div><blockquote type=3D"cite"><div>On 2015=E2=80=9307=E2=
=80=9306, at 4:30 PM, <a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"3ujEvGknh7wJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'ja=
vascript:';return true;" onclick=3D"this.href=3D'javascript:';return true;"=
>b17...@gmail.com</a> wrote:</div><br><div><div dir=3D"ltr">N4121 is intere=
sting. But it seems to me that&nbsp;N4121 and&nbsp;N3599 are orthogonal pro=
posals. I mean templated string UDLs are useful on their own with or withou=
t&nbsp;<span style=3D"font-family:Courier">basic_string_literal</span>. I d=
on't think there is any need to combine them as in&nbsp;N4236.&nbsp;Seems l=
ike it can be kept fairly simple, along the lines of what N3599 proposes.<b=
r></div></div></blockquote><div><br></div><div>You can also get a <font fac=
e=3D"Courier">char</font> non-type parameter pack from a <font face=3D"Cour=
ier">basic_string_literal</font>, provided that it can bind to a template n=
on-type parameter of reference type. so the feature would need justificatio=
n for being a core language feature instead of a library. And, one main rea=
son N4121 was favored was that it=E2=80=99s faster (more efficient for the =
compiler) to process char array values instead of parameter packs. It=E2=80=
=99s also easier for the programmer, since arrays are manipulated by conste=
xpr functions but packs require TMP.</div><div><br></div><div>Parameter pac=
ks provide the benefit of a distinct C++ type per string, but at a signific=
ant cost in compiler efficiency. A better way toward string-to-type mapping=
 would be to allow temporary objects of literal type to bind to template <f=
ont face=3D"Courier">const&amp;</font> parameters. There=E2=80=99s a knot t=
o be untied there, relating to linkage and object uniqueness, but that prob=
lem needs solving anyway. It=E2=80=99s the better way forward.</div><div><b=
r></div></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_620_1864097968.1436197927452--
------=_Part_619_1099599029.1436197927452--

.

On Monday 06 July 2015 08:52:07 b17c0de@gmail.com wrote:
> I want to create a constexpr object from a UDL string. Like:
>
> constexpr UUID = "123e4567-e89b-12d3-a456-426655440000"_uuid;
>
> How can this be done with basic_string_literal without an addition to
> string UDLs?

You were thinking of doing:

template <char... str, size_t N> operator""_uuid();

and operate on str[i].

Why can't your function operate on literal[i] ?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

--Apple-Mail=_F4F40FA6-6FEF-4D19-B398-A88AA10EFF66
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


Don=E2=80=99t use basic_string_literal. Try this <http://coliru.stacked-cro=
oked.com/a/0430f191347d77cd>.


> On 2015=E2=80=9307=E2=80=9306, at 11:52 PM, b17c0de@gmail.com wrote:
>=20
> I want to create a constexpr object from a UDL string. Like:
>=20
> constexpr UUID =3D "123e4567-e89b-12d3-a456-426655440000"_uuid;
>=20
> How can this be done with basic_string_literal without an addition to str=
ing UDLs?

--=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=_F4F40FA6-6FEF-4D19-B398-A88AA10EFF66
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""><b=
r class=3D""></div>Don=E2=80=99t use&nbsp;<font face=3D"Courier" class=3D""=
>basic_string_literal</font>. Try&nbsp;<a href=3D"http://coliru.stacked-cro=
oked.com/a/0430f191347d77cd" class=3D"">this</a>.<div class=3D""><br class=
=3D""></div><div class=3D""><br class=3D""></div><div class=3D""><div><bloc=
kquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9307=E2=80=93=
06, at 11:52 PM, <a href=3D"mailto:b17c0de@gmail.com" class=3D"">b17c0de@gm=
ail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><div class=
=3D""><div dir=3D"ltr" class=3D"">I want to create a constexpr object from =
a UDL string. Like:<br class=3D""><br class=3D"">constexpr UUID =3D "123e45=
67-e89b-12d3-a456-426655440000"_uuid;<br class=3D""><br class=3D"">How can =
this be done with basic_string_literal without an addition to string UDLs?<=
br class=3D""></div></div></blockquote><div><br class=3D""></div></div></di=
v></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_F4F40FA6-6FEF-4D19-B398-A88AA10EFF66--

.

------=_Part_806_1700363564.1436207770790
Content-Type: multipart/alternative;
 boundary="----=_Part_807_1445529519.1436207770790"

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

David,

I understand how and why N4121-style compile-time strings have a better=20
compile-time performance than type-level strings. However, type-level
strings are more powerful (strictly speaking) than constexpr strings.
Consider the following challenge:

Write a function `f` (it can be a template) which takes two arguments=20
representing strings known at compile-time and which statically asserts=20
that both strings are equal.

The solution with type-level strings:

    // Utilities
    template <char ...s>
    struct string { };

    template <char ...s1, char ...s2>
    constexpr std::false_type operator=3D=3D(string<s1...>, string<s2...>)=
=20
    { return {}; }

    template <char ...s>
    constexpr std::true_type operator=3D=3D(string<s...>, string<s...>)=20
    { return {}; }

    template <typename CharT, CharT ...c>
    constexpr auto operator""_s() { return string<c...>{}; }


    // And now the function
    template <typename S1, typename S2>
    void f(S1 s1, S2 s2) {
        static_assert(s1 =3D=3D s2, "");
    }


I know of no solution with strings =C3=A0 la N4121, and so (if I'm right) t=
he=20
claim=20
at the beginning of the paper that both approaches are equivalent is=20
downright=20
wrong. The thing is that the value of the string must be contained in the=
=20
type
of the object that represents that string, since passing an object as an=20
argument to a function discards constexpr-ness. More is explained in the=20
documentation of the Hana library [1].

Note that if the above challenge seems stupid, well it is. However, the=20
exact
same problem applies if you try to write a function which maps compile-time
strings to heterogeneous objects, for example. And this is a very, very=20
important use case for compile-time strings.

Now, you might be aware of all this already. However, your answer

    You can also get a char non-type parameter pack from a=20
basic_string_literal,=20
    provided that it can bind to a template non-type parameter of reference=
=20
type.=20
    so the feature would need justification for being a core language=20
feature=20
    instead of a library.=20

makes me think that you envision a different way of making this possible. I=
s
this right? If so, how might one get a template parameter from a=20
non-constexpr
basic_string_literal?

Regarding performance; anyone sane would do the hardcore compile-time=20
string=20
processing with constexpr functions, and then turn the result back into a=
=20
type-level string. The interface of the library would however be comprised=
=20
of=20
type-level strings, because that's what's required for most applications=20
anyway.

Regards,
Louis

[1]: http://ldionne.com/hana/#tutorial-appendix-constexpr-stripping


On Monday, 6 July 2015 10:52:07 UTC+2, David Krauss wrote:
>
>
> On 2015=E2=80=9307=E2=80=9306, at 4:30 PM, b17...@gmail.com <javascript:>=
 wrote:
>
> N4121 is interesting. But it seems to me that N4121 and N3599 are=20
> orthogonal proposals. I mean templated string UDLs are useful on their ow=
n=20
> with or without basic_string_literal. I don't think there is any need to=
=20
> combine them as in N4236. Seems like it can be kept fairly simple, along=
=20
> the lines of what N3599 proposes.
>
>
> You can also get a char non-type parameter pack from a=20
> basic_string_literal, provided that it can bind to a template non-type=20
> parameter of reference type. so the feature would need justification for=
=20
> being a core language feature instead of a library. And, one main reason=
=20
> N4121 was favored was that it=E2=80=99s faster (more efficient for the co=
mpiler) to=20
> process char array values instead of parameter packs. It=E2=80=99s also e=
asier for=20
> the programmer, since arrays are manipulated by constexpr functions but=
=20
> packs require TMP.
>
> Parameter packs provide the benefit of a distinct C++ type per string, bu=
t=20
> at a significant cost in compiler efficiency. A better way toward=20
> string-to-type mapping would be to allow temporary objects of literal typ=
e=20
> to bind to template const& parameters. There=E2=80=99s a knot to be untie=
d there,=20
> relating to linkage and object uniqueness, but that problem needs solving=
=20
> anyway. It=E2=80=99s the better way forward.
>
>

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

<div dir=3D"ltr"><div>David,</div><div><br></div><div>I understand how and =
why N4121-style compile-time strings have a better&nbsp;</div><div>compile-=
time performance than type-level strings. However, type-level</div><div>str=
ings are more powerful (strictly speaking) than constexpr strings.</div><di=
v>Consider the following challenge:</div><div><br></div><div>Write a functi=
on `f` (it can be a template) which takes two arguments&nbsp;</div><div>rep=
resenting strings known at compile-time and which statically asserts&nbsp;<=
/div><div>that both strings are equal.</div><div><br></div><div>The solutio=
n with type-level strings:</div><div><br></div><div>&nbsp; &nbsp; // Utilit=
ies</div><div>&nbsp; &nbsp; template &lt;char ...s&gt;</div><div>&nbsp; &nb=
sp; struct string { };</div><div><br></div><div>&nbsp; &nbsp; template &lt;=
char ...s1, char ...s2&gt;</div><div>&nbsp; &nbsp; constexpr std::false_typ=
e operator=3D=3D(string&lt;s1...&gt;, string&lt;s2...&gt;)&nbsp;</div><div>=
&nbsp; &nbsp; { return {}; }</div><div><br></div><div>&nbsp; &nbsp; templat=
e &lt;char ...s&gt;</div><div>&nbsp; &nbsp; constexpr std::true_type operat=
or=3D=3D(string&lt;s...&gt;, string&lt;s...&gt;)&nbsp;</div><div>&nbsp; &nb=
sp; { return {}; }</div><div><br></div><div>&nbsp; &nbsp; template &lt;type=
name CharT, CharT ...c&gt;</div><div>&nbsp; &nbsp; constexpr auto operator"=
"_s() { return string&lt;c...&gt;{}; }</div><div><br></div><div><br></div><=
div>&nbsp; &nbsp; // And now the function</div><div>&nbsp; &nbsp; template =
&lt;typename S1, typename S2&gt;</div><div>&nbsp; &nbsp; void f(S1 s1, S2 s=
2) {</div><div>&nbsp; &nbsp; &nbsp; &nbsp; static_assert(s1 =3D=3D s2, "");=
</div><div>&nbsp; &nbsp; }</div><div><br></div><div><br></div><div>I know o=
f no solution with strings =C3=A0 la N4121, and so (if I'm right) the claim=
&nbsp;</div><div>at the beginning of the paper that both approaches are equ=
ivalent is downright&nbsp;</div><div>wrong. The thing is that the value of =
the string must be contained in the type</div><div>of the object that repre=
sents that string, since passing an object as an&nbsp;</div><div>argument t=
o a function discards constexpr-ness. More is explained in the&nbsp;</div><=
div>documentation of the Hana library [1].</div><div><br></div><div>Note th=
at if the above challenge seems stupid, well it is. However, the exact</div=
><div>same problem applies if you try to write a function which maps compil=
e-time</div><div>strings to heterogeneous objects, for example. And this is=
 a very, very&nbsp;</div><div>important use case for compile-time strings.<=
/div><div><br></div><div>Now, you might be aware of all this already. Howev=
er, your answer</div><div><br></div><div>&nbsp; &nbsp; You can also get a c=
har non-type parameter pack from a basic_string_literal,&nbsp;</div><div>&n=
bsp; &nbsp; provided that it can bind to a template non-type parameter of r=
eference type.&nbsp;</div><div>&nbsp; &nbsp; so the feature would need just=
ification for being a core language feature&nbsp;</div><div>&nbsp; &nbsp; i=
nstead of a library.&nbsp;</div><div><br></div><div>makes me think that you=
 envision a different way of making this possible. Is</div><div>this right?=
 If so, how might one get a template parameter from a non-constexpr</div><d=
iv>basic_string_literal?</div><div><br></div><div>Regarding performance; an=
yone sane would do the hardcore compile-time string&nbsp;</div><div>process=
ing with constexpr functions, and then turn the result back into a&nbsp;</d=
iv><div>type-level string. The interface of the library would however be co=
mprised of&nbsp;</div><div>type-level strings, because that's what's requir=
ed for most applications anyway.</div><div><br></div><div>Regards,</div><di=
v>Louis</div><div><br></div><div>[1]: http://ldionne.com/hana/#tutorial-app=
endix-constexpr-stripping</div><div><br></div><br>On Monday, 6 July 2015 10=
:52:07 UTC+2, David Krauss  wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div style=3D"word-wrap:break-word"><br><div><blockquote type=3D"cite=
"><div>On 2015=E2=80=9307=E2=80=9306, at 4:30 PM, <a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"3ujEvGknh7wJ" rel=3D"nofollow" on=
mousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">b17...@gmail.com</a> wrote:</div><br><div><d=
iv dir=3D"ltr">N4121 is interesting. But it seems to me that&nbsp;N4121 and=
&nbsp;N3599 are orthogonal proposals. I mean templated string UDLs are usef=
ul on their own with or without&nbsp;<span style=3D"font-family:Courier">ba=
sic_string_literal</span>. I don't think there is any need to combine them =
as in&nbsp;N4236.&nbsp;Seems like it can be kept fairly simple, along the l=
ines of what N3599 proposes.<br></div></div></blockquote><div><br></div><di=
v>You can also get a <font face=3D"Courier">char</font> non-type parameter =
pack from a <font face=3D"Courier">basic_string_literal</font>, provided th=
at it can bind to a template non-type parameter of reference type. so the f=
eature would need justification for being a core language feature instead o=
f a library. And, one main reason N4121 was favored was that it=E2=80=99s f=
aster (more efficient for the compiler) to process char array values instea=
d of parameter packs. It=E2=80=99s also easier for the programmer, since ar=
rays are manipulated by constexpr functions but packs require TMP.</div><di=
v><br></div><div>Parameter packs provide the benefit of a distinct C++ type=
 per string, but at a significant cost in compiler efficiency. A better way=
 toward string-to-type mapping would be to allow temporary objects of liter=
al type to bind to template <font face=3D"Courier">const&amp;</font> parame=
ters. There=E2=80=99s a knot to be untied there, relating to linkage and ob=
ject uniqueness, but that problem needs solving anyway. It=E2=80=99s the be=
tter way forward.</div><div><br></div></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_807_1445529519.1436207770790--
------=_Part_806_1700363564.1436207770790--

.

------=_Part_879_1306793784.1436207887836
Content-Type: multipart/alternative;
 boundary="----=_Part_880_919860645.1436207887836"

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

Thanks for this. I had tried something like this but it didn't work because=
=20
I tried to use static_assert for error checking. The parameters of the UDL=
=20
function aren't constexpr so they can't be used with static_assert but out=
=20
of these non-constexpr parameters you can construct a constexpr UUID=20
object? How does that work?

On Monday, July 6, 2015 at 6:49:05 PM UTC+2, David Krauss wrote:
>
>
> Don=E2=80=99t use basic_string_literal. Try this=20
> <http://coliru.stacked-crooked.com/a/0430f191347d77cd>.
>
>
> On 2015=E2=80=9307=E2=80=9306, at 11:52 PM, b17...@gmail.com <javascript:=
> wrote:
>
> I want to create a constexpr object from a UDL string. Like:
>
> constexpr UUID =3D "123e4567-e89b-12d3-a456-426655440000"_uuid;
>
> How can this be done with basic_string_literal without an addition to=20
> string UDLs?
>
>
>

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

<div dir=3D"ltr">Thanks for this. I had tried something like this but it di=
dn't work because I tried to use static_assert for error checking. The para=
meters of the UDL function aren't constexpr so they can't be used with stat=
ic_assert but out of these non-constexpr parameters you can construct a con=
stexpr UUID object?&nbsp;How does that work?<br><br>On Monday, July 6, 2015=
 at 6:49:05 PM UTC+2, David Krauss wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div style=3D"word-wrap:break-word"><div><br></div>Don=E2=80=99t=
 use&nbsp;<font face=3D"Courier">basic_string_literal</font>. Try&nbsp;<a h=
ref=3D"http://coliru.stacked-crooked.com/a/0430f191347d77cd" target=3D"_bla=
nk" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?=
q\75http%3A%2F%2Fcoliru.stacked-crooked.com%2Fa%2F0430f191347d77cd\46sa\75D=
\46sntz\0751\46usg\75AFQjCNGDn-iljv_LbDqk9Tu9b2LPu4unWg';return true;" oncl=
ick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fcoliru.stack=
ed-crooked.com%2Fa%2F0430f191347d77cd\46sa\75D\46sntz\0751\46usg\75AFQjCNGD=
n-iljv_LbDqk9Tu9b2LPu4unWg';return true;">this</a>.<div><br></div><div><br>=
</div><div><div><blockquote type=3D"cite"><div>On 2015=E2=80=9307=E2=80=930=
6, at 11:52 PM, <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"nUeoz5-6hRAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascri=
pt:';return true;" onclick=3D"this.href=3D'javascript:';return true;">b17..=
..@gmail.com</a> wrote:</div><br><div><div dir=3D"ltr">I want to create a co=
nstexpr object from a UDL string. Like:<br><br>constexpr UUID =3D "123e4567=
-e89b-12d3-a456-<wbr>426655440000"_uuid;<br><br>How can this be done with b=
asic_string_literal without an addition to string UDLs?<br></div></div></bl=
ockquote><div><br></div></div></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_880_919860645.1436207887836--
------=_Part_879_1306793784.1436207887836--

.

------=_Part_7329_1498609718.1436211777574
Content-Type: multipart/alternative;
 boundary="----=_Part_7330_1445318410.1436211777574"

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

For completeness; I don't know what I was thinking, but I didn't test my=20
solution
and it does not work as-is. Here's a corrected solution:


    #include <type_traits>

    // ...same as before...

    template <typename S1, typename S2>
    void f(S1 s1, S2 s2) {
        auto eq =3D s1 =3D=3D s2;
        static_assert(eq, "");
    }

    int main() {
        f("abc"_s, "abc"_s);
    }

Regards,
Louis


On Monday, 6 July 2015 20:36:10 UTC+2, Louis Dionne wrote:
>
> David,
>
> I understand how and why N4121-style compile-time strings have a better=
=20
> compile-time performance than type-level strings. However, type-level
> strings are more powerful (strictly speaking) than constexpr strings.
> Consider the following challenge:
>
> Write a function `f` (it can be a template) which takes two arguments=20
> representing strings known at compile-time and which statically asserts=
=20
> that both strings are equal.
>
> The solution with type-level strings:
>
>     // Utilities
>     template <char ...s>
>     struct string { };
>
>     template <char ...s1, char ...s2>
>     constexpr std::false_type operator=3D=3D(string<s1...>, string<s2...>=
)=20
>     { return {}; }
>
>     template <char ...s>
>     constexpr std::true_type operator=3D=3D(string<s...>, string<s...>)=
=20
>     { return {}; }
>
>     template <typename CharT, CharT ...c>
>     constexpr auto operator""_s() { return string<c...>{}; }
>
>
>     // And now the function
>     template <typename S1, typename S2>
>     void f(S1 s1, S2 s2) {
>         static_assert(s1 =3D=3D s2, "");
>     }
>
>
> I know of no solution with strings =C3=A0 la N4121, and so (if I'm right)=
 the=20
> claim=20
> at the beginning of the paper that both approaches are equivalent is=20
> downright=20
> wrong. The thing is that the value of the string must be contained in the=
=20
> type
> of the object that represents that string, since passing an object as an=
=20
> argument to a function discards constexpr-ness. More is explained in the=
=20
> documentation of the Hana library [1].
>
> Note that if the above challenge seems stupid, well it is. However, the=
=20
> exact
> same problem applies if you try to write a function which maps compile-ti=
me
> strings to heterogeneous objects, for example. And this is a very, very=
=20
> important use case for compile-time strings.
>
> Now, you might be aware of all this already. However, your answer
>
>     You can also get a char non-type parameter pack from a=20
> basic_string_literal,=20
>     provided that it can bind to a template non-type parameter of=20
> reference type.=20
>     so the feature would need justification for being a core language=20
> feature=20
>     instead of a library.=20
>
> makes me think that you envision a different way of making this possible.=
=20
> Is
> this right? If so, how might one get a template parameter from a=20
> non-constexpr
> basic_string_literal?
>
> Regarding performance; anyone sane would do the hardcore compile-time=20
> string=20
> processing with constexpr functions, and then turn the result back into a=
=20
> type-level string. The interface of the library would however be comprise=
d=20
> of=20
> type-level strings, because that's what's required for most applications=
=20
> anyway.
>
> Regards,
> Louis
>
> [1]: http://ldionne.com/hana/#tutorial-appendix-constexpr-stripping
>
>
> On Monday, 6 July 2015 10:52:07 UTC+2, David Krauss wrote:
>>
>>
>> On 2015=E2=80=9307=E2=80=9306, at 4:30 PM, b17...@gmail.com wrote:
>>
>> N4121 is interesting. But it seems to me that N4121 and N3599 are=20
>> orthogonal proposals. I mean templated string UDLs are useful on their o=
wn=20
>> with or without basic_string_literal. I don't think there is any need to=
=20
>> combine them as in N4236. Seems like it can be kept fairly simple, along=
=20
>> the lines of what N3599 proposes.
>>
>>
>> You can also get a char non-type parameter pack from a=20
>> basic_string_literal, provided that it can bind to a template non-type=
=20
>> parameter of reference type. so the feature would need justification for=
=20
>> being a core language feature instead of a library. And, one main reason=
=20
>> N4121 was favored was that it=E2=80=99s faster (more efficient for the c=
ompiler) to=20
>> process char array values instead of parameter packs. It=E2=80=99s also =
easier for=20
>> the programmer, since arrays are manipulated by constexpr functions but=
=20
>> packs require TMP.
>>
>> Parameter packs provide the benefit of a distinct C++ type per string,=
=20
>> but at a significant cost in compiler efficiency. A better way toward=20
>> string-to-type mapping would be to allow temporary objects of literal ty=
pe=20
>> to bind to template const& parameters. There=E2=80=99s a knot to be unti=
ed=20
>> there, relating to linkage and object uniqueness, but that problem needs=
=20
>> solving anyway. It=E2=80=99s the better way forward.
>>
>>

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

<div dir=3D"ltr"><div>For completeness; I don't know what I was thinking, b=
ut I didn't test my solution</div><div>and it does not work as-is. Here's a=
 corrected solution:</div><div><br></div><div><div><br></div><div>&nbsp; &n=
bsp; #include &lt;type_traits&gt;</div><div><br></div><div>&nbsp; &nbsp; //=
 ...same as before...</div><div><br></div><div>&nbsp; &nbsp; template &lt;t=
ypename S1, typename S2&gt;</div><div>&nbsp; &nbsp; void f(S1 s1, S2 s2) {<=
/div><div>&nbsp; &nbsp; &nbsp; &nbsp; auto eq =3D s1 =3D=3D s2;</div><div>&=
nbsp; &nbsp; &nbsp; &nbsp; static_assert(eq, "");</div><div>&nbsp; &nbsp; }=
</div><div><br></div><div>&nbsp; &nbsp; int main() {</div><div>&nbsp; &nbsp=
; &nbsp; &nbsp; f("abc"_s, "abc"_s);</div><div>&nbsp; &nbsp; }</div></div><=
div><br></div><div>Regards,</div><div>Louis</div><br><br>On Monday, 6 July =
2015 20:36:10 UTC+2, Louis Dionne  wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><div>David,</div><div><br></div><div>I understa=
nd how and why N4121-style compile-time strings have a better&nbsp;</div><d=
iv>compile-time performance than type-level strings. However, type-level</d=
iv><div>strings are more powerful (strictly speaking) than constexpr string=
s.</div><div>Consider the following challenge:</div><div><br></div><div>Wri=
te a function `f` (it can be a template) which takes two arguments&nbsp;</d=
iv><div>representing strings known at compile-time and which statically ass=
erts&nbsp;</div><div>that both strings are equal.</div><div><br></div><div>=
The solution with type-level strings:</div><div><br></div><div>&nbsp; &nbsp=
; // Utilities</div><div>&nbsp; &nbsp; template &lt;char ...s&gt;</div><div=
>&nbsp; &nbsp; struct string { };</div><div><br></div><div>&nbsp; &nbsp; te=
mplate &lt;char ...s1, char ...s2&gt;</div><div>&nbsp; &nbsp; constexpr std=
::false_type operator=3D=3D(string&lt;s1...&gt;, string&lt;s2...&gt;)&nbsp;=
</div><div>&nbsp; &nbsp; { return {}; }</div><div><br></div><div>&nbsp; &nb=
sp; template &lt;char ...s&gt;</div><div>&nbsp; &nbsp; constexpr std::true_=
type operator=3D=3D(string&lt;s...&gt;, string&lt;s...&gt;)&nbsp;</div><div=
>&nbsp; &nbsp; { return {}; }</div><div><br></div><div>&nbsp; &nbsp; templa=
te &lt;typename CharT, CharT ...c&gt;</div><div>&nbsp; &nbsp; constexpr aut=
o operator""_s() { return string&lt;c...&gt;{}; }</div><div><br></div><div>=
<br></div><div>&nbsp; &nbsp; // And now the function</div><div>&nbsp; &nbsp=
; template &lt;typename S1, typename S2&gt;</div><div>&nbsp; &nbsp; void f(=
S1 s1, S2 s2) {</div><div>&nbsp; &nbsp; &nbsp; &nbsp; static_assert(s1 =3D=
=3D s2, "");</div><div>&nbsp; &nbsp; }</div><div><br></div><div><br></div><=
div>I know of no solution with strings =C3=A0 la N4121, and so (if I'm righ=
t) the claim&nbsp;</div><div>at the beginning of the paper that both approa=
ches are equivalent is downright&nbsp;</div><div>wrong. The thing is that t=
he value of the string must be contained in the type</div><div>of the objec=
t that represents that string, since passing an object as an&nbsp;</div><di=
v>argument to a function discards constexpr-ness. More is explained in the&=
nbsp;</div><div>documentation of the Hana library [1].</div><div><br></div>=
<div>Note that if the above challenge seems stupid, well it is. However, th=
e exact</div><div>same problem applies if you try to write a function which=
 maps compile-time</div><div>strings to heterogeneous objects, for example.=
 And this is a very, very&nbsp;</div><div>important use case for compile-ti=
me strings.</div><div><br></div><div>Now, you might be aware of all this al=
ready. However, your answer</div><div><br></div><div>&nbsp; &nbsp; You can =
also get a char non-type parameter pack from a basic_string_literal,&nbsp;<=
/div><div>&nbsp; &nbsp; provided that it can bind to a template non-type pa=
rameter of reference type.&nbsp;</div><div>&nbsp; &nbsp; so the feature wou=
ld need justification for being a core language feature&nbsp;</div><div>&nb=
sp; &nbsp; instead of a library.&nbsp;</div><div><br></div><div>makes me th=
ink that you envision a different way of making this possible. Is</div><div=
>this right? If so, how might one get a template parameter from a non-const=
expr</div><div>basic_string_literal?</div><div><br></div><div>Regarding per=
formance; anyone sane would do the hardcore compile-time string&nbsp;</div>=
<div>processing with constexpr functions, and then turn the result back int=
o a&nbsp;</div><div>type-level string. The interface of the library would h=
owever be comprised of&nbsp;</div><div>type-level strings, because that's w=
hat's required for most applications anyway.</div><div><br></div><div>Regar=
ds,</div><div>Louis</div><div><br></div><div>[1]: <a href=3D"http://ldionne=
..com/hana/#tutorial-appendix-constexpr-stripping" target=3D"_blank" rel=3D"=
nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A=
%2F%2Fldionne.com%2Fhana%2F%23tutorial-appendix-constexpr-stripping\46sa\75=
D\46sntz\0751\46usg\75AFQjCNHh-fQUXE56lhOrhPO1PqXxqG9_Ww';return true;" onc=
lick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fldionne.com=
%2Fhana%2F%23tutorial-appendix-constexpr-stripping\46sa\75D\46sntz\0751\46u=
sg\75AFQjCNHh-fQUXE56lhOrhPO1PqXxqG9_Ww';return true;">http://ldionne.com/h=
ana/#<wbr>tutorial-appendix-constexpr-<wbr>stripping</a></div><div><br></di=
v><br>On Monday, 6 July 2015 10:52:07 UTC+2, David Krauss  wrote:<blockquot=
e 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"><br><div>=
<blockquote type=3D"cite"><div>On 2015=E2=80=9307=E2=80=9306, at 4:30 PM, <=
a rel=3D"nofollow">b17...@gmail.com</a> wrote:</div><br><div><div dir=3D"lt=
r">N4121 is interesting. But it seems to me that&nbsp;N4121 and&nbsp;N3599 =
are orthogonal proposals. I mean templated string UDLs are useful on their =
own with or without&nbsp;<span style=3D"font-family:Courier">basic_string_l=
iteral</span>. I don't think there is any need to combine them as in&nbsp;N=
4236.&nbsp;Seems like it can be kept fairly simple, along the lines of what=
 N3599 proposes.<br></div></div></blockquote><div><br></div><div>You can al=
so get a <font face=3D"Courier">char</font> non-type parameter pack from a =
<font face=3D"Courier">basic_string_literal</font>, provided that it can bi=
nd to a template non-type parameter of reference type. so the feature would=
 need justification for being a core language feature instead of a library.=
 And, one main reason N4121 was favored was that it=E2=80=99s faster (more =
efficient for the compiler) to process char array values instead of paramet=
er packs. It=E2=80=99s also easier for the programmer, since arrays are man=
ipulated by constexpr functions but packs require TMP.</div><div><br></div>=
<div>Parameter packs provide the benefit of a distinct C++ type per string,=
 but at a significant cost in compiler efficiency. A better way toward stri=
ng-to-type mapping would be to allow temporary objects of literal type to b=
ind to template <font face=3D"Courier">const&amp;</font> parameters. There=
=E2=80=99s a knot to be untied there, relating to linkage and object unique=
ness, but that problem needs solving anyway. It=E2=80=99s the better way fo=
rward.</div><div><br></div></div></div></blockquote></div></blockquote></di=
v>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_7330_1445318410.1436211777574--
------=_Part_7329_1498609718.1436211777574--

.

------=_Part_8_1967973408.1436378283456
Content-Type: multipart/alternative;
 boundary="----=_Part_9_1382297175.1436378283456"

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

On Monday, July 6, 2015 at 8:15:59 AM UTC+2, David Krauss wrote:
>
>
> What do you mean, arbitrary? Unprefixed strings use the execution=20
> character set. u8 strings use UTF-8. The same goes for character=20
> literals, now that the u8 prefix exists there too, although multibyte=20
> characters must be treated as substrings either way.
>

I think what Thiago Macieira meant was that you can't distinguish between "=
"=20
and u8"" based on its type (e.g. overloading, std::is_same, etc) since both=
=20
are char.

Is there a problem with letting unsigned char stand-in for char8_t? I mean,=
=20
> changing types has its own problems either way, but I don=E2=80=99t see t=
he=20
> advantage of an additional type.
>

unsigned char is not sufficient here because char's signed-ness is=20
implementation-defined which means that on a platform where char is=20
actually unsigned char nothing would change.

Note: I'm currently working on a proposal for char8_t. Sure, yet another=20
character type is not perfect but it's the only way to make UTF-8 string=20
literals (and in the future UTF-8 character literals) usable. For (an=20
incomplete) reference see my post from a few weeks ago: Distinct type of=20
array elements in UTF-8 string literals (char8_t).=20
<https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/uOAhnhW=
6kCc>

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

<div dir=3D"ltr">On Monday, July 6, 2015 at 8:15:59 AM UTC+2, David Krauss =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:=
break-word"><div><div><br></div><div>What do you mean, arbitrary? Unprefixe=
d strings use the execution character set. <font face=3D"Courier">u8</font>=
 strings use UTF-8. The same goes for character literals, now that the <fon=
t face=3D"Courier">u8</font> prefix exists there too, although multibyte ch=
aracters must be treated as substrings either way.</div></div></div></block=
quote><div><br></div><div>I think what Thiago Macieira=C2=A0meant was that =
you can&#39;t distinguish between <font face=3D"courier new, monospace">&qu=
ot;&quot;</font> and <font face=3D"courier new, monospace">u8&quot;&quot;</=
font> based on its type (e.g. overloading, <font face=3D"courier new, monos=
pace">std::is_same</font>, etc) since both are <font face=3D"courier new, m=
onospace">char</font>.</div><div><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><div style=3D"word-wrap:break-word"><div><div></div><div>Is th=
ere a problem with letting <font face=3D"Courier">unsigned char</font> stan=
d-in for <font face=3D"Courier">char8_t</font>? I mean, changing types has =
its own problems either way, but I don=E2=80=99t see the advantage of an ad=
ditional type.</div></div></div></blockquote><div><br></div><div><font face=
=3D"courier new, monospace">unsigned char</font>=C2=A0is not sufficient her=
e because <font face=3D"courier new, monospace">char</font>&#39;s signed-ne=
ss is implementation-defined which means that on a platform where <font fac=
e=3D"courier new, monospace">char</font> is actually <font face=3D"courier =
new, monospace">unsigned char</font> nothing would change.</div><div><br></=
div><div>Note: I&#39;m currently working on a proposal for <font face=3D"co=
urier new, monospace">char8_t</font>. Sure, yet another character type is n=
ot perfect but it&#39;s the only way to make UTF-8 string literals (and in =
the future UTF-8 character literals) usable. For (an incomplete) reference =
see my post from a few weeks ago: <a href=3D"https://groups.google.com/a/is=
ocpp.org/forum/#!topic/std-proposals/uOAhnhW6kCc">Distinct type of array el=
ements in UTF-<span class=3D"s1">8</span> string literals (char8_t).</a></d=
iv>















</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_9_1382297175.1436378283456--
------=_Part_8_1967973408.1436378283456--

.

2015-07-08 19:58 GMT+02:00 Max Truxa <me@maxtruxa.com>:
> On Monday, July 6, 2015 at 8:15:59 AM UTC+2, David Krauss wrote:
>> Is there a problem with letting unsigned char stand-in for char8_t? I
>> mean, changing types has its own problems either way, but I don=E2=80=99=
t see the
>> advantage of an additional type.
>
> unsigned char is not sufficient here because char's signed-ness is
> implementation-defined which means that on a platform where char is actua=
lly
> unsigned char nothing would change.

This statement is misleading. Plain "char", "signed char", and
"unsigned char" are always three different types. There does not exist
a platform, where char is actually unsigned char (or signed char),
even though char is either a signed or an unsigned type:

#include <type_traits>

static_assert(!std::is_same<char, unsigned char>() &&
                    !std::is_same<char, signed char>(), "char is different"=
);


- Daniel

--=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_31_143599373.1436380225608
Content-Type: multipart/alternative;
 boundary="----=_Part_32_431169482.1436380225608"

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

On Wednesday, July 8, 2015 at 8:12:19 PM UTC+2, Daniel Kr=C3=BCgler wrote:
>
>
> This statement is misleading. Plain "char", "signed char", and=20
> "unsigned char" are always three different types. There does not exist=20
> a platform, where char is actually unsigned char (or signed char),=20
> even though char is either a signed or an unsigned type:=20
>

That didn't come across as I wanted it to. You are right, obviously.=20
Initially I intended to refer to Bo Persson's comment about the persisting=
=20
ambiguity regarding e.g. uint8_t when overloading but that got lost=20
somehow...

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

<div dir=3D"ltr">On Wednesday, July 8, 2015 at 8:12:19 PM UTC+2, Daniel Kr=
=C3=BCgler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>This stat=
ement is misleading. Plain &quot;char&quot;, &quot;signed char&quot;, and
<br>&quot;unsigned char&quot; are always three different types. There does =
not exist
<br>a platform, where char is actually unsigned char (or signed char),
<br>even though char is either a signed or an unsigned type:
<br></blockquote><div><br></div><div>That didn&#39;t come across as I wante=
d it to. You are right, obviously. Initially I intended to refer to Bo Pers=
son&#39;s comment about the persisting ambiguity regarding e.g. <font face=
=3D"courier new, monospace">uint8_t</font><font face=3D"arial, sans-serif">=
=C2=A0when overloading but that got lost somehow..</font>.</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_32_431169482.1436380225608--
------=_Part_31_143599373.1436380225608--

.