On Wed, Nov 16, 2016 at 9:04 AM, Vittorio Romeo
<vittorio.romeo.vee@gmail.com> wrote:
> Currently string literals are not allowed as template arguments because the
> standard explicitly prevents that (see 14.3.2 Template non-type arguments).

At the end of the Issaquah C++ standards meeting last week some of us
worked toward another approach to arrays as value-kind template
parameters (Louis Dione, Jeff Snyder, James Touton, myself, and
others), specifically because of wanting to easily pass compile-time
strings. It's a harder problem than it seems and implementors voiced
concern regarding representation as a pack of char even though the
desired semantics are similar. I'm not sure, but Louis Dionne might
already be starting on a new paper in this area. There are a few of us
who really want something like this.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEm_8ngPVZyMAP4GU8nbvgiD2XxBrLT0M1Pk94m8%2BtQrug%40mail.gmail.com.

.

------=_Part_4794_1970617621.1479360505913
Content-Type: multipart/alternative;
 boundary="----=_Part_4795_1525416045.1479360505914"

------=_Part_4795_1525416045.1479360505914
Content-Type: text/plain; charset=UTF-8

Let me just expand a bit on what Matt said.

I think this is a brilliant idea, but I don't think it's going to work, for
the same reason
as my P0424R0 paper was not warmly received. The reason is that implementers
don't want anything that encourages the use of large template parameter
lists,
because the representation of that inside the compiler is too inefficient.
They don't
want a single template parameter per character in the string, because the
structure
that represents a template parameter in the compiler is expensive. Instead,
they'd
rather have a single structure that represents all the characters. I'm not
sure why they
can't just represent a character pack in a more efficient manner, but
that's what I
was told when I presented in EWG.

So on Saturday, we tried looking into passing arrays as template arguments,
but
that becomes messy because arrays are already supported, but they decay to
pointers so we'd need to support a new syntax. We then tried passing
std::array,
but doing this cleanly would require passing arbitrary literal types as
template
arguments, which is also non-trivial of a change.

I have not started writing a paper yet, because I don't have any solution
in mind
at this time to be honest. However, this is one of the most valuable
problems to
be solved for metaprogramming, so I'll take anything that works.

Louis


On Wednesday, 16 November 2016 15:18:23 UTC+1, Matt Calabrese wrote:
>
> On Wed, Nov 16, 2016 at 9:04 AM, Vittorio Romeo
> <vittorio....@gmail.com <javascript:>> wrote:
> > Currently string literals are not allowed as template arguments because
> the
> > standard explicitly prevents that (see 14.3.2 Template non-type
> arguments).
>
> At the end of the Issaquah C++ standards meeting last week some of us
> worked toward another approach to arrays as value-kind template
> parameters (Louis Dione, Jeff Snyder, James Touton, myself, and
> others), specifically because of wanting to easily pass compile-time
> strings. It's a harder problem than it seems and implementors voiced
> concern regarding representation as a pack of char even though the
> desired semantics are similar. I'm not sure, but Louis Dionne might
> already be starting on a new paper in this area. There are a few of us
> who really want something like this.
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d9433fac-152f-4515-b518-985a78768c03%40isocpp.org.

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

<div dir=3D"ltr"><div>Let me just expand a bit on what Matt said.</div><div=
><br></div><div>I think this is a brilliant idea, but I don&#39;t think it&=
#39;s going to work, for the same reason</div><div>as my P0424R0 paper was =
not warmly received. The reason is that implementers</div><div>don&#39;t wa=
nt anything that encourages the use of large template parameter lists,</div=
><div>because the representation of that inside the compiler is too ineffic=
ient. They don&#39;t</div><div>want a single template parameter per charact=
er in the string, because the structure</div><div>that represents a templat=
e parameter in the compiler is expensive. Instead, they&#39;d</div><div>rat=
her have a single structure that represents all the characters. I&#39;m not=
 sure why they</div><div>can&#39;t just represent a character pack in a mor=
e efficient manner, but that&#39;s what I</div><div>was told when I present=
ed in EWG.</div><div><br></div><div>So on Saturday, we tried looking into p=
assing arrays as template arguments, but</div><div>that becomes messy becau=
se arrays are already supported, but they decay to</div><div>pointers so we=
&#39;d need to support a new syntax. We then tried passing std::array,</div=
><div>but doing this cleanly would require passing arbitrary literal types =
as template</div><div>arguments, which is also non-trivial of a change.</di=
v><div><br></div><div>I have not started writing a paper yet, because I don=
&#39;t have any solution in mind</div><div>at this time to be honest. Howev=
er, this is one of the most valuable problems to</div><div>be solved for me=
taprogramming, so I&#39;ll take anything that works.</div><div><br></div><d=
iv>Louis</div><div><br></div><br>On Wednesday, 16 November 2016 15:18:23 UT=
C+1, Matt Calabrese  wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On =
Wed, Nov 16, 2016 at 9:04 AM, Vittorio Romeo
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
8yZA3nkyAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">vittorio....@gmail.com</a>&gt; wrote:
<br>&gt; Currently string literals are not allowed as template arguments be=
cause the
<br>&gt; standard explicitly prevents that (see 14.3.2 Template non-type ar=
guments).
<br>
<br>At the end of the Issaquah C++ standards meeting last week some of us
<br>worked toward another approach to arrays as value-kind template
<br>parameters (Louis Dione, Jeff Snyder, James Touton, myself, and
<br>others), specifically because of wanting to easily pass compile-time
<br>strings. It&#39;s a harder problem than it seems and implementors voice=
d
<br>concern regarding representation as a pack of char even though the
<br>desired semantics are similar. I&#39;m not sure, but Louis Dionne might
<br>already be starting on a new paper in this area. There are a few of us
<br>who really want something like this.
<br></blockquote></div>

<p></p>

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

------=_Part_4795_1525416045.1479360505914--

------=_Part_4794_1970617621.1479360505913--

.

------=_Part_5380_1809884440.1479366622806
Content-Type: multipart/alternative;
 boundary="----=_Part_5381_930922786.1479366622806"

------=_Part_5381_930922786.1479366622806
Content-Type: text/plain; charset=UTF-8

On Thursday, November 17, 2016 at 1:28:26 PM UTC+8, Louis Dionne wrote:
>
> Let me just expand a bit on what Matt said.
>
> I think this is a brilliant idea, but I don't think it's going to work,
> for the same reason
> as my P0424R0 paper was not warmly received. The reason is that
> implementers
> don't want anything that encourages the use of large template parameter
> lists,
> because the representation of that inside the compiler is too inefficient.
> They don't
> want a single template parameter per character in the string, because the
> structure
> that represents a template parameter in the compiler is expensive.
> Instead, they'd
> rather have a single structure that represents all the characters. I'm not
> sure why they
> can't just represent a character pack in a more efficient manner, but
> that's what I
> was told when I presented in EWG.
>
> So on Saturday, we tried looking into passing arrays as template
> arguments, but
> that becomes messy because arrays are already supported, but they decay to
> pointers so we'd need to support a new syntax. We then tried passing
> std::array,
> but doing this cleanly would require passing arbitrary literal types as
> template
> arguments, which is also non-trivial of a change.
>
> I have not started writing a paper yet, because I don't have any solution
> in mind
> at this time to be honest. However, this is one of the most valuable
> problems to
> be solved for metaprogramming, so I'll take anything that works.
>

What about automatically generating types for string-literals?
Probably with a built-in literal operator 'lit' that does the compiler
magic.

The generated type of a string-literal is guaranteed to be the same across
TUs.
Such a type should provide some constexpr methods/typedefs to access its
intrinsic (e.g. size(), operator[], char_type, etc).

For example:
constexpr auto str = "Hello"lit;
static_assert(is_same<decltype(str), decltype("Hello"lit)>::value);
static_assert(is_same<decltype(str)::char_type, char>::value);
static_assert(s[0] == 'H');

Has idea like this been discussed?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6b73bf50-4189-4d5d-a2c0-2debb085659e%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, November 17, 2016 at 1:28:26 PM UTC+8, Louis =
Dionne 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">=
<div>Let me just expand a bit on what Matt said.</div><div><br></div><div>I=
 think this is a brilliant idea, but I don&#39;t think it&#39;s going to wo=
rk, for the same reason</div><div>as my P0424R0 paper was not warmly receiv=
ed. The reason is that implementers</div><div>don&#39;t want anything that =
encourages the use of large template parameter lists,</div><div>because the=
 representation of that inside the compiler is too inefficient. They don&#3=
9;t</div><div>want a single template parameter per character in the string,=
 because the structure</div><div>that represents a template parameter in th=
e compiler is expensive. Instead, they&#39;d</div><div>rather have a single=
 structure that represents all the characters. I&#39;m not sure why they</d=
iv><div>can&#39;t just represent a character pack in a more efficient manne=
r, but that&#39;s what I</div><div>was told when I presented in EWG.</div><=
div><br></div><div>So on Saturday, we tried looking into passing arrays as =
template arguments, but</div><div>that becomes messy because arrays are alr=
eady supported, but they decay to</div><div>pointers so we&#39;d need to su=
pport a new syntax. We then tried passing std::array,</div><div>but doing t=
his cleanly would require passing arbitrary literal types as template</div>=
<div>arguments, which is also non-trivial of a change.</div><div><br></div>=
<div>I have not started writing a paper yet, because I don&#39;t have any s=
olution in mind</div><div>at this time to be honest. However, this is one o=
f the most valuable problems to</div><div>be solved for metaprogramming, so=
 I&#39;ll take anything that works.</div></div></blockquote><div><br></div>=
<div style=3D"font-family: arial, sans-serif; font-size: small;">What about=
 automatically generating types for string-literals?</div><div style=3D"fon=
