------=_Part_1361_1721562336.1423286270064
Content-Type: multipart/alternative;
 boundary="----=_Part_1362_1251005121.1423286270064"

------=_Part_1362_1251005121.1423286270064
Content-Type: text/plain; charset=UTF-8

I wrote up a draft of a proposal for 2 utilities for making constexpr
string_view string literals and constexpr array<string_view,N> arrays of
string literals.

https://github.com/fmatthew5876/stdcxx-sv-literal/blob/master/proposal/draft.md

I'm using these tools and I find them very useful. Do you agree that these
would be very useful to have? If not, how would you define string literals
in modern C++?

--

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

<div dir=3D"ltr">I wrote up a draft of a proposal for 2 utilities for makin=
g constexpr string_view string literals and constexpr array&lt;string_view,=
N&gt; arrays of string literals.<div><br></div><div>https://github.com/fmat=
thew5876/stdcxx-sv-literal/blob/master/proposal/draft.md<br></div><div><br>=
</div><div>I'm using these tools and I find them very useful. Do you agree =
that these would be very useful to have? If not, how would you define strin=
g literals in modern C++?</div><div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_1362_1251005121.1423286270064--
------=_Part_1361_1721562336.1423286270064--

.

------=_Part_2336_648339440.1423411709050
Content-Type: multipart/alternative;
 boundary="----=_Part_2337_308943202.1423411709050"

------=_Part_2337_308943202.1423411709050
Content-Type: text/plain; charset=UTF-8



On Saturday, February 7, 2015 at 12:17:50 AM UTC-5, Matthew Fioravante
wrote:
>
> I wrote up a draft of a proposal for 2 utilities for making constexpr
> string_view string literals and constexpr array<string_view,N> arrays of
> string literals.
>
>
> https://github.com/fmatthew5876/stdcxx-sv-literal/blob/master/proposal/draft.md
>
> I'm using these tools and I find them very useful. Do you agree that these
> would be very useful to have? If not, how would you define string literals
> in modern C++?
>
>
I like it, and it's a small enough library change that they might go for it.

Editorially, I would suggest that you not recap the reasons why string_view
exists. Since that's already part of the library fundamentals TS at this
point, you should assume your audience knows both that string_view exists
and why. You should focus more on the specific deficiencies of string_view
with regard to string literals and strlen.

--

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

<div dir=3D"ltr"><br><br>On Saturday, February 7, 2015 at 12:17:50 AM UTC-5=
, Matthew Fioravante wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">I wrote up a draft of a proposal for 2 utilities for making c=
onstexpr string_view string literals and constexpr array&lt;string_view,N&g=
t; arrays of string literals.<div><br></div><div><a href=3D"https://github.=
com/fmatthew5876/stdcxx-sv-literal/blob/master/proposal/draft.md" target=3D=
"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://www.google.co=
m/url?q\75https%3A%2F%2Fgithub.com%2Ffmatthew5876%2Fstdcxx-sv-literal%2Fblo=
b%2Fmaster%2Fproposal%2Fdraft.md\46sa\75D\46sntz\0751\46usg\75AFQjCNHiwk_kX=
OpaJEvwxvNmTotGudWRdQ';return true;" onclick=3D"this.href=3D'https://www.go=
ogle.com/url?q\75https%3A%2F%2Fgithub.com%2Ffmatthew5876%2Fstdcxx-sv-litera=
l%2Fblob%2Fmaster%2Fproposal%2Fdraft.md\46sa\75D\46sntz\0751\46usg\75AFQjCN=
Hiwk_kXOpaJEvwxvNmTotGudWRdQ';return true;">https://github.com/<wbr>fmatthe=
w5876/stdcxx-sv-<wbr>literal/blob/master/proposal/<wbr>draft.md</a><br></di=
v><div><br></div><div>I'm using these tools and I find them very useful. Do=
 you agree that these would be very useful to have? If not, how would you d=
efine string literals in modern C++?</div><div><br></div></div></blockquote=
><div><br>I like it, and it's a small enough library change that they might=
 go for it.<br><br>Editorially, I would suggest that you not recap the reas=
ons why string_view exists. Since that's already part of the library fundam=
entals TS at this point, you should assume your audience knows both that st=
ring_view exists and why. You should focus more on the specific deficiencie=
s of string_view with regard to string literals and strlen.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_2337_308943202.1423411709050--
------=_Part_2336_648339440.1423411709050--

.

------=_Part_151_1225726638.1423413318919
Content-Type: multipart/alternative;
 boundary="----=_Part_152_2124462842.1423413318919"

------=_Part_152_2124462842.1423413318919
Content-Type: text/plain; charset=UTF-8

Thanks for your feedback. I've edited the draft with your suggestions.

On Sunday, February 8, 2015 at 11:08:29 AM UTC-5, Nicol Bolas wrote:
>
>
>
> On Saturday, February 7, 2015 at 12:17:50 AM UTC-5, Matthew Fioravante
> wrote:
>>
>> I wrote up a draft of a proposal for 2 utilities for making constexpr
>> string_view string literals and constexpr array<string_view,N> arrays of
>> string literals.
>>
>>
>> https://github.com/fmatthew5876/stdcxx-sv-literal/blob/master/proposal/draft.md
>>
>> I'm using these tools and I find them very useful. Do you agree that
>> these would be very useful to have? If not, how would you define string
>> literals in modern C++?
>>
>>
> I like it, and it's a small enough library change that they might go for
> it.
>
> Editorially, I would suggest that you not recap the reasons why
> string_view exists. Since that's already part of the library fundamentals
> TS at this point, you should assume your audience knows both that
> string_view exists and why. You should focus more on the specific
> deficiencies of string_view with regard to string literals and strlen.
>

--

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

<div dir=3D"ltr">Thanks for your feedback. I've edited the draft with your =
suggestions.<br><br>On Sunday, February 8, 2015 at 11:08:29 AM UTC-5, Nicol=
 Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<br><br>On Saturday, February 7, 2015 at 12:17:50 AM UTC-5, Matthew Fiorava=
nte 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">I wrote =
up a draft of a proposal for 2 utilities for making constexpr string_view s=
tring literals and constexpr array&lt;string_view,N&gt; arrays of string li=
terals.<div><br></div><div><a href=3D"https://github.com/fmatthew5876/stdcx=
x-sv-literal/blob/master/proposal/draft.md" rel=3D"nofollow" target=3D"_bla=
nk" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%=
2Fgithub.com%2Ffmatthew5876%2Fstdcxx-sv-literal%2Fblob%2Fmaster%2Fproposal%=
2Fdraft.md\46sa\75D\46sntz\0751\46usg\75AFQjCNHiwk_kXOpaJEvwxvNmTotGudWRdQ'=
;return true;" onclick=3D"this.href=3D'https://www.google.com/url?q\75https=
%3A%2F%2Fgithub.com%2Ffmatthew5876%2Fstdcxx-sv-literal%2Fblob%2Fmaster%2Fpr=
oposal%2Fdraft.md\46sa\75D\46sntz\0751\46usg\75AFQjCNHiwk_kXOpaJEvwxvNmTotG=
udWRdQ';return true;">https://github.com/<wbr>fmatthew5876/stdcxx-sv-<wbr>l=
iteral/blob/master/proposal/<wbr>draft.md</a><br></div><div><br></div><div>=
I'm using these tools and I find them very useful. Do you agree that these =
would be very useful to have? If not, how would you define string literals =
in modern C++?</div><div><br></div></div></blockquote><div><br>I like it, a=
nd it's a small enough library change that they might go for it.<br><br>Edi=
torially, I would suggest that you not recap the reasons why string_view ex=
ists. Since that's already part of the library fundamentals TS at this poin=
t, you should assume your audience knows both that string_view exists and w=
hy. You should focus more on the specific deficiencies of string_view with =
regard to string literals and strlen.<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_152_2124462842.1423413318919--
------=_Part_151_1225726638.1423413318919--

.

------=_Part_2580_220408256.1423507816382
Content-Type: multipart/alternative;
 boundary="----=_Part_2581_2139751164.1423507816382"

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

On Friday, February 6, 2015 at 9:17:50 PM UTC-8, Matthew Fioravante wrote:
>
> I wrote up a draft of a proposal for 2 utilities for making constexpr=20
> string_view string literals and constexpr array<string_view,N> arrays of=
=20
> string literals.
>
>
> https://github.com/fmatthew5876/stdcxx-sv-literal/blob/master/proposal/dr=
aft.md
>
> I'm using these tools and I find them very useful. Do you agree that thes=
e=20
> would be very useful to have? If not, how would you define string literal=
s=20
> in modern C++?
>

I have two questions after reading your proposal, which I think you should=
=20
address =E2=80=94 presumably to rebut them =E2=80=94 because otherwise it s=
eems like you're=20
ignoring them.

(A) Why not change the definition of string literals in C++1z to be=20
"constexpr const char [N]" instead of "const char [N]", and furthermore=20
make strlen() a constexpr function? Those changes seem long overdue. If the=
=20
Standard did that in 2017, would this proposal become obsolete, or would=20
there still be some reason make_sv_literal() ought to exist?

(B) Why not use a user-defined literal suffix, so that e.g. "abc"s is a=20
std::string and "abc"sv is a std::string_view? Then the syntax for your=20
last example would be

