Topic: Comments on n4171: extended placeholders


Author: germandiago@gmail.com
Date: Thu, 9 Oct 2014 01:13:11 -0700 (PDT)
Raw View
------=_Part_486_1059125838.1412842391150
Content-Type: text/plain; charset=UTF-8

Hello everyone,


I have been taking a look at this:

https://isocpp.org/files/papers/n4171.html


It looks ok and as a great addition to me, but I wonder if this is the best
way to add this feature given the current language feature set
and future extensions.

Particularly, what would be the advantages/disadvantages of adding
placeholders as a user-defined literal operator?
If we could have compile-time <char...> for udls, maybe a more general
syntax could be added instead of adding variables
or types to the namespace:

"1"ph -> first placeholder
"2-5"ph -> second to 5th
"1-"ph  -> first to last
"1-10"ph -> first to tenth

I think this could be also used to generate placeholders for other cases,
but I am not sure about the advantages/disadvantages
of this approach compared to the proposal.

Just my two cents.












"1-5"ph <--

--

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

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

<div dir=3D"ltr">Hello everyone,<div><br></div><div><br></div><div>I have b=
een taking a look at this:</div><div><br></div><div>https://isocpp.org/file=
s/papers/n4171.html<br></div><div><br></div><div><br></div><div>It looks ok=
 and as a great addition to me, but I wonder if this is the best way to add=
 this feature given the current language feature set</div><div>and future e=
xtensions.</div><div><br></div><div>Particularly, what would be the advanta=
ges/disadvantages of adding placeholders as a user-defined literal operator=
?</div><div>If we could have compile-time &lt;char...&gt; for udls, maybe a=
 more general syntax could be added instead of adding variables</div><div>o=
r types to the namespace:</div><div><br></div><div>"1"ph -&gt; first placeh=
older</div><div>"2-5"ph -&gt; second to 5th</div><div>"1-"ph &nbsp;-&gt; fi=
rst to last</div><div>"1-10"ph -&gt; first to tenth</div><div><br></div><di=
v>I think this could be also used to generate placeholders for other cases,=
 but I am not sure about the advantages/disadvantages</div><div>of this app=
roach compared to the proposal.</div><div><br></div><div>Just my two cents.=
</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br>=
</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br>=
</div><div><br></div><div><br></div><div>"1-5"ph &lt;--</div></div>

<p></p>

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

------=_Part_486_1059125838.1412842391150--

.


Author: Tomasz <tomaszkam@gmail.com>
Date: Fri, 10 Oct 2014 09:56:18 -0700 (PDT)
Raw View
------=_Part_604_777913657.1412960178454
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu czwartek, 9 pa=C5=BAdziernika 2014 10:13:11 UTC+2 u=C5=BCytkownik Ge=
rm=C3=A1n Diago=20
napisa=C5=82:
>
> Hello everyone,
>
>
> I have been taking a look at this:
>
> https://isocpp.org/files/papers/n4171.html
>
>
> It looks ok and as a great addition to me, but I wonder if this is the=20
> best way to add this feature given the current language feature set
> and future extensions.
>
Currently language already has a special namespace for the placeholder=20
definitions that are used within bind, so I think that every placeholder=20
that is added to the language should have a corresponding definition added=
=20
into this namespace.


> Particularly, what would be the advantages/disadvantages of adding=20
> placeholders as a user-defined literal operator?
> If we could have compile-time <char...> for udls, maybe a more general=20
> syntax could be added instead of adding variables
> or types to the namespace:
>
> "1"ph -> first placeholder
> "2-5"ph -> second to 5th
> "1-"ph  -> first to last
> "1-10"ph -> first to tenth
>
> I think this could be also used to generate placeholders for other cases,=
=20
> but I am not sure about the advantages/disadvantages
> of this approach compared to the proposal.
>

I personally do not see any advantages of having placeholder defined using=
=20
literal operator versus defining them in appropriate nested namespace. I=20
personally use a using directive for std::placeholder at function level=20
when I am using bind:
{
  using namespace std::placeholders;
  std::bind(f{}, _1, _2);
}
The one advantage of having placeholder defined at the variable template=20
(as in my proposal) is that you can use a compile time constant to compute=
=20
as index of the arguments. If the approach with user-defined literals are=
=20
selected (even current _1, _2 placeholder) creating a placeholder form the=
=20
constexpr integral value is cumbersome:
template<int N>
struct placeholder_for_index;