t-family: arial, sans-serif; font-size: small;">Probably with a built-in=C2=
=A0<span style=3D"color: rgb(0, 0, 0); font-family: dejavusans, &quot;dejav=
u sans&quot;, arial, sans-serif; font-size: 12.8px;">literal operator &#39;=
lit&#39; that does the compiler magic.</span><br></div><div style=3D"font-f=
amily: arial, sans-serif; font-size: small;"><span style=3D"color: rgb(0, 0=
, 0); font-family: dejavusans, &quot;dejavu sans&quot;, arial, sans-serif; =
font-size: 12.8px;"><br></span></div><div style=3D"font-family: arial, sans=
-serif; font-size: small;"><div>The generated type of a string-literal=C2=
=A0is guaranteed to be the same across TUs.</div><div>Such a type should pr=
ovide some constexpr methods/typedefs to access its intrinsic (e.g. size(),=
 operator[], char_type, etc).</div></div><div style=3D"font-family: arial, =
sans-serif; font-size: small;"><br></div><div style=3D"font-family: arial, =
sans-serif; font-size: small;">For example:</div><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;"><cod=
e class=3D"prettyprint"><div class=3D"subprettyprint"><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;" cl=
ass=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> str </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">=
&quot;Hello&quot;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">lit</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: #008;" class=3D"styled-by-prettify">static_assert</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">is_same</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">decltype</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">str</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">),</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">decltype</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #080;" class=3D"styled-by-pretti=
fy">&quot;Hello&quot;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">lit</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">)&gt;::</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>value</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: #008;" class=3D"styled-by-prettify">static_assert</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">is_same</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">decltype</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">str</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">char_type</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">ch=
ar</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;::</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">value</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><span style=3D=
"color: #008;" class=3D"styled-by-prettify">static_assert</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">s</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 style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #080;" class=3D"styled-by-prettify">&#39;H&#39;</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">);</span></div></co=
de></div><div style=3D"font-family: arial, sans-serif; font-size: small;"><=
br>Has idea like this been discussed?</div></div>

<p></p>

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

------=_Part_5381_930922786.1479366622806--

------=_Part_5380_1809884440.1479366622806--

.

------=_Part_4483_1132369733.1479367380085
Content-Type: multipart/alternative;
 boundary="----=_Part_4484_1017898364.1479367380086"

------=_Part_4484_1017898364.1479367380086
Content-Type: text/plain; charset=UTF-8

No, this has not been discussed AFAICT. That's not a bad idea, but it does
seem very magic to me.
I don't know whether it's more desirable to introduce this special case or
to "fix" the problem by
allowing user defined types with some restrictions as template arguments.
Certainly the latter is
cleaner, but also much more difficult.

Louis


On Thursday, 17 November 2016 08:10:22 UTC+1, TONGARI J wrote:
>
> On Thursday, November 17, 2016 at 1:28:26 PM UTC+8, Louis Dionne wrote:
>>
>> Let me just expand a bit on what Matt said.
>>
>> I think this is a brilliant idea, but I don't think it's going to work,
>> for the same reason
>> as my P0424R0 paper was not warmly received. The reason is that
>> implementers
>> don't want anything that encourages the use of large template parameter
>> lists,
>> because the representation of that inside the compiler is too
>> inefficient. They don't
>> want a single template parameter per character in the string, because the
>> structure
>> that represents a template parameter in the compiler is expensive.
>> Instead, they'd
>> rather have a single structure that represents all the characters. I'm
>> not sure why they
>> can't just represent a character pack in a more efficient manner, but
>> that's what I
>> was told when I presented in EWG.
>>
>> So on Saturday, we tried looking into passing arrays as template
>> arguments, but
>> that becomes messy because arrays are already supported, but they decay to
>> pointers so we'd need to support a new syntax. We then tried passing
>> std::array,
>> but doing this cleanly would require passing arbitrary literal types as
>> template
>> arguments, which is also non-trivial of a change.
>>
>> I have not started writing a paper yet, because I don't have any solution
>> in mind
>> at this time to be honest. However, this is one of the most valuable
>> problems to
>> be solved for metaprogramming, so I'll take anything that works.
>>
>
> What about automatically generating types for string-literals?
> Probably with a built-in literal operator 'lit' that does the compiler
> magic.
>
> The generated type of a string-literal is guaranteed to be the same across
> TUs.
> Such a type should provide some constexpr methods/typedefs to access its
> intrinsic (e.g. size(), operator[], char_type, etc).
>
> For example:
> constexpr auto str = "Hello"lit;
> static_assert(is_same<decltype(str), decltype("Hello"lit)>::value);
> static_assert(is_same<decltype(str)::char_type, char>::value);
> static_assert(s[0] == 'H');
>
> Has idea like this been discussed?
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f99786d0-d4fd-40ee-89fe-89399fe8d600%40isocpp.org.

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

<div dir=3D"ltr">No, this has not been discussed AFAICT. That&#39;s not a b=
ad idea, but it does seem very magic to me.<div>I don&#39;t know whether it=
&#39;s more desirable to introduce this special case or to &quot;fix&quot; =
the problem by</div><div>allowing user defined types with some restrictions=
 as template arguments. Certainly the latter is</div><div>cleaner, but also=
 much more difficult.</div><div><br></div><div>Louis<br><div><br><br>On Thu=
rsday, 17 November 2016 08:10:22 UTC+1, TONGARI J  wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">On Thursday, November 17, 2016=
 at 1:28:26 PM UTC+8, Louis Dionne 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"><div>Let me just expand a bit on what Matt said.</di=
v><div><br></div><div>I think this is a brilliant idea, but I don&#39;t thi=
nk it&#39;s going to work, for the same reason</div><div>as my P0424R0 pape=
r was not warmly received. The reason is that implementers</div><div>don&#3=
9;t want anything that encourages the use of large template parameter lists=
,</div><div>because the representation of that inside the compiler is too i=
nefficient. They don&#39;t</div><div>want a single template parameter per c=
haracter in the string, because the structure</div><div>that represents a t=
emplate parameter in the compiler is expensive. Instead, they&#39;d</div><d=
iv>rather have a single structure that represents all the characters. I&#39=
;m not sure why they</div><div>can&#39;t just represent a character pack in=
 a more efficient manner, but that&#39;s what I</div><div>was told when I p=
resented in EWG.</div><div><br></div><div>So on Saturday, we tried looking =
into passing arrays as template arguments, but</div><div>that becomes messy=
 because arrays are already supported, but they decay to</div><div>pointers=
 so we&#39;d need to support a new syntax. We then tried passing std::array=
,</div><div>but doing this cleanly would require passing arbitrary literal =
types as template</div><div>arguments, which is also non-trivial of a chang=
e.</div><div><br></div><div>I have not started writing a paper yet, because=
 I don&#39;t have any solution in mind</div><div>at this time to be honest.=
 However, this is one of the most valuable problems to</div><div>be solved =