static constexpr std::array<std::string_view> kColorStr =3D { "Red"sv, "Gre=
en"sv, "Blue"sv };

Then the syntax for "wide" string literals (literals of type=20
basic_string_view<char32_t>) would be U"Red"sv. Which looks dopey, but=20
then, everything to do with wide characters in C++ looks dopey.

Is there a technical reason (B) couldn't work in C++14 as a library-only=20
extension (e.g., something to do with the lifetime of the parameter or the=
=20
result)? How much would the language side of things have to change in order=
=20
to get it to work?

my $.02,
=E2=80=93Arthur

--=20

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

------=_Part_2581_2139751164.1423507816382
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, February 6, 2015 at 9:17:50 PM UTC-8, Matthew F=
ioravante 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"lt=
r">I wrote up a draft of a proposal for 2 utilities for making constexpr st=
ring_view string literals and constexpr array&lt;string_view,N&gt; arrays o=
f string literals.<div><br></div><div><a href=3D"https://github.com/fmatthe=
w5876/stdcxx-sv-literal/blob/master/proposal/draft.md" target=3D"_blank" re=
l=3D"nofollow" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75h=
ttps%3A%2F%2Fgithub.com%2Ffmatthew5876%2Fstdcxx-sv-literal%2Fblob%2Fmaster%=
2Fproposal%2Fdraft.md\46sa\75D\46sntz\0751\46usg\75AFQjCNHiwk_kXOpaJEvwxvNm=
TotGudWRdQ';return true;" onclick=3D"this.href=3D'https://www.google.com/ur=
l?q\75https%3A%2F%2Fgithub.com%2Ffmatthew5876%2Fstdcxx-sv-literal%2Fblob%2F=
master%2Fproposal%2Fdraft.md\46sa\75D\46sntz\0751\46usg\75AFQjCNHiwk_kXOpaJ=
EvwxvNmTotGudWRdQ';return true;">https://github.com/<wbr>fmatthew5876/stdcx=
x-sv-<wbr>literal/blob/master/proposal/<wbr>draft.md</a><br></div><div><br>=
</div><div>I'm using these tools and I find them very useful. Do you agree =
that these would be very useful to have? If not, how would you define strin=
g literals in modern C++?</div></div></blockquote><div><br></div><div>I hav=
e two questions after reading your proposal, which I think you should addre=
ss =E2=80=94 presumably to rebut them =E2=80=94 because otherwise it seems =
like you're ignoring them.</div><div><br></div><div>(A) Why not change the =
definition of string literals in C++1z to be "constexpr const char [N]" ins=
tead of "const char [N]", and furthermore make strlen() a constexpr functio=
n? Those changes seem long overdue. If the Standard did that in 2017, would=
 this proposal become obsolete, or would there still be some reason make_sv=
_literal() ought to exist?</div><div><br></div><div>(B) Why not use a user-=
defined literal suffix, so that e.g. <font face=3D"courier new, monospace">=
"abc"s</font> is a <font face=3D"courier new, monospace">std::string</font>=
 and <font face=3D"courier new, monospace">"abc"sv</font> is a <font face=
=3D"courier new, monospace">std::string_view</font>? Then the syntax for yo=
ur last example would be</div><div><br></div><div><pre style=3D"box-sizing:=
 border-box; overflow: auto; font-family: Consolas, 'Liberation Mono', Menl=
o, Courier, monospace; font-size: 14px; margin-bottom: 16px; line-height: 1=
..45; padding: 16px; background-color: rgb(247, 247, 247); border-top-left-r=
adius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; =
border-bottom-left-radius: 3px; word-wrap: normal; color: rgb(51, 51, 51);"=
><code style=3D"box-sizing: border-box; font-family: Consolas, 'Liberation =
Mono', Menlo, Courier, monospace; background-color: transparent; border-top=
-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius=
: 3px; border-bottom-left-radius: 3px; word-break: normal; display: inline;=
 line-height: inherit; word-wrap: normal;">static constexpr std::array&lt;s=
td::string_view&gt; kColorStr =3D { "Red"sv, "Green"sv, "Blue"sv };</code><=
/pre>Then the syntax for "wide" string literals (literals of type <font fac=
e=3D"courier new, monospace">basic_string_view&lt;char32_t&gt;</font>) woul=
d be <font face=3D"courier new, monospace">U"Red"sv</font>. Which looks dop=
ey, but then, everything to do with wide characters in C++ looks dopey.</di=
v><div><br></div><div>Is there a technical reason (B) couldn't work in C++1=
4 as a library-only extension (e.g., something to do with the lifetime of t=
he parameter or the result)? How much would the language side of things hav=
e to change in order to get it to work?</div><div><br></div><div>my $.02,</=
div><div>=E2=80=93Arthur</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_2581_2139751164.1423507816382--
------=_Part_2580_220408256.1423507816382--

.

------=_Part_929_1529777177.1423515617152
Content-Type: multipart/alternative;
 boundary="----=_Part_930_1290791955.1423515617152"

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



On Monday, February 9, 2015 at 1:50:16 PM UTC-5, Arthur O'Dwyer wrote:
>
> On Friday, February 6, 2015 at 9:17:50 PM UTC-8, Matthew Fioravante wrote=
:
>>
>> I wrote up a draft of a proposal for 2 utilities for making constexpr=20
>> string_view string literals and constexpr array<string_view,N> arrays of=
=20
>> string literals.
>>
>>
>> https://github.com/fmatthew5876/stdcxx-sv-literal/blob/master/proposal/d=
raft.md
>>
>> I'm using these tools and I find them very useful. Do you agree that=20
>> these would be very useful to have? If not, how would you define string=
=20
>> literals in modern C++?
>>
>
> I have two questions after reading your proposal, which I think you shoul=
d=20
> address =E2=80=94 presumably to rebut them =E2=80=94 because otherwise it=
 seems like you're=20
> ignoring them.
>
> (A) Why not change the definition of string literals in C++1z to be=20
> "constexpr const char [N]" instead of "const char [N]",=20
>

How would that help? String literals can already be processed at compile=20
time.
=20

> and furthermore make strlen() a constexpr function?=20
>

constexpr is not the only problem. strlen() assumes null terminated=20
semantics. The following example will not work as expected.

string_view s =3D "ABC\0DEF";


Most implementations of strlen() cannot be constexpr because they usually=
=20
are heavily optimized with inline assembly and/or simd intrinsics. A true=
=20
constexpr strlen() would probably require either constexpr overloading or=
=20
implementation specific magic to allow strlen() to be constexpr despite=20
implementations using platform specific optimization techniques.

=20

> Those changes seem long overdue. If the Standard did that in 2017, would=
=20
> this proposal become obsolete, or would there still be some reason=20
> make_sv_literal() ought to exist
>

We need to support strings with embedded nulls. I had mentioned this issue=
=20
several times in the first draft but removed it because of the previous=20
poster's feedback.

=20

>
> (B) Why not use a user-defined literal suffix
>

I addressed the limitations of user defined literals and why they cannot be=
=20
used in the paper in the Issues section.

>
> static constexpr std::array<std::string_view> kColorStr =3D { "Red"sv, "G=
reen"sv, "Blue"sv };
>
> You forgot the size parameter to std::array in this example. Unless some=
=20
new template magic is invented, we need a variadic function to initialize=
=20
the array and automatically determine the size.=20

--=20

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

------=_Part_930_1290791955.1423515617152
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, February 9, 2015 at 1:50:16 PM UTC-5, A=
rthur O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Friday, February 6, 2015 at 9:17:50 PM UTC-8, Matthew Fioravant=
e wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I wrote up=
 a draft of a proposal for 2 utilities for making constexpr string_view str=
ing literals and constexpr array&lt;string_view,N&gt; arrays of string lite=
rals.<div><br></div><div><a href=3D"https://github.com/fmatthew5876/stdcxx-=
sv-literal/blob/master/proposal/draft.md" rel=3D"nofollow" target=3D"_blank=
" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2F=
github.com%2Ffmatthew5876%2Fstdcxx-sv-literal%2Fblob%2Fmaster%2Fproposal%2F=
draft.md\46sa\75D\46sntz\0751\46usg\75AFQjCNHiwk_kXOpaJEvwxvNmTotGudWRdQ';r=
eturn true;" onclick=3D"this.href=3D'https://www.google.com/url?q\75https%3=
A%2F%2Fgithub.com%2Ffmatthew5876%2Fstdcxx-sv-literal%2Fblob%2Fmaster%2Fprop=
osal%2Fdraft.md\46sa\75D\46sntz\0751\46usg\75AFQjCNHiwk_kXOpaJEvwxvNmTotGud=
WRdQ';return true;">https://github.com/<wbr>fmatthew5876/stdcxx-sv-<wbr>lit=
eral/blob/master/proposal/<wbr>draft.md</a><br></div><div><br></div><div>I'=
m using these tools and I find them very useful. Do you agree that these wo=
uld be very useful to have? If not, how would you define string literals in=
 modern C++?</div></div></blockquote><div><br></div><div>I have two questio=
ns after reading your proposal, which I think you should address =E2=80=94 =
presumably to rebut them =E2=80=94 because otherwise it seems like you're i=
gnoring them.</div><div><br></div><div>(A) Why not change the definition of=
 string literals in C++1z to be "constexpr const char [N]" instead of "cons=
t char [N]", </div></div></blockquote><div><br>How would that help? String =
literals can already be processed at compile time.<br>&nbsp;</div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>and furthermore m=
ake strlen() a constexpr function? </div></div></blockquote><div><br>conste=
xpr is not the only problem. strlen() assumes null terminated semantics. Th=
e following example will not work as expected.<br><br><div class=3D"prettyp=
rint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187,=
 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"=
><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">string_view s </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;=
" class=3D"styled-by-prettify">"ABC\0DEF"</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br><br>Most implemen=
tations of strlen() cannot be constexpr because they usually are heavily op=
timized with inline assembly and/or simd intrinsics. A true constexpr strle=
n() would probably require either constexpr overloading or implementation s=
pecific magic to allow strlen() to be constexpr despite implementations usi=
ng platform specific optimization techniques.<br><br>&nbsp;</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Those changes seem=
 long overdue. If the Standard did that in 2017, would this proposal become=
 obsolete, or would there still be some reason make_sv_literal() ought to e=
xist</div></div></blockquote><div><br>We need to support strings with embed=
ded nulls. I had mentioned this issue several times in the first draft but =
removed it because of the previous poster's feedback.<br></div><div><br>&nb=
sp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
><br></div><div>(B) Why not use a user-defined literal suffix<br></div></di=
v></blockquote><div><br>I addressed the limitations of user defined literal=
s and why they cannot be used in the paper in the Issues section.<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><d=
iv><br></div><div><pre style=3D"overflow:auto;font-family:Consolas,'Liberat=
ion Mono',Menlo,Courier,monospace;font-size:14px;margin-bottom:16px;line-he=
ight:1.45;padding:16px;background-color:rgb(247,247,247);border-top-left-ra=
dius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-=
bottom-left-radius:3px;word-wrap:normal;color:rgb(51,51,51)"><code style=3D=
"font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;background-=
color:transparent;border-top-left-radius:3px;border-top-right-radius:3px;bo=
rder-bottom-right-radius:3px;border-bottom-left-radius:3px;word-break:norma=
l;display:inline;line-height:inherit;word-wrap:normal">static constexpr std=
::array&lt;std::string_view&gt; kColorStr =3D { "Red"sv, "Green"sv, "Blue"s=
v };</code></pre></div></div></blockquote><div>You forgot the size paramete=
r to std::array in this example. Unless some new template magic is invented=
, we need a variadic function to initialize the array and automatically det=
ermine the size. <br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_930_1290791955.1423515617152--
------=_Part_929_1529777177.1423515617152--

.

On Mon, Feb 9, 2015 at 4:00 PM, Matthew Fioravante
<fmatthew5876@gmail.com> wrote:
> constexpr is not the only problem. strlen() assumes null terminated
> semantics. The following example will not work as expected.
>
> string_view s = "ABC\0DEF";
>

That's why we are going to write "ABC\0DEF"sv

>> (B) Why not use a user-defined literal suffix
>
>
> I addressed the limitations of user defined literals and why they cannot be
> used in the paper in the Issues section.
>>

"Unfortunately, since enabling user defined literals
 requires using declarations, it is not usable for header
 files where global constants are most often defined. "

You might want to use this argument to defend a
proposal making changes to user defined literals or
namespace, but not for yet-another-way to create
string_view literals.

>>
>> static constexpr std::array<std::string_view> kColorStr = { "Red"sv,
>> "Green"sv, "Blue"sv };
>
> You forgot the size parameter to std::array in this example. Unless some new
> template magic is invented, we need a variadic function to initialize the
> array and automatically determine the size.
>

  auto ss = make_array("seems"sv, "to work"sv);

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4315.html

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

--

---
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_738_756631384.1423519921055
Content-Type: multipart/alternative;
 boundary="----=_Part_739_1452997001.1423519921056"

------=_Part_739_1452997001.1423519921056
Content-Type: text/plain; charset=UTF-8



On Monday, February 9, 2015 at 4:24:23 PM UTC-5, Zhihao Yuan wrote:
>
>
> "Unfortunately, since enabling user defined literals
>  requires using declarations, it is not usable for header
>  files where global constants are most often defined. "
>
> You might want to use this argument to defend a
> proposal making changes to user defined literals or
> namespace, but not for yet-another-way to create
> string_view literals.
>

I'm not sure I understand your rebuttal here. If I want to use an sv
literal I need a using declaration.

using std::literals;

constexpr auto color_str = std::make_array("red"sv, "green"sv, "blue"sv);

 Adding "using std::literals" to a header file is not going to fly for even
the most relaxed coding standards.

Or am I misunderstanding something?

--

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

<div dir=3D"ltr"><br><br>On Monday, February 9, 2015 at 4:24:23 PM UTC-5, Z=
hihao Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>"Unfortun=
ately, since enabling user defined literals
<br>&nbsp;requires using declarations, it is not usable for header
<br>&nbsp;files where global constants are most often defined. "
<br>
<br>You might want to use this argument to defend a
<br>proposal making changes to user defined literals or
<br>namespace, but not for yet-another-way to create
<br>string_view literals.
<br></blockquote><div><br>I'm not sure I understand your rebuttal here. If =
I want to use an sv literal I need a using declaration.<br><br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">using</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">literals</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">constexpr</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> color_str </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">make_array<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #080;" class=3D"styled-by-prettify">"red"</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">sv</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=
=3D"styled-by-prettify">"green"</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">sv</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">"blue=
"</span><span style=3D"color: #000;" class=3D"styled-by-prettify">sv</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code><=
/div><br>&nbsp;Adding "using std::literals" to a header file is not going t=
o fly for even the most relaxed coding standards.<br><br>Or am I misunderst=
anding something?<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_739_1452997001.1423519921056--
------=_Part_738_756631384.1423519921055--

.

On Mon, Feb 9, 2015 at 5:12 PM, Matthew Fioravante
<fmatthew5876@gmail.com> wrote:
>
> using std::literals;
>
> constexpr auto color_str = std::make_array("red"sv, "green"sv, "blue"sv);
>
>  Adding "using std::literals" to a header file is not going to fly for even
> the most relaxed coding standards.
>

I know this is a problem, but it's not a problem caused
by operator""sv; it's a problem cause by missing UDL
feature or missing namespace related feature.  Adding
make_sv_literal does not solve the problem using `3min`
(chrono UDL) or any other UDL in header file.

For now, an workaround that I can think of would be:

  namespace detail
  {
     constexpr auto a = ...;
     constexpr auto b = ... "some"sv, ...;
  }

  using detail::a;
  using detail::b;

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

--

---
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_4164_128499153.1423521543183
Content-Type: multipart/alternative;
 boundary="----=_Part_4165_1464199236.1423521543183"

------=_Part_4165_1464199236.1423521543183
Content-Type: text/plain; charset=UTF-8



On Monday, February 9, 2015 at 5:24:59 PM UTC-5, Zhihao Yuan wrote:
>
>
>
> I know this is a problem, but it's not a problem caused
> by operator""sv; it's a problem cause by missing UDL
> feature or missing namespace related feature.  Adding
> make_sv_literal does not solve the problem using `3min`
> (chrono UDL) or any other UDL in header file.
>
> For now, an workaround that I can think of would be:
>
>   namespace detail
>   {
>      constexpr auto a = ...;
>      constexpr auto b = ... "some"sv, ...;
>   }
>
>   using detail::a;
>   using detail::b;
>
>

Sorry, I get what you're saying now. Being unable to use literals in a
header file really kind of defeats the purpose of having them at all.

You might be right but that's opening an huge can of worms and I don't know
of a good solution to the problem. Your example workaround above is
horribly verbose and requires repeating every variable twice. it also
doesn't work if you want to make the objects static variables of a class.

A few solutions I can think of

1) local using statements

inline using std::literals;

The meaning here would be only use this namespace within the current file.
The big problem with this approach is that now the preprocessor needs to
parse this syntax.  Requiring this kind of cross talk between the
preprocessor and compiler is probably a very bad idea.

2) scoped using statements