template<>
struct placeholder_for_index<1>
{
   static auto get() { return _1; /* or "1"ph */; }
} //and additional specialization for "N"ph, "N-K"ph, "N-"ph and so one.=20
While with variable template approach I can simply say _at<N>.

I perceive literals operators for the bind placeholder as orthogonal to my=
=20
group placeholder and think they may be discussed separately (we still need=
=20
a template variable version). Anyway, if you feel that having such=20
extension would be usefull in general, go ahead and write paper about the=
=20
idea (link=20
<https://groups.google.com/a/isocpp.org/forum/?fromgroups=3D#!topic/std-pro=
posals/MEoBsfFK9JI>=20
to previous topic about it). I personally do not see any reasons to have=20
another syntax for defining placeholders, because I have no problems with=
=20
using current one, so have no interest in writing such paper.=20

--=20

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

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

<div dir=3D"ltr"><br><br>W dniu czwartek, 9 pa=C5=BAdziernika 2014 10:13:11=
 UTC+2 u=C5=BCytkownik Germ=C3=A1n Diago napisa=C5=82:<blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr">Hello everyone,<div><br></div><div=
><br></div><div>I have been taking a look at this:</div><div><br></div><div=
><a href=3D"https://isocpp.org/files/papers/n4171.html" target=3D"_blank" o=
nmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fiso=
cpp.org%2Ffiles%2Fpapers%2Fn4171.html\46sa\75D\46sntz\0751\46usg\75AFQjCNEk=
rogM9Un39T9X7NMA30V99bxW_g';return true;" onclick=3D"this.href=3D'https://w=
ww.google.com/url?q\75https%3A%2F%2Fisocpp.org%2Ffiles%2Fpapers%2Fn4171.htm=
l\46sa\75D\46sntz\0751\46usg\75AFQjCNEkrogM9Un39T9X7NMA30V99bxW_g';return t=
rue;">https://isocpp.org/files/<wbr>papers/n4171.html</a><br></div><div><br=
></div><div><br></div><div>It looks ok and as a great addition to me, but I=
 wonder if this is the best way to add this feature given the current langu=
age feature set</div><div>and future extensions.</div></div></blockquote><d=
iv>Currently language already has a special namespace for the placeholder d=
efinitions that are used within bind, so I think that every placeholder tha=
t is added to the language should have a corresponding definition added int=
o this namespace.<br><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div><br></div><div>Particularly, what would be the advan=
tages/disadvantages of adding placeholders as a user-defined literal operat=
or?</div><div>If we could have compile-time &lt;char...&gt; for udls, maybe=
 a more general syntax could be added instead of adding variables</div><div=
>or types to the namespace:</div><div><br></div><div>"1"ph -&gt; first plac=
eholder</div><div>"2-5"ph -&gt; second to 5th</div><div>"1-"ph &nbsp;-&gt; =
first to last</div><div>"1-10"ph -&gt; first to tenth</div><div><br></div><=
div>I think this could be also used to generate placeholders for other case=
s, but I am not sure about the advantages/disadvantages</div><div>of this a=
pproach compared to the proposal.</div></div></blockquote><div dir=3D"ltr">=
<br>I personally do not see any advantages of having placeholder defined us=
ing literal operator versus defining them in appropriate nested namespace. =
I personally use a using directive for std::placeholder at function level w=
hen I am using bind:<br>{<br>&nbsp; using namespace std::placeholders;<br>&=
nbsp; std::bind(f{}, _1, _2);<br>}<br>The one advantage of having placehold=
er defined at the variable template (as in my proposal) is that you can use=
 a compile time constant to compute as index of the arguments. If the appro=
ach with user-defined literals are selected (even current _1, _2 placeholde=
r) creating a placeholder form the constexpr integral value is cumbersome:<=
br>template&lt;int N&gt;<br>struct placeholder_for_index;<br><br>template&l=
t;&gt;<br>struct placeholder_for_index&lt;1&gt;<br>{<br>&nbsp;&nbsp; static=
 auto get() { return _1; /* or "1"ph */; }<br>} //and additional specializa=