for metaprogramming, so I&#39;ll take anything that works.</div></div></blo=
ckquote><div><br></div><div style=3D"font-family:arial,sans-serif;font-size=
:small">What about automatically generating types for string-literals?</div=
><div style=3D"font-family:arial,sans-serif;font-size:small">Probably with =
a built-in=C2=A0<span style=3D"color:rgb(0,0,0);font-family:dejavusans,&quo=
t;dejavu sans&quot;,arial,sans-serif;font-size:12.8px">literal operator &#3=
9;lit&#39; that does the compiler magic.</span><br></div><div style=3D"font=
-family:arial,sans-serif;font-size:small"><span style=3D"color:rgb(0,0,0);f=
ont-family:dejavusans,&quot;dejavu sans&quot;,arial,sans-serif;font-size:12=
..8px"><br></span></div><div style=3D"font-family:arial,sans-serif;font-size=
:small"><div>The generated type of a string-literal=C2=A0is guaranteed to b=
e the same across TUs.</div><div>Such a type should provide some constexpr =
methods/typedefs to access its intrinsic (e.g. size(), operator[], char_typ=
e, etc).</div></div><div style=3D"font-family:arial,sans-serif;font-size:sm=
all"><br></div><div style=3D"font-family:arial,sans-serif;font-size:small">=
For example:</div><div style=3D"background-color:rgb(250,250,250);border-co=
lor:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-wo=
rd"><code><div><span style=3D"color:#008">constexpr</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#008">auto</span><span style=3D"colo=
r:#000"> str </span><span style=3D"color:#660">=3D</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#080">&quot;Hello&quot;</span><span s=
tyle=3D"color:#000">lit</span><span style=3D"color:#660">;</span><span styl=
e=3D"color:#000"><br></span><span style=3D"color:#008">static_assert</span>=
<span style=3D"color:#660">(</span><span style=3D"color:#000">is_same</span=
><span style=3D"color:#660">&lt;</span><span style=3D"color:#008">decltype<=
/span><span style=3D"color:#660"><wbr>(</span><span style=3D"color:#000">st=
r</span><span style=3D"color:#660">),</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#008">decltype</span><span style=3D"color:#660">(<=
/span><span style=3D"color:#080">&quot;Hello&quot;</span><span style=3D"col=
or:#000">lit</span><span style=3D"color:#660">)&gt;::</span><span style=3D"=
color:#000">value</span><span style=3D"color:#660">);</span><span style=3D"=
color:#000"><br></span><span style=3D"color:#008">static_assert</span><span=
 style=3D"color:#660">(</span><span style=3D"color:#000">is_same</span><spa=
n style=3D"color:#660">&lt;</span><span style=3D"color:#008">decltype</span=
><span style=3D"color:#660"><wbr>(</span><span style=3D"color:#000">str</sp=
an><span style=3D"color:#660">)::</span><span style=3D"color:#000">char_typ=
e</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#008">char</span><span style=3D"color:#660">&gt;::<=
/span><span style=3D"color:#000">value</span><span style=3D"color:#660">);<=
/span><span style=3D"color:#000"><br></span><span style=3D"color:#008">stat=
ic_assert</span><span style=3D"color:#660">(</span><span style=3D"color:#00=
0">s</span><span style=3D"color:#660">[</span><span style=3D"color:#066">0<=
/span><span style=3D"color:#660">]</span><span style=3D"color:#000"> </span=
><span style=3D"color:#660">=3D=3D</span><span style=3D"color:#000"> </span=
><span style=3D"color:#080">&#39;H&#39;</span><span style=3D"color:#660">);=
</span></div></code></div><div style=3D"font-family:arial,sans-serif;font-s=
ize:small"><br>Has idea like this been discussed?</div></div></blockquote><=
/div></div></div>

<p></p>

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

------=_Part_4484_1017898364.1479367380086--

------=_Part_4483_1132369733.1479367380085--

.

------=_Part_5649_555192666.1479368424159
Content-Type: multipart/alternative;
 boundary="----=_Part_5650_413995084.1479368424160"

------=_Part_5650_413995084.1479368424160
Content-Type: text/plain; charset=UTF-8

On Thursday, November 17, 2016 at 3:23:00 PM UTC+8, Louis Dionne wrote:
>
> No, this has not been discussed AFAICT. That's not a bad idea, but it does
> seem very magic to me.
> I don't know whether it's more desirable to introduce this special case or
> to "fix" the problem by
> allowing user defined types with some restrictions as template arguments.
> Certainly the latter is
> cleaner, but also much more difficult.
>

It's only as magic as lambda expressions :)
The idea is very similar, the big difference is that lambda will give you
different types even if the expressions are lexically the same, while this
will give you the same type as long as the string-literals are the same.
Further more, we can define some useful operations to help string
processing, e.g.

static_assert(is_same<decltype("Hello"lit + " World"lit), decltype("Hello
World"lit)>::value);

This is certainly not as general as allowing UDTs as template arguments,
but should solve a practical problem in compile-time string processing.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/10914b55-c188-4573-a4c7-ba686f213a38%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, November 17, 2016 at 3:23:00 PM UTC+8, Louis =
Dionne 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">=
No, this has not been discussed AFAICT. That&#39;s not a bad idea, but it d=
oes seem very magic to me.<div>I don&#39;t know whether it&#39;s more desir=
able to introduce this special case or to &quot;fix&quot; the problem by</d=
iv><div>allowing user defined types with some restrictions as template argu=
ments. Certainly the latter is</div><div>cleaner, but also much more diffic=
ult.</div></div></blockquote><div><br></div><div style=3D"font-family: aria=
l, sans-serif; font-size: small;">It&#39;s only as magic as lambda expressi=
ons :)</div><div style=3D"font-family: arial, sans-serif; font-size: small;=
">The idea is very similar, the big difference is that lambda will give you=
 different types even if the expressions are lexically the same, while this=
 will give you the same type as long as the string-literals are the same.</=
div><div style=3D"font-family: arial, sans-serif; font-size: small;">Furthe=
r more, we can define some useful operations to help string processing, e.g=
..</div><div style=3D"font-family: arial, sans-serif; font-size: small;"><br=
></div><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">stati=
c_assert</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">is_same</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">decltype</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #080;" class=3D"styled-by-prettify">&quot;Hello&quot;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">lit </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">+</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" =
class=3D"styled-by-prettify">&quot; World&quot;</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify">lit</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">),</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">decltype</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #080;" class=3D"styled-by-pretti=
fy">&quot;Hello World&quot;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">lit</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">)&gt;::</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">value</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><div><br><span style=3D"font-family: arial, sans-se=
rif; font-size: small;">This is certainly not as general as allowing UDTs a=
s template arguments, but should solve a practical problem in compile-time =
string processing.</span></div></div>

<p></p>

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

------=_Part_5650_413995084.1479368424160--

------=_Part_5649_555192666.1479368424159--

.

--94eb2c08adaad207d305417ac4a5
Content-Type: text/plain; charset=UTF-8

Sorry if I'm asking the obvious question here: Why not guarantee that
different string literals have different addresses and the same string
literal has the same address and use const char* as non-type template
parameters?

Jonathan

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJZf-Y9D90ZePLoMv_HcFeCJz%2BFC25WRVdWZjbsrrS4FEQ%40mail.gmail.com.

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

<p dir=3D"ltr">Sorry if I&#39;m asking the obvious question here: Why not g=
uarantee that different string literals have different addresses and the sa=
me string literal has the same address and use const char* as non-type temp=
late parameters?</p>
<p dir=3D"ltr">Jonathan</p>

<p></p>

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

--94eb2c08adaad207d305417ac4a5--

.

On 17 November 2016 at 10:13, Jonathan M=C3=BCller
<jonathanmueller.dev@gmail.com> wrote:
> Sorry if I'm asking the obvious question here: Why not guarantee that
> different string literals have different addresses and the same string
> literal has the same address and use const char* as non-type template
> parameters?

It's less of a problem of guaranteeing that different literals have
different addresses, and
more a problem of avoiding identical literals possibly having
different addresses. Therefore
it's better to have the template equivalence be determined by the
contents of the string
rather than the address.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUY2PhGLKB89dun0teFynYW104xr4w-%2BkV-ae2tJX=
5W8YA%40mail.gmail.com.

.

------=_Part_4940_1827998296.1479370999176
Content-Type: multipart/alternative;
 boundary="----=_Part_4941_694291348.1479370999177"

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

Another problem is that "different" literals for address purposes could be=
=20
the
same when doing a strcmp-style comparison. Consider:

    foo<"hello world">
    foo<"hello world\0abcd">

Should these two resolve to the same template? If we use the address of=20
literals,
certainly not. If we compare the contents of the string, I guess that=20
remains an
open issue but the two behaviors could be envisioned.

Louis


On Thursday, 17 November 2016 09:19:32 UTC+1, Ville Voutilainen wrote:
>
> On 17 November 2016 at 10:13, Jonathan M=C3=BCller=20
> <jonathanm...@gmail.com <javascript:>> wrote:=20
> > Sorry if I'm asking the obvious question here: Why not guarantee that=
=20
> > different string literals have different addresses and the same string=
=20
> > literal has the same address and use const char* as non-type template=
=20
> > parameters?=20
>
> It's less of a problem of guaranteeing that different literals have=20
> different addresses, and=20
> more a problem of avoiding identical literals possibly having=20
> different addresses. Therefore=20
> it's better to have the template equivalence be determined by the=20
> contents of the string=20
> rather than the address.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/f8c8b5e6-3d69-4605-bd5d-161c3e47ca7e%40isocpp.or=
g.

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

<div dir=3D"ltr"><div><div>Another problem is that &quot;different&quot; li=
terals for address purposes could be the</div><div>same when doing a strcmp=
-style comparison. Consider:</div><div><br></div><div>=C2=A0 =C2=A0 foo&lt;=
&quot;hello world&quot;&gt;</div><div>=C2=A0 =C2=A0 foo&lt;&quot;hello worl=
d\0abcd&quot;&gt;</div><div><br></div><div>Should these two resolve to the =
same template? If we use the address of literals,</div><div>certainly not. =
If we compare the contents of the string, I guess that remains an</div><div=
>open issue but the two behaviors could be envisioned.</div><div><br></div>=
<div>Louis</div></div><br><br>On Thursday, 17 November 2016 09:19:32 UTC+1,=
 Ville Voutilainen  wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 1=
7 November 2016 at 10:13, Jonathan M=C3=BCller
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
eG2iRnltAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">jonathanm...@gmail.com</a><wbr>&gt; wrote:
<br>&gt; Sorry if I&#39;m asking the obvious question here: Why not guarant=
ee that
<br>&gt; different string literals have different addresses and the same st=
ring
<br>&gt; literal has the same address and use const char* as non-type templ=
ate
<br>&gt; parameters?
<br>
<br>It&#39;s less of a problem of guaranteeing that different literals have
<br>different addresses, and
<br>more a problem of avoiding identical literals possibly having
<br>different addresses. Therefore
<br>it&#39;s better to have the template equivalence be determined by the
<br>contents of the string
<br>rather than the address.
<br></blockquote></div>

<p></p>

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

------=_Part_4941_694291348.1479370999177--

------=_Part_4940_1827998296.1479370999176--

.

On Thu, Nov 17, 2016 at 3:13 AM, Jonathan M=C3=BCller
<jonathanmueller.dev@gmail.com> wrote:
> Sorry if I'm asking the obvious question here: Why not guarantee that
> different string literals have different addresses and the same string
> literal has the same address and use const char* as non-type template
> parameters?

Ville and Louis already covered a couple of reasons why this won't
work, but yet another is that not all string template arguments come
directly from literals. It's entirely possible that such strings will
be the result of compile-time string manipulations (and I predict that
this may even end up being fairly common, given metaprogramming).

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CANh8DEkmUOnyBvC2%3Dz1eETFq%2BBjAax15mAVaAP%3DF1=
GbVCHgtGg%40mail.gmail.com.

.

On 11/17/2016 03:13 AM, Jonathan M=C3=BCller wrote:
>
> Sorry if I'm asking the obvious question here: Why not guarantee that=20
> different string literals have different addresses and the same string=20
> literal has the same address and use const char* as non-type template=20
> parameters?
>
I believe one of the complications here is systems that support shared=20
libraries.  The opportunity to assign common addresses for equal string=20
literals doesn't arise until run-time.

Tom.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/cb9de829-bc1b-f9b7-6864-6b5ad0c4b5af%40honermann=
..net.

.

This is a multi-part message in MIME format.
--------------1ECB6F4A89B94423D6D5BA7C
Content-Type: text/plain; charset=UTF-8; format=flowed

On 11/17/2016 02:10 AM, TONGARI J wrote:
> What about automatically generating types for string-literals?
> Probably with a built-in literal operator 'lit' that does the compiler
> magic.
I've given this a little thought.  My motivation comes from wanting to
know the encoding of a string literal (e.g., implementation defined
execution character set vs UTF-8).  Presumably, the generated/deduced
type could record this information.  Such a mechanism would address the
use cases that motivated P0482R0
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0482r0.html>.

I think the primary difficulty with such an approach is addressing
backward compatibility; in particular standard conversions and overload
resolution.  The generated/deduced type would have to allow implicit
conversion to an (lvalue) array of code unit type (and then allow
array-to-pointer decay).  The potential difficulties with specifying
such behavior are briefly discussed in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0482r0.html#design_compat_core.

You're proposal would presumably break the following code unless special
rules we're introduced to allow a different type deduction for deduced
pointer types.

auto *p = "text";

Tom.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/08b6d632-c137-b039-9d79-7e67f9ccecfa%40honermann.net.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 11/17/2016 02:10 AM, TONGARI J
      wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:6b73bf50-4189-4d5d-a2c0-2debb085659e@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">What about automatically generating types for
        string-literals?
        <div style=3D"font-family: arial, sans-serif; font-size: small;">Pr=
obably
          with a built-in=C2=A0<span style=3D"color: rgb(0, 0, 0); font-fam=
ily:
            dejavusans, &quot;dejavu sans&quot;, arial, sans-serif;
            font-size: 12.8px;">literal operator 'lit' that does the
            compiler magic.</span><br>
        </div>
      </div>
    </blockquote>
    I've given this a little thought.=C2=A0 My motivation comes from wantin=
g
    to know the encoding of a string literal (e.g., implementation
    defined execution character set vs UTF-8).=C2=A0 Presumably, the
    generated/deduced type could record this information.=C2=A0 Such a
    mechanism would address the use cases that motivated <a
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0482r0.htm=
l">P0482R0</a>.<br>
    <br>
    I think the primary difficulty with such an approach is addressing
    backward compatibility; in particular standard conversions and
    overload resolution.=C2=A0 The generated/deduced type would have to all=
ow
    implicit conversion to an (lvalue) array of code unit type (and then
    allow array-to-pointer decay).=C2=A0 The potential difficulties with
    specifying such behavior are briefly discussed in
<a class=3D"moz-txt-link-freetext" href=3D"http://www.open-std.org/jtc1/sc2=
2/wg21/docs/papers/2016/p0482r0.html#design_compat_core">http://www.open-st=
d.org/jtc1/sc22/wg21/docs/papers/2016/p0482r0.html#design_compat_core</a>.<=
br>
    <br>
    You're proposal would presumably break the following code unless
    special rules we're introduced to allow a different type deduction
    for deduced pointer types.<br>
    <br>
    auto *p =3D "text";<br>
    <br>
    Tom.
  </body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/08b6d632-c137-b039-9d79-7e67f9ccecfa%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/08b6d632-c137-b039-9d79-7e67f9cce=
cfa%40honermann.net</a>.<br />

--------------1ECB6F4A89B94423D6D5BA7C--

.

Perhaps pass it not as a value, but as a (class-) type with a new kind
of type specifier. Then you can use a type template parameter, and
need to invent only syntax to denote these types. The type would have
a "value" static constexpr member that denotes the value. For string
literals, that would be a char array. Notice that this approach will
be compatible with passing std::integral_constant as a type, just that
the actual type will be some "magic" type. Using the "decltype"
keyword here, I'm making an example

    template<typename Name>
    struct Variable {
        void print() { std::cout << Name::value; }
    };

    Variable<decltype<"Hello folks">> v;
    v.print(); // prints "Hello folks" (without quotes)

    Variable <decltype<42>> v42;
    v42.print(); // prints 42

If we expose the type (bikeshed warning) as "std::constant", we could
also specialize on it

    template<>
    struct Variable<std::constant<int>> { };

I can imagine that with concepts, one could also specialize on the
contained value, although I'm not familiar with the exact syntax and
whether it actually could work

    template<typename C> // C will be char[N]
       requires constexprCompareFunction(C::value, "Hello folks")
    struct Variable<std::constant<C>> { };

All kind of literals are allowed. Perhaps one can extend it to all
kinds of constant expressions even.

2016-11-17 6:28 GMT+01:00 Louis Dionne <ldionne.2@gmail.com>:
> Let me just expand a bit on what Matt said.
>
> I think this is a brilliant idea, but I don't think it's going to work, for
> the same reason
> as my P0424R0 paper was not warmly received. The reason is that implementers
> don't want anything that encourages the use of large template parameter
> lists,
> because the representation of that inside the compiler is too inefficient.
> They don't
> want a single template parameter per character in the string, because the
> structure
> that represents a template parameter in the compiler is expensive. Instead,
> they'd
> rather have a single structure that represents all the characters. I'm not
> sure why they
> can't just represent a character pack in a more efficient manner, but that's
> what I
> was told when I presented in EWG.
>
> So on Saturday, we tried looking into passing arrays as template arguments,
> but
> that becomes messy because arrays are already supported, but they decay to
> pointers so we'd need to support a new syntax. We then tried passing
> std::array,
> but doing this cleanly would require passing arbitrary literal types as
> template
> arguments, which is also non-trivial of a change.
>
> I have not started writing a paper yet, because I don't have any solution in
> mind
> at this time to be honest. However, this is one of the most valuable
> problems to
> be solved for metaprogramming, so I'll take anything that works.
>
> Louis
>
>
> On Wednesday, 16 November 2016 15:18:23 UTC+1, Matt Calabrese wrote:
>>
>> On Wed, Nov 16, 2016 at 9:04 AM, Vittorio Romeo
>> <vittorio....@gmail.com> wrote:
>> > Currently string literals are not allowed as template arguments because
>> > the
>> > standard explicitly prevents that (see 14.3.2 Template non-type
>> > arguments).
>>
>> At the end of the Issaquah C++ standards meeting last week some of us
>> worked toward another approach to arrays as value-kind template
>> parameters (Louis Dione, Jeff Snyder, James Touton, myself, and
>> others), specifically because of wanting to easily pass compile-time
>> strings. It's a harder problem than it seems and implementors voiced
>> concern regarding representation as a pack of char even though the
>> desired semantics are similar. I'm not sure, but Louis Dionne might
>> already be starting on a new paper in this area. There are a few of us
>> who really want something like this.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d9433fac-152f-4515-b518-985a78768c03%40isocpp.org.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANu6V4WLfjDJF%2BNjRQcOE0vO2Fd%3DFnEtOgTQg9N8%2BmcyZ%2BvX7A%40mail.gmail.com.

.

And you need something to guarantee that decltype<0> is not the same
type as decltype<1> in order for the templates that receive the types
to be different for different constants ^_^ Perhaps you can make it a
hidden compiler type and the user could simply write the above
concepts-thingy as

    template<> struct Variable<decltype<"Hello folks">> { };

To say "some string", you could catch the type type and require that
it's for a string-literal

    template<typename C>
       requires StringLiteralConstant<C>
    struct Variable<C> { };

2016-11-17 16:41 GMT+01:00 Johannes Schaub <schaub.johannes@googlemail.com>:
> Perhaps pass it not as a value, but as a (class-) type with a new kind
> of type specifier. Then you can use a type template parameter, and
> need to invent only syntax to denote these types. The type would have
> a "value" static constexpr member that denotes the value. For string
> literals, that would be a char array. Notice that this approach will
> be compatible with passing std::integral_constant as a type, just that
> the actual type will be some "magic" type. Using the "decltype"
> keyword here, I'm making an example
>
>     template<typename Name>
>     struct Variable {
>         void print() { std::cout << Name::value; }
>     };
>
>     Variable<decltype<"Hello folks">> v;
>     v.print(); // prints "Hello folks" (without quotes)
>
>     Variable <decltype<42>> v42;
>     v42.print(); // prints 42
>
> If we expose the type (bikeshed warning) as "std::constant", we could
> also specialize on it
>
>     template<>
>     struct Variable<std::constant<int>> { };
>
> I can imagine that with concepts, one could also specialize on the
> contained value, although I'm not familiar with the exact syntax and
> whether it actually could work
>
>     template<typename C> // C will be char[N]
>        requires constexprCompareFunction(C::value, "Hello folks")
>     struct Variable<std::constant<C>> { };
>
> All kind of literals are allowed. Perhaps one can extend it to all
> kinds of constant expressions even.
>
> 2016-11-17 6:28 GMT+01:00 Louis Dionne <ldionne.2@gmail.com>:
>> Let me just expand a bit on what Matt said.
>>
>> I think this is a brilliant idea, but I don't think it's going to work, for
>> the same reason
>> as my P0424R0 paper was not warmly received. The reason is that implementers
>> don't want anything that encourages the use of large template parameter
>> lists,
>> because the representation of that inside the compiler is too inefficient.
>> They don't
>> want a single template parameter per character in the string, because the
>> structure
>> that represents a template parameter in the compiler is expensive. Instead,
>> they'd
>> rather have a single structure that represents all the characters. I'm not
>> sure why they
>> can't just represent a character pack in a more efficient manner, but that's
>> what I
>> was told when I presented in EWG.
>>
>> So on Saturday, we tried looking into passing arrays as template arguments,
>> but
>> that becomes messy because arrays are already supported, but they decay to
>> pointers so we'd need to support a new syntax. We then tried passing
>> std::array,
>> but doing this cleanly would require passing arbitrary literal types as
>> template
>> arguments, which is also non-trivial of a change.
>>
>> I have not started writing a paper yet, because I don't have any solution in
>> mind
>> at this time to be honest. However, this is one of the most valuable
>> problems to
>> be solved for metaprogramming, so I'll take anything that works.
>>
>> Louis
>>
>>
>> On Wednesday, 16 November 2016 15:18:23 UTC+1, Matt Calabrese wrote:
>>>
>>> On Wed, Nov 16, 2016 at 9:04 AM, Vittorio Romeo
>>> <vittorio....@gmail.com> wrote:
>>> > Currently string literals are not allowed as template arguments because
>>> > the
>>> > standard explicitly prevents that (see 14.3.2 Template non-type
>>> > arguments).
>>>
>>> At the end of the Issaquah C++ standards meeting last week some of us
>>> worked toward another approach to arrays as value-kind template
>>> parameters (Louis Dione, Jeff Snyder, James Touton, myself, and
>>> others), specifically because of wanting to easily pass compile-time
>>> strings. It's a harder problem than it seems and implementors voiced
>>> concern regarding representation as a pack of char even though the
>>> desired semantics are similar. I'm not sure, but Louis Dionne might
>>> already be starting on a new paper in this area. There are a few of us
>>> who really want something like this.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d9433fac-152f-4515-b518-985a78768c03%40isocpp.org.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANu6V4W8v_rJNw0-mNbFbqE5OvqvxD8T3yWOjzQdKQbR_qzCog%40mail.gmail.com.

.

--001a113e2b58fafa16054181aadc
Content-Type: text/plain; charset=UTF-8

On Thu, Nov 17, 2016 at 12:28 AM, Louis Dionne <ldionne.2@gmail.com> wrote:
>
> So on Saturday, we tried looking into passing arrays as template
> arguments, but
> that becomes messy because arrays are already supported, but they decay to
> pointers so we'd need to support a new syntax. We then tried passing
> std::array,
> but doing this cleanly would require passing arbitrary literal types as
> template
> arguments, which is also non-trivial of a change.
>

FWIW, I think that either supporting std::array or supporting some kind of
new built-in array type that doesn't decay (and is convertible from
existing array types) is most likely the way we'd need to go. I'm not
entirely convinced of the implication being that we'd need to support
passing arbitrary literal types as template arguments in order to get one
of these solutions -- we can just limit the element type of the array to
being a type from the set of existing non-type template argument types that
are also valid array element types. This seems to be a reasonable
restriction and avoids all of the scary questions regarding support for
literal types as non-type template parameter types.