This:

{
using std::literals;
constexpr auto name = "name"sv;
} //using std::literals no longer in effect after this line

Or maybe this:
using std::literals {
constexpr auto name = "name"sv;
}

3) Just make the standard user defined literals always available on the
global namespace after you #include <string_view> etc..

This might not be so terrible since non-standard literals are required to
use a leading underscore.

If no solution is ever accepted for this, then going back to my proposal,
we could just have 1 function name which is short.

constexpr auto color_name = std::sv("color");
constexpr auto color_str = std::make_array(std::sv("red"), std::sv("green"),
std::sv("blue"));


--

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

<div dir=3D"ltr"><br><br>On Monday, February 9, 2015 at 5:24:59 PM UTC-5, Z=
hihao Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>
<br>I know this is a problem, but it's not a problem caused
<br>by operator""sv; it's a problem cause by missing UDL
<br>feature or missing namespace related feature. &nbsp;Adding
<br>make_sv_literal does not solve the problem using `3min`
<br>(chrono UDL) or any other UDL in header file.
<br>
<br>For now, an workaround that I can think of would be:
<br>
<br>&nbsp; namespace detail
<br>&nbsp; {
<br>&nbsp; &nbsp; &nbsp;constexpr auto a =3D ...;
<br>&nbsp; &nbsp; &nbsp;constexpr auto b =3D ... "some"sv, ...;
<br>&nbsp; }
<br>
<br>&nbsp; using detail::a;
<br>&nbsp; using detail::b;
<br>
<br></blockquote><div><br><br>Sorry, I get what you're saying now. Being un=
able to use literals in a header file really kind of defeats the purpose of=
 having them at all.<br><br>You might be right but that's=20
opening an huge can of worms and I don't know of a good solution to the=20
problem. Your example workaround above is horribly verbose and requires rep=
eating every variable twice. it also doesn't work if you want to make the o=
bjects static variables of a class.<br><br>A few solutions I can think of<b=
r><br>1) local using statements<br><br><div class=3D"prettyprint" style=3D"=
background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bor=
der-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">inline</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">using</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">lite=
rals</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></di=
v></code></div><br>The
 meaning here would be only use this namespace within the current file.=20
The big problem with this approach is that now the preprocessor needs to
 parse this syntax.&nbsp; Requiring this kind of cross talk between the=20
preprocessor and compiler is probably a very bad idea.<br><br>2) scoped usi=
ng statements<br><br>This:<br><br><div class=3D"prettyprint" style=3D"backg=
round-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-s=
tyle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pret=
typrint"><div class=3D"subprettyprint"><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">using</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">literals</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> name </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-b=
y-prettify">"name"</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">sv</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #800;" class=3D"styled-by-prettify">//using std::literals no longer i=
n effect after this line</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br></span></div></code></div><br>Or maybe this:<br><div clas=
s=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-col=
or: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: =
break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">using</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">literals </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">constexpr</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> name </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #080;" class=3D"styled-by-prettify">"name"</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">sv</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br>3) Just make the =
standard user defined literals always available on the global namespace aft=
er you #include &lt;string_view&gt; etc..<br><br>This might not be=20
so terrible since non-standard literals are required to use a leading=20
underscore. <br><br>If no solution is ever accepted for this, then going ba=
ck to my proposal, we could just have 1 function name which is short.<br><b=
r><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250);=
 border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; =
word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpretty=
print"><span style=3D"color: #008;" class=3D"styled-by-prettify">constexpr<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> color_name </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">sv</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #080;" class=3D"style=
d-by-prettify">"color"</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">co=
nstexpr</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> color_str </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">make_array</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">sv</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #080;" class=3D"styled-by-prettify">"=
red"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">),</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">sv</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #080;"=
 class=3D"styled-by-prettify">"green"</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">),</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">sv</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #080;" class=3D"styled-by-prettify">"blue"</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">));</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code=
></div><br><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_4165_1464199236.1423521543183--
------=_Part_4164_128499153.1423521543183--

.