tion for "N"ph, "N-K"ph, "N-"ph and so one. <br>While with variable templat=
e approach I can simply say _at&lt;N&gt;.<br><br>I perceive literals operat=
ors for the bind placeholder as orthogonal to my group placeholder and thin=
k they may be discussed separately (we still need a template variable versi=
on). Anyway, if you feel that having such extension would be usefull in gen=
eral, go ahead and write paper about the idea (<a href=3D"https://groups.go=
ogle.com/a/isocpp.org/forum/?fromgroups=3D#!topic/std-proposals/MEoBsfFK9JI=
">link</a> to previous topic about it). I personally do not see any reasons=
 to have another syntax for defining=20
placeholders, because I have no problems with using current one, so have no=
=20
interest in writing such paper. <br><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"></blockquote></div>

<p></p>

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

------=_Part_604_777913657.1412960178454--

.


Author: german.gomez@personifyinc.com
Date: Mon, 13 Oct 2014 00:42:08 -0700 (PDT)
Raw View
------=_Part_2958_423691474.1413186128313
Content-Type: text/plain; charset=UTF-8


>
>
> I perceive literals operators for the bind placeholder as orthogonal to my
> group placeholder and think they may be discussed separately (we still need
> a template variable version). Anyway, if you feel that having such
> extension would be usefull in general, go ahead and write paper about the
> idea (link
> <https://groups.google.com/a/isocpp.org/forum/?fromgroups=#!topic/std-proposals/MEoBsfFK9JI>
> to previous topic about it). I personally do not see any reasons to have
> another syntax for defining placeholders, because I have no problems with
> using current one, so have no interest in writing such paper.
>
>
Well, I think the way you propose is more than good and very useful
already. This was more of a question or make others think about it than a
deep critic to the syntax,
which is more than good enough.

What I really considered maybe improvable are two things actually, but I
didn't give a long thought or experimentally tried:

1. With generated udl placeholders, we can achieve more general syntax: no
need for _from, _upto, etc. Just number placeholders, namely, ranges, in
the sense of mathematical ranges, not STL ranges.
2. It does not need to add a type/template for each placeholder to a
namespace.

1. gives you a general, single-way, to learn the syntax, instead of having
to learn all the placeholders, which are not many anyway, at this point.
2. No need to write boilerplate, no namespace pollution (though this is not
a big problem, since it is already scoped), no need to open/close a
namespace.

Well, I don't have enough interest at this point to write a paper. I don't
even know if I would dare, no experience yet :D Just my two cents.
Thanks for your feedback.

--

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

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div dir=3D"ltr"><br>I perceive literals operators for the bind placeho=
lder as orthogonal to my group placeholder and think they may be discussed =
separately (we still need a template variable version). Anyway, if you feel=
 that having such extension would be usefull in general, go ahead and write=
 paper about the idea (<a href=3D"https://groups.google.com/a/isocpp.org/fo=
rum/?fromgroups=3D#!topic/std-proposals/MEoBsfFK9JI" target=3D"_blank" onmo=
usedown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/forum/?fromg=
roups\75#!topic/std-proposals/MEoBsfFK9JI';return true;" onclick=3D"this.hr=
ef=3D'https://groups.google.com/a/isocpp.org/forum/?fromgroups\75#!topic/st=
d-proposals/MEoBsfFK9JI';return true;">link</a> to previous topic about it)=
.. I personally do not see any reasons to have another syntax for defining=
=20
placeholders, because I have no problems with using current one, so have no=
=20
interest in writing such paper. <br><br></div></div></blockquote><div><br><=
/div><div>Well, I think the way you propose is more than good and very usef=
ul already. This was more of a question or make others think about it than =
a deep critic to the syntax,</div><div>which is more than good enough.</div=
><div><br></div><div>What I really considered maybe improvable are two thin=
gs actually, but I didn't give a long thought or experimentally tried:</div=
><div><br></div><div>1. With generated udl placeholders, we can achieve mor=
e general syntax: no need for _from, _upto, etc. Just number placeholders, =
namely, ranges, in the sense of mathematical ranges, not STL ranges.</div><=
div>2. It does not need to add a type/template for each placeholder to a na=
mespace.</div><div><br></div><div>1. gives you a general, single-way, to le=
arn the syntax, instead of having to learn all the placeholders, which are =
not many anyway, at this point.</div><div>2. No need to write boilerplate, =
no namespace pollution (though this is not a big problem, since it is alrea=
dy scoped), no need to open/close a namespace.</div><div><br></div><div>Wel=
l, I don't have enough interest at this point to write a paper. I don't eve=
n know if I would dare, no experience yet :D Just my two cents.</div><div>T=
hanks for your feedback.</div><div><br></div></div>

<p></p>

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

------=_Part_2958_423691474.1413186128313--

.


Author: =?UTF-8?Q?Tomasz_Kami=C5=84ski?= <tomaszkam@gmail.com>
Date: Mon, 13 Oct 2014 10:16:31 +0200
Raw View
--001a113c1a0c2f0c8e050549845e
Content-Type: text/plain; charset=UTF-8

2014-10-13 9:42 GMT+02:00 <german.gomez@personifyinc.com>:

>
>> I perceive literals operators for the bind placeholder as orthogonal to
>> my group placeholder and think they may be discussed separately (we still
>> need a template variable version). Anyway, if you feel that having such
>> extension would be usefull in general, go ahead and write paper about the
>> idea (link
>> <https://groups.google.com/a/isocpp.org/forum/?fromgroups=#!topic/std-proposals/MEoBsfFK9JI>
>> to previous topic about it). I personally do not see any reasons to have
>> another syntax for defining placeholders, because I have no problems with
>> using current one, so have no interest in writing such paper.
>>
>>
> Well, I think the way you propose is more than good and very useful
> already. This was more of a question or make others think about it than a
> deep critic to the syntax,
> which is more than good enough.
>
I am not fan of adding placeholders for everything into language,
especially ones that return different type for different value (1ph and Nph
must create a different type, because the meaning of placeholder is
resolved at compile time).

>
> What I really considered maybe improvable are two things actually, but I
> didn't give a long thought or experimentally tried:
>


> 1. With generated udl placeholders, we can achieve more general syntax: no
> need for _from, _upto, etc. Just number placeholders, namely, ranges, in
> the sense of mathematical ranges, not STL ranges.
>
But this would mean parsing of string at compile time, because different
ranges must define different types, and:

 1. We do not have ability to parse string literals at compile time
(although it is proposed)

 2. This will cause a compiler error from string parsing being generated in
addition to existing barely understandable outputs.

 3. Increase compile time because of parsing of strings.


2. It does not need to add a type/template for each placeholder to a
> namespace.
>
It adds, because some type must still be returned from udl operator, just
this type would not be specified in standard, but must still be defined by
implementation and being visible in the point of use of bind.


> 1. gives you a general, single-way, to learn the syntax, instead of having
> to learn all the placeholders, which are not many anyway, at this point.
>
For me the 1ph, "-5ph", "1-"ph, "1-10"ph are tree different syntaxes, same
as for _at, _to, _from and _between.

2. No need to write boilerplate, no namespace pollution (though this is not
> a big problem, since it is already scoped), no need to open/close a
> namespace.
>
As, I this typs must be defined somewhere so namespace still we be
polluted. And for the user defined literals you will still need to have
using directive for std::literals::placeholder_literals at some point (as
std::placeholders for current placeholders).

>
> Well, I don't have enough interest at this point to write a paper. I don't
> even know if I would dare, no experience yet :D Just my two cents.
>
This is just my third paper. It is harder to make one than I tought it
would be, but nothing imposible for mere programer. My only advice would be
to start small.


Thanks for your feedback.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/ll1K71wI2KM/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2014-10-13 9:42 GMT+02:00  <span dir=3D"ltr">&lt;<a href=3D"mailto:germ=
an.gomez@personifyinc.com" target=3D"_blank">german.gomez@personifyinc.com<=
/a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr"><span class=3D""><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr"><div dir=3D"ltr"><br>I perceive literals operators for =
the bind placeholder as orthogonal to my group placeholder and think they m=
ay be discussed separately (we still need a template variable version). Any=
way, if you feel that having such extension would be usefull in general, go=
 ahead and write paper about the idea (<a href=3D"https://groups.google.com=
/a/isocpp.org/forum/?fromgroups=3D#!topic/std-proposals/MEoBsfFK9JI" target=
=3D"_blank">link</a> to previous topic about it). I personally do not see a=
ny reasons to have another syntax for defining=20
placeholders, because I have no problems with using current one, so have no=
=20
interest in writing such paper. <br><br></div></div></blockquote><div><br><=
/div></span><div>Well, I think the way you propose is more than good and ve=
ry useful already. This was more of a question or make others think about i=
t than a deep critic to the syntax,</div><div>which is more than good enoug=
h.</div></div></blockquote><div>

<p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt;line-height:normal">=
<span style=3D"font-size:12pt;font-family:&quot;Times New Roman&quot;,&quot=
;serif&quot;">I am not fan of adding placeholders
for everything into language, especially ones that return different type fo=
r
different value (1ph and Nph must create a different type, because the mean=
ing
of placeholder is resolved at compile time). </span></p>

</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv><br></div><div>What I really considered maybe improvable are two things =
actually, but I didn&#39;t give a long thought or experimentally tried:</di=
v></div></blockquote><div><br></div><blockquote 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"><div><br></div><div>1. With generated udl place=
holders, we can achieve more general syntax: no need for _from, _upto, etc.=
 Just number placeholders, namely, ranges, in the sense of mathematical ran=
ges, not STL ranges.</div></div></blockquote>

<p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt;line-height:normal">=
<span style=3D"font-size:12pt;font-family:&quot;Times New Roman&quot;,&quot=
;serif&quot;">But this would mean parsing of
string at compile time, because different ranges must define different type=
s, and:<br></span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt;line-height:normal">=
<span style=3D"font-size:12pt;font-family:&quot;Times New Roman&quot;,&quot=
;serif&quot;">=C2=A01. We do not have ability to
parse string literals at compile time (although it is proposed)</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt;line-height:normal">=
<span style=3D"font-size:12pt;font-family:&quot;Times New Roman&quot;,&quot=
;serif&quot;">=C2=A02. This will cause a compiler
error from string parsing being generated in addition to existing barely
understandable outputs.</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt;line-height:normal">=
<span style=3D"font-size:12pt;font-family:&quot;Times New Roman&quot;,&quot=
;serif&quot;">=C2=A03. Increase compile time
because of parsing of strings.</span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt;line-height:normal">=
<span style=3D"font-size:12pt;font-family:&quot;Times New Roman&quot;,&quot=
;serif&quot;"></span></p>

<p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt;line-height:normal">=
<span style=3D"font-size:12pt;font-family:&quot;Times New Roman&quot;,&quot=
;serif&quot;"><br></span></p>

<blockquote 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"><div>2. =
It does not need to add a type/template for each placeholder to a namespace=
..</div></div></blockquote><div>

<p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt;line-height:normal">=
<span style=3D"font-size:12pt;font-family:&quot;Times New Roman&quot;,&quot=
;serif&quot;">It adds, because some type must
still be returned from udl operator, just this type would not be specified =
in
standard, but must still be defined by implementation and being visible in =
the point
of use of bind.</span></p>

<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr=
"><div><br></div><div>1. gives you a general, single-way, to learn the synt=
ax, instead of having to learn all the placeholders, which are not many any=
way, at this point.</div></div></blockquote><div><span style=3D"font-size:1=
1pt;line-height:115%;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=
">For
me the 1ph, &quot;-5ph&quot;, &quot;1-&quot;ph, &quot;1-10&quot;ph are tree
different syntaxes, same as for _at, _to, _from and _between.</span><span s=
tyle=3D"font-size:12pt;line-height:115%;font-family:&quot;Times New Roman&q=
uot;,&quot;serif&quot;"></span><br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><div dir=3D"ltr"><div>2. No need to write boilerplate, =
no namespace pollution (though this is not a big problem, since it is alrea=
dy scoped), no need to open/close a namespace.</div></div></blockquote><div=
>

<p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt;line-height:normal">=
<span style=3D"font-size:12pt;font-family:&quot;Times New Roman&quot;,&quot=
;serif&quot;">As, I this typs must be defined
somewhere so namespace still we be polluted. And for the user defined liter=
als
you will still need to have using directive for
std::literals::placeholder_literals at some point (as std::placeholders for
current placeholders).</span></p>

</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv><br></div><div>Well, I don&#39;t have enough interest at this point to w=
rite a paper. I don&#39;t even know if I would dare, no experience yet :D J=
ust my two cents.</div></div></blockquote><div>

<p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt;line-height:normal">=
<span style=3D"font-size:12pt;font-family:&quot;Times New Roman&quot;,&quot=
;serif&quot;">This is just my third paper. It is
harder to make one than I tought it would be, but nothing imposible for mer=
e
programer. My only advice would be to start small.</span></p><p class=3D"Ms=
oNormal" style=3D"margin-bottom:0.0001pt;line-height:normal"><span style=3D=
"font-size:12pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;">=
<br></span></p>

</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv>Thanks for your feedback.</div><div><br></div></div><div class=3D""><div=
 class=3D"h5">



-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/ll1K71wI2KM/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/ll1K71wI2KM=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

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

--001a113c1a0c2f0c8e050549845e--

.