One reason that I lean toward a new, language-level array type is that
there are other problems with arrays that, in my opinion, hold the language
back. Here's a brief, non-exhaustive list of issues with existing c-arrays:

* They decay
* They cannot have a 0-length extent
* There are all of the problems already mentioned in this thread regarding
difficulty in supporting them as non-type template parameter types
* If we hope for the language to ever support size-0 types, I suggest that
c-style arrays would be one of the main barriers (more on this later)
* They are neither copyable nor movable
* They are not comparable

From that list, I consider the last two to be things that actually might be
able to be fixed with respect to c-style arrays without introducing a new
type. I may write a paper on this, specifically, but the other issues
remain.

std::array fixes some of these problems but introduces others:
* Multi-dimensional arrays are not directly supported (yet) and std::array
of std::array is a hairy alternative
* No simple way to dynamically allocate a std::array of N elements, where N
is only known at run-time
* Template instantiations :|
* It's a library solution for "fixing" a legacy language issue (I'm usually
for library solutions to problems rather than language, but not when the
library is the preferred alternative to a built-in language facility)
* Special-casing support for std::array as a valid non-type template
argument would be somewhat weird and puts an... interesting dependency on
the library from the language.

As much as I like std::array for everything it fixes, I really think that
we should, if at all possible, have a language-level array type that's
simply not broken. I just suspect that it would be difficult to get
consensus since we'd likely never be able to get rid of existing c-style
arrays and having two fundamental array kinds would be weird. It would also
mean that there would be no less than 3 ways to create an array in standard
C++ (c-style, std::array, and the hypothetical new type).