On 10 February 2015 at 00:39, Matthew Fioravante <fmatthew5876@gmail.com> wrote:
> A few solutions I can think of
>
> 1) local using statements
>
> inline using std::literals;
>
> The meaning here would be only use this namespace within the current file.
> The big problem with this approach is that now the preprocessor needs to
> parse this syntax.  Requiring this kind of cross talk between the
> preprocessor and compiler is probably a very bad idea.
>
> 2) scoped using statements
>
> This:
>
> {
> using std::literals;
> constexpr auto name = "name"sv;
> } //using std::literals no longer in effect after this line
>
> Or maybe this:
> using std::literals {
> constexpr auto name = "name"sv;
> }
>
> 3) Just make the standard user defined literals always available on the
> global namespace after you #include <string_view> etc..

Lambdas, the solution to EVERY problem: :)

auto x = [](){using namespace std::literals; return 3if;}();

--

---
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 Mon, Feb 9, 2015 at 5:39 PM, Matthew Fioravante
<fmatthew5876@gmail.com> wrote:
> Your example workaround above is horribly
> verbose and requires repeating every variable twice. it also doesn't work if
> you want to make the objects static variables of a class.
>

  class A
  {
    static constexpr auto a = detail::a;
  };

  ...or

  using detail::YouClass;

Just saying.

> constexpr auto color_name = std::sv("color");
> constexpr auto color_str = std::make_array(std::sv("red"), std::sv("green"),
> std::sv("blue"));
>

By proposing so is like saying "UDL doesn't work in header file, so
let's forget about it and keep using ctors, like std::chrono::minutes(3).
Oh BTW string_view does not have the right constructor, let's fix it. "

I... don't know how to respond to this...

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

--

---
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_4176_359922290.1423523379283
Content-Type: multipart/alternative;
 boundary="----=_Part_4177_1899978078.1423523379283"

------=_Part_4177_1899978078.1423523379283
Content-Type: text/plain; charset=UTF-8



On Monday, February 9, 2015 at 6:00:59 PM UTC-5, Ville Voutilainen wrote:
>
>
> Lambdas, the solution to EVERY problem: :)
>
> auto x = [](){using namespace std::literals; return 3if;}();
>

I really really hope this is a joke. Why on earth would anyone write all of
that?

Isn't the point of user defined literals to be terse and easy to write?

If the solution is to be to use a lambda, I'd rather just write the type
directly and forget the whole useless user defined literal feature to begin
with.

auto x = std::complex<float>(0, 3);

The above is much clearer and readable than your lambda mess.


--

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

<div dir=3D"ltr"><br><br>On Monday, February 9, 2015 at 6:00:59 PM UTC-5, V=
ille Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>Lam=
bdas, the solution to EVERY problem: :)
<br>
<br>auto x =3D [](){using namespace std::literals; return 3if;}();
<br></blockquote><div><br>I really really hope this is a joke. Why on earth=
 would anyone write all of that?<br><br>Isn't the point of user defined lit=
erals to be terse and easy to write?<br><br>If the solution is to be to use=
 a lambda, I'd rather just write the type directly and forget the whole use=
less user defined literal feature to begin with.<br><br><div class=3D"prett=
yprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(18=
7, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word=
;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D=
"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> x </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">complex</span><span style=3D"color: #080;" class=3D"styled-by-pre=
ttify">&lt;float&gt;</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #066;" class=3D"styled-by-prettify"=
>0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #066;" class=3D"styled-by-prettify">3</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span></div></code></div><br>The above=
 is much clearer and readable than your lambda mess.<br><br><br></div></div=
>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_4177_1899978078.1423523379283--
------=_Part_4176_359922290.1423523379283--

.

------=_Part_4270_107812468.1423523700245
Content-Type: multipart/alternative;
 boundary="----=_Part_4271_1675435255.1423523700245"

------=_Part_4271_1675435255.1423523700245
Content-Type: text/plain; charset=UTF-8



On Monday, February 9, 2015 at 6:09:18 PM UTC-5, Zhihao Yuan wrote:
>
>
> > constexpr auto color_name = std::sv("color");
> > constexpr auto color_str = std::make_array(std::sv("red"),
> std::sv("green"),
> > std::sv("blue"));
> >
>
> By proposing so is like saying "UDL doesn't work in header file, so
> let's forget about it and keep using ctors, like std::chrono::minutes(3).
> Oh BTW string_view does not have the right constructor, let's fix it. "
>
> I... don't know how to respond to this...
>

If the UDL in header file problem is not solved then UDL's become pretty
useless and going back to ctor's / make functions is the only approach that
would work.  I'm really surprised the UDL header problem was never
considered when UDL's were originally designed for C++11, or was it?

--

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

<div dir=3D"ltr"><br><br>On Monday, February 9, 2015 at 6:09:18 PM UTC-5, Z=
hihao Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>&gt; cons=
texpr auto color_name =3D std::sv("color");
<br>&gt; constexpr auto color_str =3D std::make_array(std::sv("red")<wbr>, =
std::sv("green"),
<br>&gt; std::sv("blue"));
<br>&gt;
<br>
<br>By proposing so is like saying "UDL doesn't work in header file, so
<br>let's forget about it and keep using ctors, like std::chrono::minutes(3=
).
<br>Oh BTW string_view does not have the right constructor, let's fix it. "
<br>
<br>I... don't know how to respond to this...
<br></blockquote><div><br>If the UDL in header file problem is not solved t=
hen UDL's become pretty useless and going back to ctor's / make functions i=
s the only approach that would work.&nbsp; I'm really surprised the UDL hea=
der problem was never considered when UDL's were originally designed for C+=
+11, or was it?<br><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_4271_1675435255.1423523700245--
------=_Part_4270_107812468.1423523700245--

.

------=_Part_14_390591299.1423590718517
Content-Type: multipart/alternative;
 boundary="----=_Part_15_1957937061.1423590718517"

------=_Part_15_1957937061.1423590718517
Content-Type: text/plain; charset=UTF-8



On Monday, February 9, 2015 at 6:15:00 PM UTC-5, Matthew Fioravante wrote:
>
>
>
> On Monday, February 9, 2015 at 6:09:18 PM UTC-5, Zhihao Yuan wrote:
>>
>>
>> > constexpr auto color_name = std::sv("color");
>> > constexpr auto color_str = std::make_array(std::sv("red"),
>> std::sv("green"),
>> > std::sv("blue"));
>> >
>>
>> By proposing so is like saying "UDL doesn't work in header file, so
>> let's forget about it and keep using ctors, like std::chrono::minutes(3).
>> Oh BTW string_view does not have the right constructor, let's fix it. "
>>
>> I... don't know how to respond to this...
>>
>
> If the UDL in header file problem is not solved then UDL's become pretty
> useless and going back to ctor's / make functions is the only approach that
> would work.  I'm really surprised the UDL header problem was never
> considered when UDL's were originally designed for C++11, or was it?
>
>
To be fair to the standards committee, the problem is not immediately
apparent from the specification. If you think in terms of your personal
user-space, the problem is a non-issue.

The reason you don't want to put things like "using std::literals" in
headers is because you don't want to pollute other people's stuff with your
literal. For your personal code, in your personal user-space, the using
declaration isn't a problem.

Furthermore, there were no UDLs in the standard library. So nobody really
knew how they were going to be used. Nobody assumed they would be in
namespaces at all. Also, before C++11 was standardized, nobody actually
implemented UDLs, so nobody really played with the feature.

However, to the committee's *discredit*, there was a national body comment
prior to standardization that pointed out the lack of practical experience
with UDLs. And the comment was effectively ignored.

That being said, module support *should* be able to resolve the UDL problem
a priori, since module inclusion allows each module to decide what gets
exported explicitly. So you don't have to pollute someone's global space if
you don't want to.

--

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

<div dir=3D"ltr"><br><br>On Monday, February 9, 2015 at 6:15:00 PM UTC-5, M=
atthew Fioravante wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><br><br>On Monday, February 9, 2015 at 6:09:18 PM UTC-5, Zhihao =
Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>&gt; constexpr auto =
color_name =3D std::sv("color");
<br>&gt; constexpr auto color_str =3D std::make_array(std::sv("red")<wbr>, =
std::sv("green"),
<br>&gt; std::sv("blue"));
<br>&gt;
<br>
<br>By proposing so is like saying "UDL doesn't work in header file, so
<br>let's forget about it and keep using ctors, like std::chrono::minutes(3=
).
<br>Oh BTW string_view does not have the right constructor, let's fix it. "
<br>
<br>I... don't know how to respond to this...
<br></blockquote><div><br>If the UDL in header file problem is not solved t=
hen UDL's become pretty useless and going back to ctor's / make functions i=
s the only approach that would work.&nbsp; I'm really surprised the UDL hea=
der problem was never considered when UDL's were originally designed for C+=
+11, or was it?<br><br></div></div></blockquote><div><br>To be fair to the =
standards committee, the problem is not immediately apparent from the speci=
fication. If you think in terms of your personal user-space, the problem is=
 a non-issue.<br><br>The reason you don't want to put things like "using st=
d::literals" in headers is because you don't want to pollute other people's=
 stuff with your literal. For your personal code, in your personal user-spa=
ce, the using declaration isn't a problem.<br><br>Furthermore, there were n=
o UDLs in the standard library. So nobody really knew how they were going t=
o be used. Nobody assumed they would be in namespaces at all. Also, before =
C++11 was standardized, nobody actually implemented UDLs, so nobody really =
played with the feature.<br><br>However, to the committee's <i>discredit</i=
>, there was a national body comment prior to standardization that pointed =
out the lack of practical experience with UDLs. And the comment was effecti=
vely ignored.<br><br>That being said, module support <i>should</i> be able =
to resolve the UDL problem a priori, since module inclusion allows each mod=
ule to decide what gets exported explicitly. So you don't have to pollute s=
omeone's global space if you don't want to.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_15_1957937061.1423590718517--
------=_Part_14_390591299.1423590718517--

.

On 10 February 2015 at 19:51, Nicol Bolas <jmckesson@gmail.com> wrote:
> The reason you don't want to put things like "using std::literals" in
> headers is because you don't want to pollute other people's stuff with your
> literal. For your personal code, in your personal user-space, the using
> declaration isn't a problem.

In other words, this works just fine:

namespace my_constants
{
    using namespace std::literals;
    auto COMPLEX_HALF = 0.5if;
}

Somehow this makes me doubt whether UDLs as a language feature are "completely
useless", or that the library literals would be.

--

---
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_425_392957686.1423595491423
Content-Type: multipart/alternative;
 boundary="----=_Part_426_927614077.1423595491423"

------=_Part_426_927614077.1423595491423
Content-Type: text/plain; charset=UTF-8


On Tuesday, February 10, 2015 at 1:01:29 PM UTC-5, Ville Voutilainen wrote:
>
> On 10 February 2015 at 19:51, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> > The reason you don't want to put things like "using std::literals" in
> > headers is because you don't want to pollute other people's stuff with
> your
> > literal. For your personal code, in your personal user-space, the using
> > declaration isn't a problem.
>
> In other words, this works just fine:
>
> namespace my_constants
> {
>     using namespace std::literals;
>     auto COMPLEX_HALF = 0.5if;
> }
>

I agree with you. This seems reasonable.

There might still be a use for a make function which takes a reference to
an array of characters (or even better an array_view of characters) and
initializes the view to point to the entire array regardless of its
contents. It would have to be a free function, not a constructor because
that would conflict with with the const char* constructor.

For instance here you can't use a literal

const char name[] = "name";
auto name_sv = std::sv_from_array(name);


--

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

<div dir=3D"ltr"><br>On Tuesday, February 10, 2015 at 1:01:29 PM UTC-5, Vil=
le Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 10 Feb=
ruary 2015 at 19:51, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"bopTbwtFvX8J" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:=
';return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; The reason you don't want to put things like "using std::literals"=
 in
<br>&gt; headers is because you don't want to pollute other people's stuff =
with your
<br>&gt; literal. For your personal code, in your personal user-space, the =
using
<br>&gt; declaration isn't a problem.
<br>
<br>In other words, this works just fine:
<br>
<br>namespace my_constants
<br>{
<br>&nbsp; &nbsp; using namespace std::literals;
<br>&nbsp; &nbsp; auto COMPLEX_HALF =3D 0.5if;
<br>}
<br></blockquote><div><br>I agree with you. This seems reasonable.<br><br>T=
here might still be a use for a make function which takes a reference to an=
 array of characters (or even better an array_view of characters) and initi=
alizes the view to point to the entire array regardless of its contents. It=
 would have to be a free function, not a constructor because that would con=
flict with with the const char* constructor.<br><br>For instance here you c=
an't use a literal<br><br><div class=3D"prettyprint" style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"=
><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled=
-by-prettify">const</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
char</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> name<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">[]</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;=
" class=3D"styled-by-prettify">"name"</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> name_sv </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s=
td</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">sv_from_array</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">name</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br><b=
r></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_426_927614077.1423595491423--
------=_Part_425_392957686.1423595491423--

.

Unless the ctor has a dummy parameter.

On 2/10/15, Matthew Fioravante <fmatthew5876@gmail.com> wrote:
>
> On Tuesday, February 10, 2015 at 1:01:29 PM UTC-5, Ville Voutilainen wrote:
>>
>> On 10 February 2015 at 19:51, Nicol Bolas <jmck...@gmail.com
>> <javascript:>>
>> wrote:
>> > The reason you don't want to put things like "using std::literals" in
>> > headers is because you don't want to pollute other people's stuff with
>> your
>> > literal. For your personal code, in your personal user-space, the using
>> >
>> > declaration isn't a problem.
>>
>> In other words, this works just fine:
>>
>> namespace my_constants
>> {
>>     using namespace std::literals;
>>     auto COMPLEX_HALF = 0.5if;
>> }
>>
>
> I agree with you. This seems reasonable.
>
> There might still be a use for a make function which takes a reference to
> an array of characters (or even better an array_view of characters) and
> initializes the view to point to the entire array regardless of its
> contents. It would have to be a free function, not a constructor because
> that would conflict with with the const char* constructor.
>
> For instance here you can't use a literal
>
> const char name[] = "name";
> auto name_sv = std::sv_from_array(name);
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_644_682481003.1423670998381
Content-Type: multipart/alternative;
 boundary="----=_Part_645_748058794.1423670998381"

------=_Part_645_748058794.1423670998381
Content-Type: text/plain; charset=UTF-8

On Tuesday, February 10, 2015 at 1:01:29 PM UTC-5, Ville Voutilainen wrote:
>
> On 10 February 2015 at 19:51, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> > The reason you don't want to put things like "using std::literals" in
> > headers is because you don't want to pollute other people's stuff with
> your
> > literal. For your personal code, in your personal user-space, the using
> > declaration isn't a problem.
>
> In other words, this works just fine:
>
> namespace my_constants
> {
>     using namespace std::literals;
>     auto COMPLEX_HALF = 0.5if;
> }
>
> Somehow this makes me doubt whether UDLs as a language feature are
> "completely
> useless", or that the library literals would be.
>

.... You're kidding, right?

So if I have this in a header:

class Foo
{
private:
  auto someValue = std::literals::func_to_compute_literal(0.5);
};

The UDL-based solution to having to call that function is:

namespace i_hope_nobody_uses_this
{
  using namespace std::literals;
  auto initialValue = 0.5if;
}

class Foo
{
private:
  auto someValue = i_hope_nobody_uses_this::initialValue;
};

I was under the impression that UDLs were supposed to make your code
cleaner, more readable, and more compact. This does none of these. You just
can't look at "Foo" and know what's going on without chasing down
"initialValue". At least in the initial case, I can see what the value
started as (0.5); here, that information is completely hidden. Not only
that, I've introduced a new variable and a new namespace name, neither of
which is necessary to do the job.

Explain to me how this is *not* a obviously hack to work around a stupid
language deficiency.

While "completely useless" may be hyperbole, your attempt to convince me
that UDLs don't have a major usability flaw has thus far failed.

--

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

<div dir=3D"ltr">On Tuesday, February 10, 2015 at 1:01:29 PM UTC-5, Ville V=
outilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 10 Februar=
y 2015 at 19:51, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"bopTbwtFvX8J" rel=3D"nofollow" onmousedown=3D"this=
..href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; The reason you don't want to put things like "using std::literals"=
 in
<br>&gt; headers is because you don't want to pollute other people's stuff =
with your
<br>&gt; literal. For your personal code, in your personal user-space, the =
using
<br>&gt; declaration isn't a problem.
<br>
<br>In other words, this works just fine:
<br>
<br>namespace my_constants
<br>{
<br>&nbsp; &nbsp; using namespace std::literals;
<br>&nbsp; &nbsp; auto COMPLEX_HALF =3D 0.5if;
<br>}
<br>
<br>Somehow this makes me doubt whether UDLs as a language feature are "com=
pletely
<br>useless", or that the library literals would be.<br></blockquote><div><=
br>... You're kidding, right?<br><br>So if I have this in a header:<br><br>=
class Foo<br>{<br>private:<br>&nbsp; auto someValue =3D std::literals::func=
_to_compute_literal(0.5);<br>};<br><br>The UDL-based solution to having to =
call that function is:<br><br>namespace i_hope_nobody_uses_this<br>{<br>&nb=
sp; using namespace std::literals;
<br>&nbsp; auto initialValue =3D 0.5if;
<br>}<br><br>class Foo<br>{<br>private:<br>&nbsp; auto someValue =3D i_hope=
_nobody_uses_this::initialValue;<br>};<br><br>I was under the impression th=
at UDLs were supposed to make your code cleaner, more readable, and more co=
mpact. This does none of these. You just can't look at "Foo" and know what'=
s going on without chasing down "initialValue". At least in the initial cas=
e, I can see what the value started as (0.5); here, that information is com=
pletely hidden. Not only that, I've introduced a new variable and a new nam=
espace name, neither of which is necessary to do the job.<br><br>Explain to=
 me how this is <i>not</i> a obviously hack to work around a stupid languag=
e deficiency.<br><br>While "completely useless" may be hyperbole, your atte=
mpt to convince me that UDLs don't have a major usability flaw has thus far=
 failed.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_645_748058794.1423670998381--
------=_Part_644_682481003.1423670998381--

.

--047d7bb70b0ca77054050ed2b2b6
Content-Type: text/plain; charset=UTF-8

On 11 February 2015 at 10:09, Nicol Bolas <jmckesson@gmail.com> wrote:

> While "completely useless" may be hyperbole, your attempt to convince me
> that UDLs don't have a major usability flaw has thus far failed.


The problem is more general.  We've never addressed the problem of trying
to use a namespace in a class declaration in a header.

For example, look at <
http://www.boost.org/doc/libs/1_57_0/libs/multi_index/doc/tutorial/basics.html
>:

typedef multi_index_container<
  employee,
  indexed_by<
    ordered_unique<identity<employee> >,
    ordered_non_unique<member<employee,std::string,&employee::name> >
  > > employee_set;


Now, let's say I want to declare employee_set inside a class in a header,
and I want to follow the good practice of not putting using declarations
unscoped in a header.  Here is what I really have to write:

typedef *boost::*multi_index_container<
  employee,
  *boost::multi_index::*indexed_by<
    *boost::multi_index::*ordered_unique<*boost::multi_index::*identity<employee>
>,
    *boost::multi_index::*ordered_non_unique<*boost::multi_index::*member<employee,std::string,&employee::name>
>
  >
> employee_set;


Very noisy and not terribly useable...
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

--047d7bb70b0ca77054050ed2b2b6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On 11 February 2015 at 10:09, N=
icol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" tar=
get=3D"_blank">jmckesson@gmail.com</a>&gt;</span> wrote:<br><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">While &quot;c=
ompletely useless&quot; may be hyperbole, your attempt to convince me that =
UDLs don&#39;t have a major usability flaw has thus far failed.</blockquote=
></div><br></div><div class=3D"gmail_extra">The problem is more general.=C2=
=A0 We&#39;ve never addressed the problem of trying to use a namespace in a=
 class declaration in a header.<br><br></div><div class=3D"gmail_extra">For=
 example, look at &lt;<a href=3D"http://www.boost.org/doc/libs/1_57_0/libs/=