Earlier in this post I mentioned that existing c-style arrays may be a
barrier for the language eventually supporting size-0 types. Hopefully not
derailing the thread too much, but to elaborate on that, c-style arrays
have the requirement of pointer-to-element-type being the corresponding
iterator type of the array. That is to say, given an array T array[N],
[array + 0, array+N) is a valid range over N elements, with T* being the
iterator type. Sean Parent and others have been vocal about the desire for
size-0 types, but, unfortunately, I see that as very difficult when it
comes to existing assumptions with respect to arrays. Imagine, for
instance, that "T" here is a hypothetical size 0 type. This means that
"array" should also be size 0. This also means that [array + 0, array + N),
with iterator type T*, no longer forms a range of length N. It actually
forms a range of length 0. This means that any generic code that depends on
T* being an appropriate iterator type may break when T happens to be a size
0 type. Other languages that support size 0 types, such as Rust, don't have
this problem because their array iterators aren't required to be pointers.
In the size 0 element case, the iterator type instead contains an index and
so you can form proper ranges. IMO, having an array type in C++ that didn't
require pointers as the iterator type would be a step in a positive
direction.

There are other problems with size 0 types, such as that for desired
effects, you'd want "distinct" size-0 objects to be able to have the same
address (the array case is just one example of this). I consider this to be
less of an issue in practice.

Anyway, the overall point is that time and time again we run into c-style
arrays being a barrier to progress. std::array is a great alternative, but
I don't think we should discount trying to have a new built-in array type
that is "compatible" with existing c-style arrays (can extract a pointer or
reference to c-style array given a new-style array in cases where it is
feasible). This could potentially make the array template-parameter-kind
more feasible along with solving the other existing issues with built-in
arrays.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEkETbqD0%2BgrrC-SROXSOSeB8z5cqFJRJ049Q6f6YmWp_g%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Nov 17, 2016 at 12:28 AM, Louis Dionne <span dir=3D"ltr">&lt;<a href=3D=
"mailto:ldionne.2@gmail.com" target=3D"_blank">ldionne.2@gmail.com</a>&gt;<=
/span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>So on Sat=
urday, we tried looking into passing arrays as template arguments, but</div=
><div>that becomes messy because arrays are already supported, but they dec=
ay to</div><div>pointers so we&#39;d need to support a new syntax. We then =
tried passing std::array,</div><div>but doing this cleanly would require pa=
ssing arbitrary literal types as template</div><div>arguments, which is als=
o non-trivial of a change.</div></div></blockquote><div><br></div><div>FWIW=
, I think that either supporting std::array or supporting some kind of new =
built-in array type that doesn&#39;t decay (and is convertible from existin=
g array types) is most likely the way we&#39;d need to go. I&#39;m not enti=
rely convinced of the implication being that we&#39;d need to support passi=
ng arbitrary literal types as template arguments in order to get one of the=
se solutions -- we can just limit the element type of the array to being a =
type from the set of existing non-type template argument types that are als=
o valid array element types. This seems to be a reasonable restriction and =
avoids all of the scary questions regarding support for literal types as no=
n-type template parameter types.</div><div><br></div><div>One reason that I=
 lean toward a new, language-level array type is that there are other probl=
ems with arrays that, in my opinion, hold the language back. Here&#39;s a b=
rief, non-exhaustive list of issues with existing c-arrays:</div><div><br><=
/div><div>* They decay</div><div>* They cannot have a 0-length extent</div>=
<div>* There are all of the problems already mentioned in this thread regar=
ding difficulty in supporting them as non-type template parameter types=C2=
=A0</div><div>* If we hope for the language to ever support size-0 types, I=
 suggest that c-style arrays would be one of the main barriers (more on thi=
s later)</div><div>* They are neither copyable nor movable</div><div>* They=
 are not comparable</div><div><br></div><div>From that list, I consider the=
 last two to be things that actually might be able to be fixed with respect=
 to c-style arrays without introducing a new type. I may write a paper on t=
his, specifically, but the other issues remain.</div><div><br></div><div>st=
d::array fixes some of these problems but introduces others:</div><div>* Mu=
lti-dimensional arrays are not directly supported (yet) and std::array of s=
td::array is a hairy alternative</div><div>* No simple way to dynamically a=
llocate a std::array of N elements, where N is only known at run-time</div>=
<div>* Template instantiations :|</div><div>* It&#39;s a library solution f=
or &quot;fixing&quot; a legacy language issue (I&#39;m usually for library =
solutions to problems rather than language, but not when the library is the=
 preferred alternative to a built-in language facility)</div><div>* Special=
-casing support for std::array as a valid non-type template argument would =
be somewhat weird and puts an... interesting dependency on the library from=
 the language.</div><div><br></div><div>As much as I like std::array for ev=
erything it fixes, I really think that we should, if at all possible, have =
a language-level array type that&#39;s simply not broken. I just suspect th=
at it would be difficult to get consensus since we&#39;d likely never be ab=
le to get rid of existing c-style arrays and having two fundamental array k=
inds would be weird. It would also mean that there would be no less than 3 =
ways to create an array in standard C++ (c-style, std::array, and the hypot=
hetical new type).=C2=A0</div><div><br></div><div>Earlier in this post I me=
ntioned that existing c-style arrays may be a barrier for the language even=
tually supporting size-0 types. Hopefully not derailing the thread too much=
, but to elaborate on that, c-style arrays have the requirement of pointer-=
to-element-type being the corresponding iterator type of the array. That is=
 to say, given an array T array[N], [array + 0, array+N) is a valid range o=
ver N elements, with T* being the iterator type. Sean Parent and others hav=
e been vocal about the desire for size-0 types, but, unfortunately, I see t=
hat as very difficult when it comes to existing assumptions with respect to=
 arrays. Imagine, for instance, that &quot;T&quot; here is a hypothetical s=
ize 0 type. This means that &quot;array&quot; should also be size 0. This a=
lso means that [array + 0, array + N), with iterator type T*, no longer for=
ms a range of length N. It actually forms a range of length 0. This means t=
hat any generic code that depends on T* being an appropriate iterator type =
may break when T happens to be a size 0 type. Other languages that support =
size 0 types, such as Rust, don&#39;t have this problem because their array=
 iterators aren&#39;t required to be pointers. In the size 0 element case, =
the iterator type instead contains an index and so you can form proper rang=
es. IMO, having an array type in C++ that didn&#39;t require pointers as th=
e iterator type would be a step in a positive direction.</div><div><br></di=
v><div>There are other problems with size 0 types, such as that for desired=
 effects, you&#39;d want &quot;distinct&quot; size-0 objects to be able to =
have the same address (the array case is just one example of this). I consi=
der this to be less of an issue in practice.</div><div><br></div><div>Anywa=
y, the overall point is that time and time again we run into c-style arrays=
 being a barrier to progress. std::array is a great alternative, but I don&=
#39;t think we should discount trying to have a new built-in array type tha=
t is &quot;compatible&quot; with existing c-style arrays (can extract a poi=
nter or reference to c-style array given a new-style array in cases where i=
t is feasible). This could potentially make the array template-parameter-ki=
nd more feasible along with solving the other existing issues with built-in=
 arrays.</div></div></div></div>

<p></p>

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

--001a113e2b58fafa16054181aadc--

.

On quinta-feira, 17 de novembro de 2016 10:18:22 PST Tom Honermann wrote:
> On 11/17/2016 03:13 AM, Jonathan M=C3=BCller wrote:
> > Sorry if I'm asking the obvious question here: Why not guarantee that
> > different string literals have different addresses and the same string
> > literal has the same address and use const char* as non-type template
> > parameters?
>=20
> I believe one of the complications here is systems that support shared
> libraries.  The opportunity to assign common addresses for equal string
> literals doesn't arise until run-time.