multi_index/doc/tutorial/basics.html" target=3D"_blank">http://www.boost.or=
g/doc/libs/1_57_0/libs/multi_index/doc/tutorial/basics.html</a>&gt;:<br><br=
><pre><font size=3D"1"><span>typedef</span> <span>multi_index_container</sp=
an><span>&lt;</span>
  <span>employee</span><span>,</span>
  <span>indexed_by</span><span>&lt;</span>
    <span>ordered_unique</span><span>&lt;</span><span>identity</span><span>=
&lt;</span><span>employee</span><span>&gt;</span> <span>&gt;,</span>
    <span>ordered_non_unique</span><span>&lt;</span><span>member</span><spa=
n>&lt;</span><span>employee</span><span>,</span><span>std</span><span>::</s=
pan><span>string</span><span>,&amp;</span><span>employee</span><span>::</sp=
an><span>name</span><span>&gt;</span> <span>&gt;</span>
  <span>&gt;</span>=20
<span>&gt;</span> <span>employee_set</span><span>;</span></font></pre><br><=
/div><div class=3D"gmail_extra">Now, let&#39;s say I want to declare employ=
ee_set inside a class in a header, and I want to follow the good practice o=
f not putting using declarations unscoped in a header.=C2=A0 Here is what I=
 really have to write:<br><br><font size=3D"1"><span style=3D"font-family:m=
onospace,monospace">typedef <i><b>boost::</b></i>multi_index_container&lt;<=
br>=C2=A0 employee,<br>=C2=A0 <i><b>boost::multi_index::</b></i>indexed_by&=
lt;<br>=C2=A0=C2=A0=C2=A0 <i><b>boost::multi_index::</b></i>ordered_unique&=
lt;<i><b>boost::multi_index::</b></i>identity&lt;employee&gt; &gt;,<br>=C2=
=A0=C2=A0=C2=A0 <i><b>boost::multi_index::</b></i>ordered_non_unique&lt;<i>=
<b>boost::multi_index::</b></i>member&lt;employee,std::string,&amp;employee=
::name&gt; &gt;<br>=C2=A0 &gt;<br>&gt; employee_set;</span></font><br><br><=
br></div><div class=3D"gmail_extra">Very noisy and not terribly useable...<=
br></div><div class=3D"gmail_extra">-- <br><div>=C2=A0Nevin &quot;:-)&quot;=
 Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D=
"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 <a href=3D"tel:%28847%29%2069=
1-1404" value=3D"+18476911404" target=3D"_blank">(847) 691-1404</a></div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />

--047d7bb70b0ca77054050ed2b2b6--

.

------=_Part_288_50892458.1423673061804
Content-Type: multipart/alternative;
 boundary="----=_Part_289_651050100.1423673061804"

------=_Part_289_651050100.1423673061804
Content-Type: text/plain; charset=UTF-8



On Wednesday, February 11, 2015 at 11:09:58 AM UTC-5, Nicol Bolas wrote:
>
> On Tuesday, February 10, 2015 at 1:01:29 PM UTC-5, Ville Voutilainen wrote:
>>
>> On 10 February 2015 at 19:51, Nicol Bolas <jmck...@gmail.com> wrote:
>> > The reason you don't want to put things like "using std::literals" in
>> > headers is because you don't want to pollute other people's stuff with
>> your
>> > literal. For your personal code, in your personal user-space, the using
>> > declaration isn't a problem.
>>
>> In other words, this works just fine:
>>
>> namespace my_constants
>> {
>>     using namespace std::literals;
>>     auto COMPLEX_HALF = 0.5if;
>> }
>>
>> Somehow this makes me doubt whether UDLs as a language feature are
>> "completely
>> useless", or that the library literals would be.
>>
>
> ... You're kidding, right?
>
> So if I have this in a header:
>
> class Foo
> {
> private:
>   auto someValue = std::literals::func_to_compute_literal(0.5);
> };
>
> The UDL-based solution to having to call that function is:
>
> namespace i_hope_nobody_uses_this
> {
>   using namespace std::literals;
>   auto initialValue = 0.5if;
> }
>
> class Foo
> {
> private:
>   auto someValue = i_hope_nobody_uses_this::initialValue;
> };
>

I think the solution is to just add using namespace std::literals to your
library namespace.

namespace mylib {
  using namespace std::literals;

  constexpr auto c = 3if;

  class MyType {
    static constexpr auto d = 4if;
  };
};

Designing a library, I would of course never have using namespace std;
within my library namespace but adding using namespace std::literals; seems
ok to me. No decent C++ library is going to be publicly defining stuff in
the global namespace anyway so the lack of usability for UDL within the
global namespace problem may not actually be a problem at all.

I would not put my constants in their own separate namespace like this just
to avoid std::literals polution within the library namespace. That approach
defeats the whole purpose of UDL's being a readability and clean code
feature.

namespace mylib {
  namespace my_constants {
    using namespace std::literals;
    constexpr auto c = 3if;
  }
  constexpr auto c = my_constants::c; //my eyes are burning right now..
}




>
> I was under the impression that UDLs were supposed to make your code
> cleaner, more readable, and more compact. This does none of these. You just
> can't look at "Foo" and know what's going on without chasing down
> "initialValue". At least in the initial case, I can see what the value
> started as (0.5); here, that information is completely hidden. Not only
> that, I've introduced a new variable and a new namespace name, neither of
> which is necessary to do the job.
>
> Explain to me how this is *not* a obviously hack to work around a stupid
> language deficiency.
>
> While "completely useless" may be hyperbole, your attempt to convince me
> that UDLs don't have a major usability flaw has thus far failed.
>

What I find interesting is the lack of people talking about UDL on the
internet. Either the feature is just obvious and uninteresting, or nobody
is using it yet . If I didn't run into this issue with string_view, I still
wouldn't be giving any thought to UDL.

--

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

<div dir=3D"ltr"><br><br>On Wednesday, February 11, 2015 at 11:09:58 AM UTC=
-5, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Tuesday, February 10, 2015 at 1:01:29 PM UTC-5, Ville Voutilain=
en wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex">On 10 February 2015 at 19:=
51, Nicol Bolas &lt;<a rel=3D"nofollow">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; The reason you don't want to put things like "using std::literals"=
 in
<br>&gt; headers is because you don't want to pollute other people's stuff =
with your
<br>&gt; literal. For your personal code, in your personal user-space, the =
using
<br>&gt; declaration isn't a problem.
<br>
<br>In other words, this works just fine:
<br>
<br>namespace my_constants
<br>{
<br>&nbsp; &nbsp; using namespace std::literals;
<br>&nbsp; &nbsp; auto COMPLEX_HALF =3D 0.5if;
<br>}
<br>
<br>Somehow this makes me doubt whether UDLs as a language feature are "com=
pletely
<br>useless", or that the library literals would be.<br></blockquote><div><=
br>... You're kidding, right?<br><br>So if I have this in a header:<br><br>=
class Foo<br>{<br>private:<br>&nbsp; auto someValue =3D std::literals::func=
_to_<wbr>compute_literal(0.5);<br>};<br><br>The UDL-based solution to havin=
g to call that function is:<br><br>namespace i_hope_nobody_uses_this<br>{<b=
r>&nbsp; using namespace std::literals;
<br>&nbsp; auto initialValue =3D 0.5if;
<br>}<br><br>class Foo<br>{<br>private:<br>&nbsp; auto someValue =3D i_hope=
_nobody_uses_this::<wbr>initialValue;<br>};<br></div></div></blockquote><di=
v><br>I think the solution is to just add using namespace std::literals to =
your library namespace. <br><br><div class=3D"prettyprint" style=3D"backgro=
und-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-sty=
le: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pretty=
print"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"=
styled-by-prettify">namespace</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> mylib </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">using</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">namesp=
ace</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">literals</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>&nbsp; <br>&nbsp; </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> c </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"st=
yled-by-prettify">3if</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">MyType<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">static</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">constexpr</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> d </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettif=
y">4if</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">};</span></div></code></di=
v><br>Designing a library, I would of course never have using namespace std=
; within my library namespace but adding using namespace std::literals; see=
ms ok to me. No decent C++ library is going to be publicly defining stuff i=
n the global namespace anyway so the lack of usability for UDL within the g=
lobal namespace problem may not actually be a problem at all.<br><br>I woul=
d not put my constants in their own separate namespace like this just to av=
oid std::literals polution within the library namespace. That approach defe=
ats the whole purpose of UDL's being a readability and clean code feature.<=
br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, =
250); border-color: rgb(187, 187, 187); border-style: solid; border-width: =
1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">names=
pace</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> mylib=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">namespace</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> my_constants </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">using</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">namespace</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">literals</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">constexpr</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> c </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">3if</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> c </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> my_constants</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify">c</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #800;" class=3D"styled-by-prettify">//my eyes are =
burning right now..</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span></div></code></div><br><br>&nbsp;</div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div><br>I was under the impression that UDL=
s were supposed to make your code cleaner, more readable, and more compact.=
 This does none of these. You just can't look at "Foo" and know what's goin=
g on without chasing down "initialValue". At least in the initial case, I c=
an see what the value started as (0.5); here, that information is completel=
y hidden. Not only that, I've introduced a new variable and a new namespace=
 name, neither of which is necessary to do the job.<br><br>Explain to me ho=
w this is <i>not</i> a obviously hack to work around a stupid language defi=
ciency.<br><br>While "completely useless" may be hyperbole, your attempt to=
 convince me that UDLs don't have a major usability flaw has thus far faile=
d.<br></div></div></blockquote><div><br>What I find interesting is the lack=
 of people talking about UDL on the internet. Either the feature is just ob=
vious and uninteresting, or nobody is using it yet . If I didn't run into t=
his issue with string_view, I still wouldn't be giving any thought to UDL.<=
br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_289_651050100.1423673061804--
------=_Part_288_50892458.1423673061804--

.

------=_Part_769_306181714.1423673844689
Content-Type: multipart/alternative;
 boundary="----=_Part_770_625248986.1423673844689"

------=_Part_770_625248986.1423673844689
Content-Type: text/plain; charset=UTF-8



On Wednesday, February 11, 2015 at 11:43:09 AM UTC-5, Nevin ":-)" Liber
wrote:
>
> On 11 February 2015 at 10:09, Nicol Bolas <jmck...@gmail.com <javascript:>
> > wrote:
>
>> While "completely useless" may be hyperbole, your attempt to convince me
>> that UDLs don't have a major usability flaw has thus far failed.
>
>
> The problem is more general.  We've never addressed the problem of trying
> to use a namespace in a class declaration in a header.
>
> For example, look at <
> http://www.boost.org/doc/libs/1_57_0/libs/multi_index/doc/tutorial/basics.html
> >:
>
> typedef multi_index_container<
>   employee,
>   indexed_by<
>     ordered_unique<identity<employee> >,
>     ordered_non_unique<member<employee,std::string,&employee::name> >
>   > > employee_set;
>
>
> Now, let's say I want to declare employee_set inside a class in a header,
> and I want to follow the good practice of not putting using declarations
> unscoped in a header.  Here is what I really have to write:
>
> typedef *boost::*multi_index_container<
>   employee,
>   *boost::multi_index::*indexed_by<
>     *boost::multi_index::*ordered_unique<*boost::multi_index::*identity<employee>
> >,
>     *boost::multi_index::*ordered_non_unique<*boost::multi_index::*member<employee,std::string,&employee::name>
> >
>   >
> > employee_set;
>
>
> Very noisy and not terribly useable...
> --
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>  (847)
> 691-1404
>

I think the solution to this general problem may be allowing for scoped
using statements. Specifically some syntax allowing you to define a new
scope using curly braces where within the scope you can add using
declarations which disappear when the scope is exited.

using namespace {
using namespace boost::multi_index;
//your example
}
//no longer using namespace boost::multi_index


Or modules, if people think that they can solve this problem. I'm a bit
skeptical when someone comes along and says a problem is a non-problem
because we just have to wait for these magic modules.

--

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

<div dir=3D"ltr"><br><br>On Wednesday, February 11, 2015 at 11:43:09 AM UTC=
-5, Nevin ":-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><div>On 11 February 2015 at 10:09, Nicol Bolas <span dir=3D"=
ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"OUcg4BxE7kkJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';re=
turn true;" onclick=3D"this.href=3D'javascript:';return true;">jmck...@gmai=
l.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">While "completely useless" may be hyperbol=
e, your attempt to convince me that UDLs don't have a major usability flaw =
has thus far failed.</blockquote></div><br></div><div>The problem is more g=
eneral.&nbsp; We've never addressed the problem of trying to use a namespac=
e in a class declaration in a header.<br><br></div><div>For example, look a=
t &lt;<a href=3D"http://www.boost.org/doc/libs/1_57_0/libs/multi_index/doc/=
tutorial/basics.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.boost.org%2Fdoc%2F=
libs%2F1_57_0%2Flibs%2Fmulti_index%2Fdoc%2Ftutorial%2Fbasics.html\46sa\75D\=
46sntz\0751\46usg\75AFQjCNE3XSpFJsSpYpZvlWjjCUEIPcmQfA';return true;" oncli=
ck=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.boost.org=
%2Fdoc%2Flibs%2F1_57_0%2Flibs%2Fmulti_index%2Fdoc%2Ftutorial%2Fbasics.html\=
46sa\75D\46sntz\0751\46usg\75AFQjCNE3XSpFJsSpYpZvlWjjCUEIPcmQfA';return tru=
e;">http://www.boost.org/doc/<wbr>libs/1_57_0/libs/multi_index/<wbr>doc/tut=
orial/basics.html</a>&gt;:<br><br><pre><font size=3D"1"><span>typedef</span=
> <span>multi_index_container</span><span>&lt;</span>
  <span>employee</span><span>,</span>
  <span>indexed_by</span><span>&lt;</span>
    <span>ordered_unique</span><span>&lt;</span><span>identity</span><span>=
&lt;</span><span>employ<wbr>ee</span><span>&gt;</span> <span>&gt;,</span>
    <span>ordered_non_unique</span><span>&lt;</span><span>member</span><spa=
n>&lt;</span><span>empl<wbr>oyee</span><span>,</span><span>std</span><span>=
::</span><span>string</span><span>,&amp;</span><span>employee</span><span>:=
:</span><span>na<wbr>me</span><span>&gt;</span> <span>&gt;</span>
  <span>&gt;</span>=20
<span>&gt;</span> <span>employee_set</span><span>;</span></font></pre><br><=
/div><div>Now, let's say I want to declare employee_set inside a class in a=
 header, and I want to follow the good practice of not putting using declar=
ations unscoped in a header.&nbsp; Here is what I really have to write:<br>=
<br><font size=3D"1"><span style=3D"font-family:monospace,monospace">typede=
f <i><b>boost::</b></i>multi_index_container&lt;<br>&nbsp; employee,<br>&nb=
sp; <i><b>boost::multi_index::</b></i>indexed_<wbr>by&lt;<br>&nbsp;&nbsp;&n=
bsp; <i><b>boost::multi_index::</b></i>ordered_<wbr>unique&lt;<i><b>boost::=
multi_index::</b></i>ide<wbr>ntity&lt;employee&gt; &gt;,<br>&nbsp;&nbsp;&nb=
sp; <i><b>boost::multi_index::</b></i>ordered_<wbr>non_unique&lt;<i><b>boos=
t::multi_index:<wbr>:</b></i>member&lt;employee,std::string,&amp;<wbr>emplo=
yee::name&gt; &gt;<br>&nbsp; &gt;<br>&gt; employee_set;</span></font><br><b=
r><br></div><div>Very noisy and not terribly useable...<br></div><div>-- <b=
r><div>&nbsp;Nevin ":-)" Liber&nbsp; &lt;mailto:<a href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"OUcg4BxE7kkJ" rel=3D"nofollow" onmo=
usedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
javascript:';return true;">ne...@eviloverlord.com</a><wbr>&gt;&nbsp; <a val=
ue=3D"+18476911404">(847) 691-1404</a></div></div></div></blockquote><div><=
br>I think the solution to this general problem may be allowing for scoped =
using statements. Specifically some syntax allowing you to define a new sco=
pe using curly braces where within the scope you can add using declarations=
 which disappear when the scope is exited.<br><br><div class=3D"prettyprint=
" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187=
, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color=
: #008;" class=3D"styled-by-prettify">using</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">namespace</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
using</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">namespace</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> boost</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">multi_index</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #8=
00;" class=3D"styled-by-prettify">//your example</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" class=3D"st=
yled-by-prettify">//no longer using namespace boost::multi_index</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></co=
de></div><br><br>Or modules, if people think that they can solve this probl=
em. I'm a bit skeptical when someone comes along and says a problem is a no=
n-problem because we just have to wait for these magic modules.<br><br></di=
v></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_770_625248986.1423673844689--
------=_Part_769_306181714.1423673844689--

.

--Apple-Mail=_088587E4-10CB-484D-B74F-8C652F109F3E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9302=E2=80=9312, at 12:44 AM, Matthew Fioravante <fmatthew5=
876@gmail.com> wrote:
>=20
> I think the solution is to just add using namespace std::literals to your=
 library namespace.=20
>=20
> namespace mylib {
>   using namespace std::literals;

If you do that, then using namespace mylib; will pull std::literals too. Th=
e workaround is a bit more complicated:

namespace mylib_impl {
    using namespace std::literals;

    namespace interface {
        static constexpr blah =3D 0.i;
    }
}
namespace mylib =3D mylib_impl::interface;

Putting implementation details in an outer namespace rather a nested one co=
uld be a good idea, but I=E2=80=99ve never tried it. You wouldn=E2=80=99t h=
ave to say detail:: everywhere.

--=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=_088587E4-10CB-484D-B74F-8C652F109F3E
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=9302=
=E2=80=9312, at 12:44 AM, Matthew Fioravante &lt;<a href=3D"mailto:fmatthew=
5876@gmail.com" class=3D"">fmatthew5876@gmail.com</a>&gt; wrote:</div><br c=
lass=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; 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"">I think the solution is to just add using namespac=
e std::literals to your library namespace.&nbsp;<br class=3D""><div class=
=3D""><br class=3D""><div class=3D"prettyprint" style=3D"background-color: =
rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-=
word;"><code class=3D"prettyprint"><span class=3D"styled-by-prettify" style=
=3D"color: rgb(0, 0, 136);">namespace</span><span class=3D"styled-by-pretti=
fy" style=3D""><span class=3D"Apple-converted-space">&nbsp;</span>mylib<spa=
n class=3D"Apple-converted-space">&nbsp;</span></span><span class=3D"styled=
-by-prettify" style=3D"color: rgb(102, 102, 0);">{</span><br class=3D"">&nb=
sp;<span class=3D"Apple-converted-space">&nbsp;</span><span class=3D"styled=
-by-prettify" style=3D"color: rgb(0, 0, 136);">using</span>&nbsp;<span clas=
s=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);">namespace</span><=
span class=3D"Apple-converted-space">&nbsp;</span>std<span class=3D"styled-=
by-prettify" style=3D"color: rgb(102, 102, 0);">::</span>literals<span clas=
s=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">;</span><br cla=
ss=3D""></code></div></div></div></div></blockquote><div><br class=3D""></d=
iv><div>If you do that, then <font face=3D"Courier" class=3D"">using namesp=
ace mylib;</font> will pull <font face=3D"Courier" class=3D"">std::literals=
</font> too. The workaround is a bit more complicated:</div><div><br class=
=3D""></div><div><font face=3D"Courier" class=3D"">namespace mylib_impl {</=
font></div><div><font face=3D"Courier" class=3D"">&nbsp; &nbsp; using names=
pace std::literals;</font></div><div><font face=3D"Courier" class=3D""><br =
class=3D""></font></div><div><font face=3D"Courier" class=3D"">&nbsp; &nbsp=
; namespace interface {</font></div><div><font face=3D"Courier" class=3D"">=
&nbsp; &nbsp; &nbsp; &nbsp; static constexpr blah =3D 0.i;</font></div><div=
><font face=3D"Courier" class=3D"">&nbsp; &nbsp; }</font></div><div><font f=
ace=3D"Courier" class=3D"">}</font></div><div><font face=3D"Courier" class=
=3D"">namespace mylib =3D mylib_impl::interface;</font></div></div><br clas=
s=3D""><div class=3D"">Putting implementation details in an outer namespace=
 rather a nested one could be a good idea, but I=E2=80=99ve never tried it.=
 You wouldn=E2=80=99t have to say <font face=3D"Courier" class=3D"">detail:=