But everything that depended on those literals would also be resolved at=20
runtime only (vague linkage).

(I'm not considering ODR-violating options like -fvisibility-inlines-hidden=
)

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7366336.xLjCtBizz3%40tjmaciei-mobl1.

.

On 11/17/2016 5:58 PM, Thiago Macieira wrote:
> On quinta-feira, 17 de novembro de 2016 10:18:22 PST Tom Honermann wrote:
>> On 11/17/2016 03:13 AM, Jonathan M=C3=BCller wrote:
>>> Sorry if I'm asking the obvious question here: Why not guarantee that
>>> different string literals have different addresses and the same string
>>> literal has the same address and use const char* as non-type template
>>> parameters?
>> I believe one of the complications here is systems that support shared
>> libraries.  The opportunity to assign common addresses for equal string
>> literals doesn't arise until run-time.
> But everything that depended on those literals would also be resolved at
> runtime only (vague linkage).

Vague linkage is not supported by all compilers/linkers, at least not=20
when shared libraries are involved.

Consider the following example compiled with MSVC 2013:

$ cat t.h
extern inline const char* f() {
   return "text";
}

$ cat dll1.cpp
#include "t.h"
__declspec(dllexport) const char* dll1() {
   return f();
}

$ cat dll2.cpp
#include "t.h"
__declspec(dllexport) const char* dll2() {
   return f();
}

$ cat main.cpp
#include <cassert>
__declspec(dllimport) const char* dll1();
__declspec(dllimport) const char* dll2();
int main() {
   assert(dll1() =3D=3D dll2());
}

$ cl /LD dll1.cpp /Fedll1.dll
....

$ cl /LD dll2.cpp /Fedll2.dll
....

$ cl main.cpp /Femain.exe dll1.lib dll2.lib
....

$ ./main
Assertion failed: dll1() =3D=3D dll2(), file main.cpp, line 5

Since f() is an inline function, the returned string literal is required=20
to have the same address in all TUs:

C++14 [dcl.fct.spec] Function specifiers p4:
....
A string literal in the body of an extern inline function is the same=20
object in different translation units.
....

However, Microsoft's compiler/linker does not implement this requirement=20
across shared library boundaries.  Since shared libraries are not=20
described by the standard, it is arguable whether this is a=20
non-conformance issue or not.

If the above code is compiled into a single executable on Windows, the=20
assert does not fail.

Tom.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/634b6222-d3e2-828b-75ec-f9da31b0493a%40honermann=
..net.

.

------=_Part_6956_1657314984.1479486626432
Content-Type: multipart/alternative;
 boundary="----=_Part_6957_126519399.1479486626432"

------=_Part_6957_126519399.1479486626432
Content-Type: text/plain; charset=UTF-8

How about allowing literal types as template arguments if they have
defaulted == and != operators (and this condition also applies recursively
to all of their members). It does look fairly likely that we will get
default ==
in the language in the near future. Once we have that, it would provide
a natural way to express which types are unproblematic for use as
template arguments.

This would be more than good enough to get us arrays of characters.

On Thursday, 17 November 2016 05:28:26 UTC, Louis Dionne wrote:
>
> So on Saturday, we tried looking into passing arrays as template
> arguments, but
> that becomes messy because arrays are already supported, but they decay to
> pointers so we'd need to support a new syntax. We then tried passing
> std::array,
> but doing this cleanly would require passing arbitrary literal types as
> template
> arguments, which is also non-trivial of a change.
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0cc57751-f41a-4da2-88e7-a42eb61f57cd%40isocpp.org.

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

<div dir=3D"ltr">How about allowing literal types as template arguments if =
they have<div>defaulted =3D=3D and !=3D operators (and this condition also =
applies recursively</div><div>to all of their members). It does look fairly=
 likely that we will get default =3D=3D</div><div>in the language in the ne=
ar future. Once we have that, it would provide</div><div>a natural way to e=
xpress which types are unproblematic for use as</div><div>template argument=
s.</div><div><br></div><div>This would be more than good enough to get us a=
rrays of characters.</div><div><br>On Thursday, 17 November 2016 05:28:26 U=
TC, Louis Dionne  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"><div>So on Saturday, we tried looking into passing arrays as tem=
plate arguments, but</div><div>that becomes messy because arrays are alread=
y supported, but they decay to</div><div>pointers so we&#39;d need to suppo=
rt a new syntax. We then tried passing std::array,</div><div>but doing this=
 cleanly would require passing arbitrary literal types as template</div><di=
v>arguments, which is also non-trivial of a change.</div></div></blockquote=
></div></div>

<p></p>

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

------=_Part_6957_126519399.1479486626432--

------=_Part_6956_1657314984.1479486626432--

.

--94eb2c1b5da47df0e90541961ba2
Content-Type: text/plain; charset=UTF-8

On Fri, Nov 18, 2016 at 11:30 AM, col3435 via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:

> How about allowing literal types as template arguments if they have
> defaulted == and != operators (and this condition also applies recursively
> to all of their members). It does look fairly likely that we will get
> default ==
> in the language in the near future. Once we have that, it would provide
> a natural way to express which types are unproblematic for use as
> template arguments.
>
> This would be more than good enough to get us arrays of characters.
>

This has came up independently by several of us. IMO, it's the most
reasonable way to support literal types as template arguments, if we ever
support them, but not everyone agrees. I think Faisal Vali and Andrew
Sutton were the most recent people pursuing literal types as template
parameter types (Faisal mentioned it to me only a few months ago). I'm not
sure what their approach will be, assuming they are still working on that
proposal.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEnp3%3D6Kcf2PiaYoDetAM2RVJY3jRyEzLc-7b%3DLJUj0kbA%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Fri, Nov 18, 2016 at 11:30 AM, col3435 via ISO C++ Standard - Future Pro=
posals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.org" ta=
rget=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">How about allowin=
g literal types as template arguments if they have<div>defaulted =3D=3D and=
 !=3D operators (and this condition also applies recursively</div><div>to a=
ll of their members). It does look fairly likely that we will get default =
=3D=3D</div><div>in the language in the near future. Once we have that, it =
would provide</div><div>a natural way to express which types are unproblema=
tic for use as</div><div>template arguments.</div><div><br></div><div>This =
would be more than good enough to get us arrays of characters.</div></div><=
/blockquote><div><br></div><div>This has came up independently by several o=
f us. IMO, it&#39;s the most reasonable way to support literal types as tem=
plate arguments, if we ever support them, but not everyone agrees. I think =
Faisal Vali and Andrew Sutton were the most recent people pursuing literal =
types as template parameter types (Faisal mentioned it to me only a few mon=
ths ago). I&#39;m not sure what their approach will be, assuming they are s=
till working on that proposal.</div></div></div></div>

<p></p>

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

--94eb2c1b5da47df0e90541961ba2--

.

On 11/18/2016 11:30 AM, col3435 via ISO C++ Standard - Future Proposals
wrote:
> How about allowing literal types as template arguments if they have
> defaulted == and != operators (and this condition also applies recursively
> to all of their members). It does look fairly likely that we will get
> default ==
> in the language in the near future. Once we have that, it would provide
> a natural way to express which types are unproblematic for use as
> template arguments.
>
> This would be more than good enough to get us arrays of characters.

For mangling purposes, I would expect a more strict requirement to be
necessary.  Probably that all non-static data members are types (or
arrays thereof) that are acceptable as non-type template arguments.

Note that literal types include void, so, unless the regular void
proposal is accepted, I think a term other than "literal type" is needed
to describe the acceptable types here.

Tom.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4e5c0e7e-74c1-1983-ad27-0baede6ebe0a%40honermann.net.

.

------=_Part_6123_1335432097.1479489163118
Content-Type: multipart/alternative;
 boundary="----=_Part_6124_1471515985.1479489163118"

------=_Part_6124_1471515985.1479489163118
Content-Type: text/plain; charset=UTF-8



On Friday, November 18, 2016 at 11:19:17 AM UTC-5, Tom Honermann wrote:
>
>
> Since f() is an inline function, the returned string literal is required
> to have the same address in all TUs:
>
> C++14 [dcl.fct.spec] Function specifiers p4:
> ...
> A string literal in the body of an extern inline function is the same
> object in different translation units.
> ...
>
>
This requirement has been removed by core issue 1823.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/35c7ffc8-ea26-41f4-8824-d6193b0adce0%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, November 18, 2016 at 11:19:17 AM UTC-5,=
 Tom Honermann wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>Since=
 f() is an inline function, the returned string literal is required=20
<br>to have the same address in all TUs:
<br>
<br>C++14 [dcl.fct.spec] Function specifiers p4:
<br>...
<br>A string literal in the body of an extern inline function is the same=
=20
<br>object in different translation units.
<br>...
<br><br></blockquote><div><br></div><div>This requirement has been removed =
by core issue 1823.=C2=A0</div></div>

<p></p>

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

------=_Part_6124_1471515985.1479489163118--

------=_Part_6123_1335432097.1479489163118--

.

This is a multi-part message in MIME format.
--------------8A6CA6B59FA68BA038E811A7
Content-Type: text/plain; charset=UTF-8; format=flowed

On 11/18/2016 12:12 PM, T. C. wrote:
>
>
> On Friday, November 18, 2016 at 11:19:17 AM UTC-5, Tom Honermann wrote:
>
>
>     Since f() is an inline function, the returned string literal is
>     required
>     to have the same address in all TUs:
>
>     C++14 [dcl.fct.spec] Function specifiers p4:
>     ...
>     A string literal in the body of an extern inline function is the same
>     object in different translation units.
>     ...
>
>
> This requirement has been removed by core issue 1823.

Interesting, I was unaware.  This sounds like additional evidence that
we cannot rely on string literals with matching contents having the same
address across TUs.

The point regarding vague linkage still stands though; the example still
fails the assertion if the inline function is modified to return the
address of a static local variable.  The WP still requires static local
variables in inline functions to be the same object across TUs
(http://eel.is/c++draft/dcl.inline)

$ cat t.h
extern inline const char* f() {
   static char c = 't';
   return &c;
}

Tom.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1bfc51e9-df00-696b-a6ed-6f2dedb5475e%40honermann.net.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 11/18/2016 12:12 PM, T. C. wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:35c7ffc8-ea26-41f4-8824-d6193b0adce0@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        <br>
        On Friday, November 18, 2016 at 11:19:17 AM UTC-5, Tom Honermann
        wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>
          Since f() is an inline function, the returned string literal
          is required <br>
          to have the same address in all TUs:
          <br>
          <br>
          C++14 [dcl.fct.spec] Function specifiers p4:
          <br>
          ...
          <br>
          A string literal in the body of an extern inline function is
          the same <br>
          object in different translation units.
          <br>
          ...
          <br>
          <br>
        </blockquote>
        <div><br>
        </div>
        <div>This requirement has been removed by core issue 1823. <br>
        </div>
      </div>
    </blockquote>
    <br>
    Interesting, I was unaware.=C2=A0 This sounds like additional evidence
    that we cannot rely on string literals with matching contents having
    the same address across TUs.<br>
    <br>
    The point regarding vague linkage still stands though; the example
    still fails the assertion if the inline function is modified to
    return the address of a static local variable.=C2=A0 The WP still
    requires static local variables in inline functions to be the same
    object across TUs (<a class=3D"moz-txt-link-freetext" href=3D"http://ee=
l.is/c++draft/dcl.inline">http://eel.is/c++draft/dcl.inline</a>)<br>
    <br>
    $ cat t.h<br>
    extern inline const char* f() {<br>
    =C2=A0 static char c =3D 't';<br>
    =C2=A0 return &amp;c;<br>
    }<br>
    <br>
    Tom.<br>
  </body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1bfc51e9-df00-696b-a6ed-6f2dedb5475e%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/1bfc51e9-df00-696b-a6ed-6f2dedb54=
75e%40honermann.net</a>.<br />

--------------8A6CA6B59FA68BA038E811A7--

.

------=_Part_6446_1737430314.1479502052265
Content-Type: multipart/alternative;
 boundary="----=_Part_6447_813059815.1479502052265"

------=_Part_6447_813059815.1479502052265
Content-Type: text/plain; charset=UTF-8



On Thursday, November 17, 2016 at 6:28:26 AM UTC+1, Louis Dionne wrote:
>
> Let me just expand a bit on what Matt said.
>
> I think this is a brilliant idea, but I don't think it's going to work,
> for the same reason
> as my P0424R0 paper was not warmly received. The reason is that
> implementers
> don't want anything that encourages the use of large template parameter
> lists,
> because the representation of that inside the compiler is too inefficient.
> They don't
> want a single template parameter per character in the string, because the
> structure
> that represents a template parameter in the compiler is expensive.
> Instead, they'd
> rather have a single structure that represents all the characters. I'm not
> sure why they
> can't just represent a character pack in a more efficient manner, but
> that's what I
> was told when I presented in EWG.
>
>
Fact that storing string in template parameters list is ineffective did not
stop GCC and Clang from implementing this:
https://godbolt.org/g/VjJzJi
https://godbolt.org/g/1DVftM
Thanks to that we can test how far we need push compilers to break when we
use this 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/35fe3945-71cf-4958-8f92-59df0ef98fae%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Thursday, November 17, 2016 at 6:28:26 AM UTC+1=
, Louis Dionne wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>Let me just expand a bit on what Matt said.</div><div><br></d=
iv><div>I think this is a brilliant idea, but I don&#39;t think it&#39;s go=
ing to work, for the same reason</div><div>as my P0424R0 paper was not warm=
ly received. The reason is that implementers</div><div>don&#39;t want anyth=
ing that encourages the use of large template parameter lists,</div><div>be=
cause the representation of that inside the compiler is too inefficient. Th=
ey don&#39;t</div><div>want a single template parameter per character in th=
e string, because the structure</div><div>that represents a template parame=
ter in the compiler is expensive. Instead, they&#39;d</div><div>rather have=
 a single structure that represents all the characters. I&#39;m not sure wh=
y they</div><div>can&#39;t just represent a character pack in a more effici=
ent manner, but that&#39;s what I</div><div>was told when I presented in EW=
G.</div><br></div></blockquote><div><br>Fact that storing string in templat=
e parameters list is ineffective did not stop GCC and Clang from implementi=
ng this:<br>https://godbolt.org/g/VjJzJi<br>https://godbolt.org/g/1DVftM<br=
>Thanks to that we can test how far we need push compilers to break when we=
 use this UDL.<br></div></div>

<p></p>

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

------=_Part_6447_813059815.1479502052265--

------=_Part_6446_1737430314.1479502052265--

.

------=_Part_6725_724601254.1479504711049
Content-Type: multipart/alternative;
 boundary="----=_Part_6726_1502113927.1479504711049"

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

On Friday, November 18, 2016 at 12:47:32 PM UTC-8, inkwizyt...@gmail.com=20
wrote:
>
> On Thursday, November 17, 2016 at 6:28:26 AM UTC+1, Louis Dionne wrote:
>>
>> Let me just expand a bit on what Matt said.
>>
>> I think this is a brilliant idea, but I don't think it's going to work,=
=20
>> for the same reason
>> as my P0424R0 paper was not warmly received. The reason is that=20
>> implementers
>> don't want anything that encourages the use of large template parameter=
=20
>> lists,
>> because the representation of that inside the compiler is too=20
>> inefficient. They don't
>> want a single template parameter per character in the string, because th=
e=20
>> structure
>> that represents a template parameter in the compiler is expensive.=20
>> Instead, they'd
>> rather have a single structure that represents all the characters. I'm=
=20
>> not sure why they
>> can't just represent a character pack in a more efficient manner, but=20
>> that's what I
>> was told when I presented in EWG.
>>
>
> Fact that storing string in template parameters list is ineffective did=
=20
> not stop GCC and Clang from implementing this:
> https://godbolt.org/g/VjJzJi
> https://godbolt.org/g/1DVftM
> Thanks to that we can test how far we need push compilers to break when w=
e=20
> use this UDL.
>

My uninformed opinion matches inkwizytor's.  Louis, I think you'll have to=
=20
be more specific when you claim that "implementors" find P0424R0=20
objectionable.  Given that two of the let's-say-four major vendors have=20
already managed to implement P0424R0, who could the holdouts be?=20
 Microsoft?  EDG?  Or GCC and/or Clang being like "We'll implement this,=20
but we'll grump about it"?

The situation seems analogous to std::make_integer_sequence<>, which I know=
=20
is near and dear to your heart: we've got implementations already in the=20
wild, and it's super useful for metaprogramming, but naive implementations=
=20
are (claimed to be) slow. So, why not apply the same solution, which was to=
=20
improve the compiler's internal mechanisms without compromising on the=20
source-level API?

[Admittedly I'm oversimplifying; the most obvious reason not to "improve"=
=20
the compiler mechanisms (e.g. by creating a special efficient=20
representation for template-argument-lists all of whose elements are=20
'char') is that it would add code and complexity (and cognitive overhead,=
=20
and test load, and bugs) to the compiler.]

Another idea to improve the shippability of P0424R0 would be to specify a=
=20
separate implementation-defined limit on the number of characters in a UDL=
=20
of this form; e.g., if some vendor wants to make it a hard error to use=20
string UDLs longer than 64 characters, I think that would be 100% fine with=
=20
today's working programmers, and the limit could easily be increased in=20
C++3x if there were a consensus among the vendors.

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

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/294698be-341d-4131-bfef-613076db9398%40isocpp.or=
g.

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

<div dir=3D"ltr">On Friday, November 18, 2016 at 12:47:32 PM UTC-8, inkwizy=
t...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Thursday, November 17, 2016 at 6:28:26 AM UTC+1, Louis Dionne w=
rote:<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>Let me j=
ust expand a bit on what Matt said.</div><div><br></div><div>I think this i=
s a brilliant idea, but I don&#39;t think it&#39;s going to work, for the s=
ame reason</div><div>as my P0424R0 paper was not warmly received. The reaso=
n is that implementers</div><div>don&#39;t want anything that encourages th=
e use of large template parameter lists,</div><div>because the representati=
on of that inside the compiler is too inefficient. They don&#39;t</div><div=
>want a single template parameter per character in the string, because the =
structure</div><div>that represents a template parameter in the compiler is=
 expensive. Instead, they&#39;d</div><div>rather have a single structure th=
at represents all the characters. I&#39;m not sure why they</div><div>can&#=
39;t just represent a character pack in a more efficient manner, but that&#=
39;s what I</div><div>was told when I presented in EWG.</div></div></blockq=
uote><div><br>Fact that storing string in template parameters list is ineff=
ective did not stop GCC and Clang from implementing this:<br><a href=3D"htt=
ps://godbolt.org/g/VjJzJi" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgodbolt.=
org%2Fg%2FVjJzJi\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEyCGEHR0GiZqVjb0An=
3WZXANd1uA&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.googl=
e.com/url?q\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2FVjJzJi\x26sa\x3dD\x26sntz\x3=
d1\x26usg\x3dAFQjCNEyCGEHR0GiZqVjb0An3WZXANd1uA&#39;;return true;">https://=
godbolt.org/g/VjJzJi</a><br><a href=3D"https://godbolt.org/g/1DVftM" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.go=
ogle.com/url?q\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2F1DVftM\x26sa\x3dD\x26sntz=
\x3d1\x26usg\x3dAFQjCNFqGgRvyhLZR0xEBFuRylEHu_fFbg&#39;;return true;" oncli=
ck=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgodbol=
t.org%2Fg%2F1DVftM\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFqGgRvyhLZR0xEBF=
uRylEHu_fFbg&#39;;return true;">https://godbolt.org/g/1DVftM</a><br>Thanks =
to that we can test how far we need push compilers to break when we use thi=
s UDL.<br></div></div></blockquote><div><br></div><div>My uninformed opinio=
n matches inkwizytor&#39;s. =C2=A0Louis, I think you&#39;ll have to be more=
 specific when you claim that &quot;implementors&quot; find P0424R0 objecti=
onable. =C2=A0Given that two of the let&#39;s-say-four major vendors have a=
lready managed to implement P0424R0, who could the holdouts be? =C2=A0Micro=
soft? =C2=A0EDG? =C2=A0Or GCC and/or Clang being like &quot;We&#39;ll imple=
ment this, but we&#39;ll grump about it&quot;?</div><div><br></div><div>The=
 situation seems analogous to std::make_integer_sequence&lt;&gt;, which I k=
now is near and dear to your heart: we&#39;ve got implementations already i=
n the wild, and it&#39;s super useful for metaprogramming, but naive implem=
entations are (claimed to be) slow. So, why not apply the same solution, wh=
ich was to improve the compiler&#39;s internal mechanisms without compromis=
ing on the source-level API?</div><div><br></div><div>[Admittedly I&#39;m o=
versimplifying; the most obvious reason not to &quot;improve&quot; the comp=
iler mechanisms (e.g. by creating a special efficient representation for te=
mplate-argument-lists all of whose elements are &#39;char&#39;) is that it =
would add code and complexity (and cognitive overhead, and test load, and b=
ugs) to the compiler.]</div><div><br></div><div>Another idea to improve the=
 shippability of P0424R0 would be to specify a separate implementation-defi=
ned limit on the number of characters in a UDL of this form; e.g., if some =
vendor wants to make it a hard error to use string UDLs longer than 64 char=
acters, I think that would be 100% fine with today&#39;s working programmer=
s, and the limit could easily be increased in C++3x if there were a consens=
us among the vendors.</div><div><br></div><div>my $.02,</div><div>=E2=80=93=
Arthur</div></div>

<p></p>

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

------=_Part_6726_1502113927.1479504711049--

------=_Part_6725_724601254.1479504711049--

.

This is a multi-part message in MIME format.
--------------8E17D3790B21A96AB15C4D24
Content-Type: text/plain; charset=UTF-8; format=flowed

On 11/18/2016 3:47 PM, inkwizytoryankes@gmail.com wrote:
>
>
> On Thursday, November 17, 2016 at 6:28:26 AM UTC+1, Louis Dionne wrote:
>
>     Let me just expand a bit on what Matt said.
>
>     I think this is a brilliant idea, but I don't think it's going to
>     work, for the same reason
>     as my P0424R0 paper was not warmly received. The reason is that
>     implementers
>     don't want anything that encourages the use of large template
>     parameter lists,
>     because the representation of that inside the compiler is too
>     inefficient. They don't
>     want a single template parameter per character in the string,
>     because the structure
>     that represents a template parameter in the compiler is expensive.
>     Instead, they'd
>     rather have a single structure that represents all the characters.
>     I'm not sure why they
>     can't just represent a character pack in a more efficient manner,
>     but that's what I
>     was told when I presented in EWG.
>
>
> Fact that storing string in template parameters list is ineffective
> did not stop GCC and Clang from implementing this:
> https://godbolt.org/g/VjJzJi
> https://godbolt.org/g/1DVftM
> Thanks to that we can test how far we need push compilers to break
> when we use this UDL.

I'd still prefer to be able to do something like this:

template<std::size_t N>
constexpr X operator""_udl(const char (&sl)[N]) { ... }

Tom.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a0d1a03d-d330-eb1b-13b1-0d241107c8b4%40honermann.net.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 11/18/2016 3:47 PM,
      <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:inkwizytoryankes=
@gmail.com">inkwizytoryankes@gmail.com</a> wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:35fe3945-71cf-4958-8f92-59df0ef98fae@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        <br>
        On Thursday, November 17, 2016 at 6:28:26 AM UTC+1, Louis Dionne
        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">
            <div>Let me just expand a bit on what Matt said.</div>
            <div><br>
            </div>
            <div>I think this is a brilliant idea, but I don't think
              it's going to work, for the same reason</div>
            <div>as my P0424R0 paper was not warmly received. The reason
              is that implementers</div>
            <div>don't want anything that encourages the use of large
              template parameter lists,</div>
            <div>because the representation of that inside the compiler
              is too inefficient. They don't</div>
            <div>want a single template parameter per character in the
              string, because the structure</div>
            <div>that represents a template parameter in the compiler is
              expensive. Instead, they'd</div>
            <div>rather have a single structure that represents all the
              characters. I'm not sure why they</div>
            <div>can't just represent a character pack in a more
              efficient manner, but that's what I</div>
            <div>was told when I presented in EWG.</div>
            <br>
          </div>
        </blockquote>
        <div><br>
          Fact that storing string in template parameters list is
          ineffective did not stop GCC and Clang from implementing this:<br=
>
          <a class=3D"moz-txt-link-freetext" href=3D"https://godbolt.org/g/=
VjJzJi">https://godbolt.org/g/VjJzJi</a><br>
          <a class=3D"moz-txt-link-freetext" href=3D"https://godbolt.org/g/=
1DVftM">https://godbolt.org/g/1DVftM</a><br>
          Thanks to that we can test how far we need push compilers to
          break when we use this UDL.</div>
      </div>
    </blockquote>
    <br>
    I'd still prefer to be able to do something like this:<br>
    <br>
    template&lt;std::size_t N&gt;<br>
    constexpr X operator""_udl(const char (&amp;sl)[N]) { ... }<br>
    <br>
    Tom.<br>
  </body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a0d1a03d-d330-eb1b-13b1-0d241107c8b4%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/a0d1a03d-d330-eb1b-13b1-0d241107c=
8b4%40honermann.net</a>.<br />

--------------8E17D3790B21A96AB15C4D24--

.

This is a multi-part message in MIME format.
--------------997E246E3BA216A8AEFB6EE7
Content-Type: text/plain; charset=UTF-8; format=flowed

On 11/18/2016 4:42 PM, Tom Honermann wrote:
> On 11/18/2016 3:47 PM, inkwizytoryankes@gmail.com wrote:
>>
>>
>> On Thursday, November 17, 2016 at 6:28:26 AM UTC+1, Louis Dionne wrote:
>>
>>     Let me just expand a bit on what Matt said.
>>
>>     I think this is a brilliant idea, but I don't think it's going to
>>     work, for the same reason
>>     as my P0424R0 paper was not warmly received. The reason is that
>>     implementers
>>     don't want anything that encourages the use of large template
>>     parameter lists,
>>     because the representation of that inside the compiler is too
>>     inefficient. They don't
>>     want a single template parameter per character in the string,
>>     because the structure
>>     that represents a template parameter in the compiler is
>>     expensive. Instead, they'd
>>     rather have a single structure that represents all the
>>     characters. I'm not sure why they
>>     can't just represent a character pack in a more efficient manner,
>>     but that's what I
>>     was told when I presented in EWG.
>>
>>
>> Fact that storing string in template parameters list is ineffective
>> did not stop GCC and Clang from implementing this:
>> https://godbolt.org/g/VjJzJi
>> https://godbolt.org/g/1DVftM
>> Thanks to that we can test how far we need push compilers to break
>> when we use this UDL.
>
> I'd still prefer to be able to do something like this:
>
> template<std::size_t N>
> constexpr X operator""_udl(const char (&sl)[N]) { ... }

Of course, that doesn't provide the string-literal -> unique type
mapping (based on string literal contents) that would be desired for at
least some use cases.

Tom.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/12f71e8a-b31f-4c68-be93-d4a513459daf%40honermann.net.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 11/18/2016 4:42 PM, Tom Honermann
      wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:a0d1a03d-d330-eb1b-13b1-0d241107c8b4@honermann.net"
      type=3D"cite">
      <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty=
pe">
      <div class=3D"moz-cite-prefix">On 11/18/2016 3:47 PM, <a
          moz-do-not-send=3D"true" class=3D"moz-txt-link-abbreviated"
          href=3D"mailto:inkwizytoryankes@gmail.com">inkwizytoryankes@gmail=
..com</a>
        wrote:<br>
      </div>
      <blockquote
        cite=3D"mid:35fe3945-71cf-4958-8f92-59df0ef98fae@isocpp.org"
        type=3D"cite">
        <div dir=3D"ltr"><br>
          <br>
          On Thursday, November 17, 2016 at 6:28:26 AM UTC+1, Louis
          Dionne 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">
              <div>Let me just expand a bit on what Matt said.</div>
              <div><br>
              </div>
              <div>I think this is a brilliant idea, but I don't think
                it's going to work, for the same reason</div>
              <div>as my P0424R0 paper was not warmly received. The
                reason is that implementers</div>
              <div>don't want anything that encourages the use of large
                template parameter lists,</div>
              <div>because the representation of that inside the
                compiler is too inefficient. They don't</div>
              <div>want a single template parameter per character in the
                string, because the structure</div>
              <div>that represents a template parameter in the compiler
                is expensive. Instead, they'd</div>
              <div>rather have a single structure that represents all
                the characters. I'm not sure why they</div>
              <div>can't just represent a character pack in a more
                efficient manner, but that's what I</div>
              <div>was told when I presented in EWG.</div>
              <br>
            </div>
          </blockquote>
          <div><br>
            Fact that storing string in template parameters list is
            ineffective did not stop GCC and Clang from implementing
            this:<br>
            <a moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext"
              href=3D"https://godbolt.org/g/VjJzJi">https://godbolt.org/g/V=
jJzJi</a><br>
            <a moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext"
              href=3D"https://godbolt.org/g/1DVftM">https://godbolt.org/g/1=
DVftM</a><br>
            Thanks to that we can test how far we need push compilers to
            break when we use this UDL.</div>
        </div>
      </blockquote>
      <br>
      I'd still prefer to be able to do something like this:<br>
      <br>
      template&lt;std::size_t N&gt;<br>
      constexpr X operator""_udl(const char (&amp;sl)[N]) { ... }</blockquo=
te>
    <br>
    Of course, that doesn't provide the string-literal -&gt; unique type
    mapping (based on string literal contents) that would be desired for
    at least some use cases.<br>
    <br>
    Tom.<br>
  </body>
</html>

<p></p>

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

--------------997E246E3BA216A8AEFB6EE7--

.