:</font> everywhere.</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=_088587E4-10CB-484D-B74F-8C652F109F3E--

.

On 2015-02-10 14:11, Matthew Fioravante wrote:
> There might still be a use for a make function which takes a reference to
> an array of characters (or even better an array_view of characters) and
> initializes the view to point to the entire array regardless of its
> contents. It would have to be a free function, not a constructor because
> that would conflict with with the const char* constructor.
>
> For instance here you can't use a literal
>
> const char name[] = "name";
> auto name_sv = std::sv_from_array(name);

    template <size_t k> sv_from_array(char const (&data)[k]);

....now sv_from_array knows the size of the array being passed. (Of
course this means you can only call it with an array of known size, but
that would seem to be the point...) Works with class constructors also.

....or do I miss something?

--
Matthew

--

---
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_138_2098593172.1423684616929
Content-Type: multipart/alternative;
 boundary="----=_Part_139_784023476.1423684616929"

------=_Part_139_784023476.1423684616929
Content-Type: text/plain; charset=UTF-8



On Wednesday, February 11, 2015 at 11:43:09 AM UTC-5, Nevin ":-)" Liber
wrote:
>
> On 11 February 2015 at 10:09, Nicol Bolas <jmck...@gmail.com <javascript:>
> > wrote:
>
>> While "completely useless" may be hyperbole, your attempt to convince me
>> that UDLs don't have a major usability flaw has thus far failed.
>
>
> The problem is more general.  We've never addressed the problem of trying
> to use a namespace in a class declaration in a header.
>
> For example, look at <
> http://www.boost.org/doc/libs/1_57_0/libs/multi_index/doc/tutorial/basics.html
> >:
>
> typedef multi_index_container<
>   employee,
>   indexed_by<
>     ordered_unique<identity<employee> >,
>     ordered_non_unique<member<employee,std::string,&employee::name> >
>   > > employee_set;
>
>
> Now, let's say I want to declare employee_set inside a class in a header,
> and I want to follow the good practice of not putting using declarations
> unscoped in a header.  Here is what I really have to write:
>
> typedef *boost::*multi_index_container<
>   employee,
>   *boost::multi_index::*indexed_by<
>     *boost::multi_index::*ordered_unique<*boost::multi_index::*identity<employee>
> >,
>     *boost::multi_index::*ordered_non_unique<*boost::multi_index::*member<employee,std::string,&employee::name>
> >
>   >
> > employee_set;
>
>
> Very noisy and not terribly useable...
>

I agree that the problem is much more general than UDLs. However, UDLs have
a unique issue with it, because you simply *cannot* use them with
namespaces. So while the above code may be verbose and ugly, it still works.

There's no equivalent for UDLs besides "using namespace". So UDLs are
either not available or pollute the translation unit's namespace.

--

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

<div dir=3D"ltr"><br><br>On Wednesday, February 11, 2015 at 11:43:09 AM UTC=
-5, Nevin ":-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><div>On 11 February 2015 at 10:09, Nicol Bolas <span dir=3D"=
ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"OUcg4BxE7kkJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';re=
turn true;" onclick=3D"this.href=3D'javascript:';return true;">jmck...@gmai=
l.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">While "completely useless" may be hyperbol=
e, your attempt to convince me that UDLs don't have a major usability flaw =
has thus far failed.</blockquote></div><br></div><div>The problem is more g=
eneral.&nbsp; We've never addressed the problem of trying to use a namespac=
e in a class declaration in a header.<br><br></div><div>For example, look a=
t &lt;<a href=3D"http://www.boost.org/doc/libs/1_57_0/libs/multi_index/doc/=
tutorial/basics.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.boost.org%2Fdoc%2F=
libs%2F1_57_0%2Flibs%2Fmulti_index%2Fdoc%2Ftutorial%2Fbasics.html\46sa\75D\=
46sntz\0751\46usg\75AFQjCNE3XSpFJsSpYpZvlWjjCUEIPcmQfA';return true;" oncli=
ck=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.boost.org=
%2Fdoc%2Flibs%2F1_57_0%2Flibs%2Fmulti_index%2Fdoc%2Ftutorial%2Fbasics.html\=
46sa\75D\46sntz\0751\46usg\75AFQjCNE3XSpFJsSpYpZvlWjjCUEIPcmQfA';return tru=
e;">http://www.boost.org/doc/<wbr>libs/1_57_0/libs/multi_index/<wbr>doc/tut=
orial/basics.html</a>&gt;:<br><br><pre><font size=3D"1"><span>typedef</span=
> <span>multi_index_container</span><span>&lt;</span>
  <span>employee</span><span>,</span>
  <span>indexed_by</span><span>&lt;</span>
    <span>ordered_unique</span><span>&lt;</span><span>identity</span><span>=
&lt;</span><span>employ<wbr>ee</span><span>&gt;</span> <span>&gt;,</span>
    <span>ordered_non_unique</span><span>&lt;</span><span>member</span><spa=
n>&lt;</span><span>empl<wbr>oyee</span><span>,</span><span>std</span><span>=
::</span><span>string</span><span>,&amp;</span><span>employee</span><span>:=
:</span><span>na<wbr>me</span><span>&gt;</span> <span>&gt;</span>
  <span>&gt;</span>=20
<span>&gt;</span> <span>employee_set</span><span>;</span></font></pre><br><=
/div><div>Now, let's say I want to declare employee_set inside a class in a=
 header, and I want to follow the good practice of not putting using declar=
ations unscoped in a header.&nbsp; Here is what I really have to write:<br>=
<br><font size=3D"1"><span style=3D"font-family:monospace,monospace">typede=
f <i><b>boost::</b></i>multi_index_container&lt;<br>&nbsp; employee,<br>&nb=
sp; <i><b>boost::multi_index::</b></i>indexed_<wbr>by&lt;<br>&nbsp;&nbsp;&n=
bsp; <i><b>boost::multi_index::</b></i>ordered_<wbr>unique&lt;<i><b>boost::=
multi_index::</b></i>ide<wbr>ntity&lt;employee&gt; &gt;,<br>&nbsp;&nbsp;&nb=
sp; <i><b>boost::multi_index::</b></i>ordered_<wbr>non_unique&lt;<i><b>boos=
t::multi_index:<wbr>:</b></i>member&lt;employee,std::string,&amp;<wbr>emplo=
yee::name&gt; &gt;<br>&nbsp; &gt;<br>&gt; employee_set;</span></font><br><b=
r><br></div><div>Very noisy and not terribly useable...<br></div></div></bl=
ockquote><div><br></div>I agree that the problem is much more general than =
UDLs. However, UDLs have a unique issue with it, because you simply <i>cann=
ot</i> use them with namespaces. So while the above code may be verbose and=
 ugly, it still works.<br><br>There's no equivalent for UDLs besides "using=
 namespace". So UDLs are either not available or pollute the translation un=
it's namespace.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_139_784023476.1423684616929--
------=_Part_138_2098593172.1423684616929--

.

------=_Part_983_1329613449.1423684759713
Content-Type: multipart/alternative;
 boundary="----=_Part_984_98406661.1423684759713"

------=_Part_984_98406661.1423684759713
Content-Type: text/plain; charset=UTF-8



On Wednesday, February 11, 2015 at 2:52:20 PM UTC-5, Matthew Woehlke wrote:
>
> On 2015-02-10 14:11, Matthew Fioravante wrote:
> > There might still be a use for a make function which takes a reference
> to
> > an array of characters (or even better an array_view of characters) and
> > initializes the view to point to the entire array regardless of its
> > contents. It would have to be a free function, not a constructor because
> > that would conflict with with the const char* constructor.
> >
> > For instance here you can't use a literal
> >
> > const char name[] = "name";
> > auto name_sv = std::sv_from_array(name);
>
>     template <size_t k> sv_from_array(char const (&data)[k]);
>

This is the intended signature for my hypothetical sv_from_array().


>
> ...now sv_from_array knows the size of the array being passed. (Of
> course this means you can only call it with an array of known size, but
> that would seem to be the point...) Works with class constructors also.
>
> ...or do I miss something?
>
> --
> Matthew
>

What i meant is that in my example is that to initialize a string_view to
point to the C array name I cannot use a user defined literal.  I need a
constructor or a free function which calls string_view(name,
sizeof(name)/sizeof(*name)-1) semantics. Hence adding something like
sv_from_array() still has value even if all of the problems with UDL are
solved.

--

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

<div dir=3D"ltr"><br><br>On Wednesday, February 11, 2015 at 2:52:20 PM UTC-=
5, Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 20=
15-02-10 14:11, Matthew Fioravante wrote:
<br>&gt; There might still be a use for a make function which takes a refer=
ence to=20
<br>&gt; an array of characters (or even better an array_view of characters=
) and=20
<br>&gt; initializes the view to point to the entire array regardless of it=
s=20
<br>&gt; contents. It would have to be a free function, not a constructor b=
ecause=20
<br>&gt; that would conflict with with the const char* constructor.
<br>&gt;=20
<br>&gt; For instance here you can't use a literal
<br>&gt;=20
<br>&gt; const char name[] =3D "name";
<br>&gt; auto name_sv =3D std::sv_from_array(name);
<br>
<br>&nbsp; &nbsp; template &lt;size_t k&gt; sv_from_array(char const (&amp;=
data)[k]);
<br></blockquote><div><br>This is the intended signature for my hypothetica=
l sv_from_array().<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
<br>...now sv_from_array knows the size of the array being passed. (Of
<br>course this means you can only call it with an array of known size, but
<br>that would seem to be the point...) Works with class constructors also.
<br>
<br>...or do I miss something?
<br>
<br>--=20
<br>Matthew
<br></blockquote><div><br>What i meant is that in my example is that to ini=
tialize a string_view to point to the C array name I cannot use a user defi=
ned literal.&nbsp; I need a constructor or a free function which calls stri=
ng_view(name, sizeof(name)/sizeof(*name)-1) semantics. Hence adding somethi=
ng like sv_from_array() still has value even if all of the problems with UD=
L are solved.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_984_98406661.1423684759713--
------=_Part_983_1329613449.1423684759713--

.