------=_Part_1035_1092255074.1492977288738
Content-Type: multipart/alternative;
 boundary="----=_Part_1036_1097958390.1492977288739"

------=_Part_1036_1097958390.1492977288739
Content-Type: text/plain; charset=UTF-8

Hello,

This is my first post to this, um, list/group, so please indulge any
flagrant ignorance.

When writing templated code, we often find ourselves writing multiple
consecutive functions with identical template parameters. (As an example,
we can have a look at, say, libstdc++'s bits/stl_algo.h ;  or just any
templated class with multiple methods implemented outside of the class
definition).

For a long while now I've been wondering why it is that we have to do so,
i.e. write code such as

template <typename T> void foo();
template <typename T> void bar();

rather than

template <typename T> {
    void foo();
    void bar();
}

?

To clarify, I mean having the latter as merely a syntactic-sugar-equivalent
to the former, without intricating the two definitions/declarations in any
way. Now, of course when you put things together visually you're implying
they're somehow related, but that would only be a stylistic nuance, and -
as far as I can tell - should not influence anything beyond parsing.

The thing is, that seems a relatively obvious and intuitive idea - so
somebody must have proposed  it, or something similar, already. Searching
this group's archives I found this post:
https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/template$20scope/std-proposals/ficfBQIgR4c/FRPjJ1QFcjoJ
part of which is very similar to what I suggest, except for involving
namespaces and/or class method implementations specifically - which might
be interesting but also problematic (increasing the cost side of a
cost/benefit view). My thought was about the absolute-minimum-cost
suggestion. That thread did not end in any conclusive way, nor in
references to past discussions.

So, my questions to the group:

   - Has this been more extensively/seriously proposed and discussed before?
   - If so, can you refer me to the text of such discussions or decisions?
   - If not, would this have some obvious downside/cost which I'm missing?
   - Ville Voutilainen mentioned, on that thread, a much more far-reaching
   idea, of having a "with foo bar" construct in C++; I would also be
   interested in the history of that (perhaps for inspiration regarding my
   simpler idea)

Respectfully,

Eyal Rozenberg

--
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/0f4715ef-223b-4d28-8381-d7a43b93d792%40isocpp.org.

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

<div dir=3D"ltr">Hello,<br><br>This is my first post to this, um, list/grou=
p, so please indulge any flagrant ignorance.<br><br>When writing templated =
code, we often find ourselves writing multiple consecutive functions with i=
dentical template parameters. (As an example, we can have a look at, say, l=
ibstdc++&#39;s bits/stl_algo.h ;=C2=A0 or just any templated class with mul=
tiple methods implemented outside of the class definition).<br><br>For a lo=
ng while now I&#39;ve been wondering why it is that we have to do so, i.e. =
write code such as<br><br><div style=3D"background-color: rgb(250, 250, 250=
); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px=
; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettypr=
int"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">template</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>typename</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #00=
0;" 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"st=
yled-by-prettify">template</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>typename</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> bar</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">()</span><code class=3D"prettyprin=
t"><span style=3D"color: #000;" class=3D"styled-by-prettify">;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></code><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"></span></div></code></=
div><br>rather than<br><br><div style=3D"background-color: rgb(250, 250, 25=
0); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1p=
x; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">template</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">typename</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{</span><br><div style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
 border-style: solid; border-width: 1px; overflow-wrap: break-word;" class=
=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #008;" class=3D"styled-by-prettify">=C2=A0=C2=A0=C2=
=A0 </span><span style=3D"color: #000;" class=3D"styled-by-prettify"></span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">=C2=A0=C2=A0=C2=A0 void</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> bar</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">()</span><code class=3D"prettyprin=
t"><span style=3D"color: #000;" class=3D"styled-by-prettify">;</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify"></span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"></span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>}<br></span></code><span style=3D"color=
: #000;" class=3D"styled-by-prettify"></span></div></code></div></div></cod=
e></div><br>? <br><br>To clarify, I mean having the latter as merely a synt=
actic-sugar-equivalent to the former, without intricating the two definitio=
ns/declarations in any way. Now, of course when you put things together vis=
ually you&#39;re implying they&#39;re somehow related, but that would only =
be a stylistic nuance, and - as far as I can tell - should not influence an=
ything beyond parsing.<br><br>The thing is, that seems a relatively obvious=
 and intuitive idea - so somebody must have proposed=C2=A0 it, or something=
 similar, already. Searching this group&#39;s archives I found this post:<b=
r>https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/tem=
plate$20scope/std-proposals/ficfBQIgR4c/FRPjJ1QFcjoJ<br>part of which is ve=
ry similar to what I suggest, except for involving namespaces and/or class =
method implementations specifically - which might be interesting but also p=
roblematic (increasing the cost side of a cost/benefit view). My thought wa=
s about the absolute-minimum-cost suggestion. That thread did not end in an=
y conclusive way, nor in references to past discussions.<br><br>So, my ques=
tions to the group:<br><ul><li>Has this been more extensively/seriously pro=
posed and discussed before?</li><li>If so, can you refer me to the text of =
such discussions or decisions?</li><li>If not, would this have some obvious=
 downside/cost which I&#39;m missing?</li><li><span class=3D"_username"><sp=
an class=3D"IVILX2C-D-a" style=3D"color: rgb(34, 34, 34);">Ville Voutilaine=
n mentioned, on that thread, a much more far-reaching idea, of having a &qu=
ot;with foo bar&quot; construct in C++; I would also be interested in the h=
istory of that (perhaps for inspiration regarding my simpler idea)</span></=
span></li></ul><p>Respectfully,</p><p>Eyal Rozenberg</p></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/0f4715ef-223b-4d28-8381-d7a43b93d792%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0f4715ef-223b-4d28-8381-d7a43b93d792=
%40isocpp.org</a>.<br />

------=_Part_1036_1097958390.1492977288739--

------=_Part_1035_1092255074.1492977288738--

.

On 04/23/2017 09:54 PM, eyalroz@technion.ac.il wrote:
> template<typenameT> {
>     void foo();
>     void bar();
> }

Looks like a reasonable proposal to me.  I'm not aware of recent
discussions on a proposal similar to this, but Ville knows a lot
more about that.

The proposal needs to be clarified regarding nesting:

template<class T>
template<class U> {
  void f();
}

and

template<class T> {
  template<class U> {
    void f();
  }
  void g();
}


(Two levels of template headers; are both options allowed?)

Jens

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

.

>=20
> On 24 Apr 2017, at 03:54, eyalroz@technion.ac.il wrote:
>=20
> Hello,
>=20
> This is my first post to this, um, list/group, so please indulge any flag=
rant ignorance.
>=20
> When writing templated code, we often find ourselves writing multiple con=
secutive functions with identical template parameters. (As an example, we c=
an have a look at, say, libstdc++'s bits/stl_algo.h ;  or just any template=
d class with multiple methods implemented outside of the class definition).

Defining members of a template class outside the class is a pain..

>=20
> For a long while now I've been wondering why it is that we have to do so,=
 i.e. write code such as
>=20
> template <typename T> void foo();
> template <typename T> void bar();

Since for the above declarations, 'T' for 'foo' and 'bar' are not required =
to be the same (since they can't be related anyway),

> rather than
>=20
> template <typename T> {
>     void foo();
>     void bar();
> }
>=20
> ?=20

neither should the 'T' here be..

And that makes confusion. At the first sight, 'foo' and 'bar' seems to shar=
e a same 'T' somehow, just as what we have 'T' for (member functions of) cl=
ass templates today.

> To clarify, I mean having the latter as merely a syntactic-sugar-equivale=
nt to the former, without intricating the two definitions/declarations in a=
ny way. Now, of course when you put things together visually you're implyin=
g they're somehow related, but that would only be a stylistic nuance, and -=
 as far as I can tell - should not influence anything beyond parsing.

And that's not what we should do from the design perspective IMHO.=20
Grouping things that are not logically related together makes the code hard=
 to maintain. Think about the efforts needed to add another template argume=
nt for one of the functions in the 'template <typename T> {...}' scope.

> The thing is, that seems a relatively obvious and intuitive idea - so som=
ebody must have proposed  it, or something similar, already. Searching this=
 group's archives I found this post:
> https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/tem=
plate$20scope/std-proposals/ficfBQIgR4c/FRPjJ1QFcjoJ
> part of which is very similar to what I suggest, except for involving nam=
espaces and/or class method implementations specifically - which might be i=
nteresting but also problematic (increasing the cost side of a cost/benefit=
 view). My thought was about the absolute-minimum-cost suggestion. That thr=
ead did not end in any conclusive way, nor in references to past discussion=
s.
>=20
> So, my questions to the group:
>  =E2=80=A2 Has this been more extensively/seriously proposed and discusse=
d before?
>  =E2=80=A2 If so, can you refer me to the text of such discussions or dec=
isions?
>  =E2=80=A2 If not, would this have some obvious downside/cost which I'm m=
issing?
>  =E2=80=A2 Ville Voutilainen mentioned, on that thread, a much more far-r=
eaching idea, of having a "with foo bar" construct in C++; I would also be =
interested in the history of that (perhaps for inspiration regarding my sim=
pler idea)
> Respectfully,
>=20
> Eyal Rozenberg

As a side note, also check to see Concepts TS (n4377). Although it seems no=
t to (completely) address your issue, when the template arguments are used =
to declare function parameters, it does simplify:

template <typename T> void foo(T arg);

into:

void foo(auto arg);

given that T is not (heavily) used.

>=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=
 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/isoc=
pp.org/d/msgid/std-proposals/0f4715ef-223b-4d28-8381-d7a43b93d792%40isocpp.=
org.

--=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/E27063D1-5465-4C74-9553-901A4150F323%40outlook.c=
om.

.

On 04/23/2017 10:46 PM, d25fe0be@outlook.com wrote:
>> For a long while now I've been wondering why it is that we have to do so, i.e. write code such as
>>
>> template <typename T> void foo();
>> template <typename T> void bar();
>
> Since for the above declarations, 'T' for 'foo' and 'bar' are not required to be the same (since they can't be related anyway),

Sure, but the main use case for this feature is probably

template<class T>
void C<T>::foo()
{ ... }

template<class T>
void C<T>::bar()
{ ... }

where the "T"s are, in fact, related.

> And that's not what we should do from the design perspective IMHO.
> Grouping things that are not logically related together makes the code hard to maintain. Think about the efforts needed to add another template argument for one of the functions in the 'template <typename T> {...}' scope.

Just move that particular function declaration / definition out of the template<...> { ... } scope?
Seems not exceedingly difficult.

> As a side note, also check to see Concepts TS (n4377). Although it seems not to (completely) address your issue, when the template arguments are used to declare function parameters, it does simplify:
>
> template <typename T> void foo(T arg);
>
> into:
>
> void foo(auto arg);
>
> given that T is not (heavily) used.

In a conceptified landscape, I expect plain (unconstrained) "T"
not to be used frequently, so the "auto" rewrite isn't important
to me.  (Personally, I feel we should have a template header for
a template, but I understand there are other opinions that want
to make templates look like regular functions as much as possible.)

Jens

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

.

------=_Part_1147_1612153423.1492982042734
Content-Type: multipart/alternative;
 boundary="----=_Part_1148_561914878.1492982042734"

------=_Part_1148_561914878.1492982042734
Content-Type: text/plain; charset=UTF-8

About nesting:
Frankly, I had not given that thought, since I essentially never write
nested templates at file scope (as opposed to templated methods of a
templated class). However, I think it would be consistent if any
declaration/definition would "traverse upwards" the chain of `template
<...> indicators surrounding it --- just like it does now, IIANM, except
that it would respect curly braces rather than just directly-preceding
templating indicators --- and be translated/transcribed to a
non-block-scoped nested-template declaration/definition, so that this:

template<class T>
template<class U> {
  void f();
}
becomes this:
template<class T> template<class U> void f();

and this:
template<class T> {
  template<class U> {
    void f();
  }
  void g();
}
becomes this:
template<class T> template<class U> void f();
template<class T> void g();

I hope you're not trying to lay an inconsistency trap for me though :-)

--
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/5a012f5b-6e15-4e13-b6d6-a787596a2218%40isocpp.org.

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

<div dir=3D"ltr">About nesting: <br>Frankly, I had not given that thought, =
since I essentially never write nested templates at file scope (as opposed =
to templated methods of a templated class). However, I think it would be co=
nsistent if any declaration/definition would &quot;traverse upwards&quot; t=
he chain of `template &lt;...&gt; indicators surrounding it --- just like i=
t does now, IIANM, except that it would respect curly braces rather than ju=
st directly-preceding templating indicators --- and be translated/transcrib=
ed to a non-block-scoped nested-template declaration/definition, so that th=
is:<br><br><div style=3D"background-color: rgb(250, 250, 250); border-color=
: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap=
: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">template</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">class=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> <br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> U</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> <br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> <br></span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> <br></span></div></code></=
div>becomes this:<br><div style=3D"background-color: rgb(250, 250, 250); bo=
rder-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; ove=
rflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-=
by-prettify">template</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> U</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> f</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <br>=
</span></div></code></div><br>and this:<br><div style=3D"background-color: =
rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; =
border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code =
class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #=
008;" class=3D"styled-by-prettify">template</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <br>=C2=
=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">templa=
te</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> U</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> <br>=C2=A0 =C2=A0 </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> <br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> <br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> g</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> <br></span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span></div></code></div>b=
ecomes this:<br><code class=3D"prettyprint"><div style=3D"background-color:=
 rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid;=
 border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code=
 class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: =
#008;" class=3D"styled-by-prettify">template</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>template</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">class</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> U</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><br><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><code class=3D"prettyprint"><code class=3D"prettyprint"><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify"></span></code></code> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> g</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"></span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span></div></code></div><span style=3D"color: #000;" class=3D"styled-=
by-prettify"></span></code><br>I hope you&#39;re not trying to lay an incon=
sistency trap for me though :-)<br><br></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/5a012f5b-6e15-4e13-b6d6-a787596a2218%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5a012f5b-6e15-4e13-b6d6-a787596a2218=
%40isocpp.org</a>.<br />

------=_Part_1148_561914878.1492982042734--

------=_Part_1147_1612153423.1492982042734--

.

On 04/23/2017 10:46 PM, d25fe0be@outlook.com wrote:
> And that makes confusion. At the first sight, 'foo' and 'bar' seems to share a same 'T' somehow, just as what we have 'T' for (member functions of) class templates today.

I see where you're coming from. However, if you spend a second to think
about it, you remember than T is just a parameter. You're not setting T,
you're just using it as a formal parameter. You can instantiate foo()
with different T's and it is meaningless to say "instantiate bar with
the same T"s - it's any T.

Also, it's not very dissimilar from having

void foo(int conspicuous_name);
void bar(int conspicuous_name);

which makes you suspect that the arguments to foo() and to bar() are
related somehow.


> And that's not what we should do from the design perspective IMHO.
> Grouping things that are not logically related together makes the code
hard to maintain. Think about the efforts needed to add another template
argument for one of the functions in the 'template <typename T> {...}'
scope.

Well...

1. it's the programmer who has the choice of whether or not to perform
that grouping. For entirely unrelated declarations/definitions, it would
make better sense to break up the grouping.
2. When two functions are declared or defined consecutively, they're
usually are related.

> As a side note, also check to see Concepts TS (n4377).

I'll have a look, thank you.

Eyal

--
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/9d45e465-86f7-4167-c4ec-a8379041a930%40technion.ac.il.

.

------=_Part_995_1463864822.1493021652192
Content-Type: multipart/alternative;
 boundary="----=_Part_996_1377084515.1493021652192"

------=_Part_996_1377084515.1493021652192
Content-Type: text/plain; charset=UTF-8



On Sunday, April 23, 2017 at 10:46:44 PM UTC+2, d25f...@outlook.com wrote:
>
> >
> > On 24 Apr 2017, at 03:54, eya...@technion.ac.il <javascript:> wrote:
> >
> > Hello,
> >
> > This is my first post to this, um, list/group, so please indulge any
> flagrant ignorance.
> >
> > When writing templated code, we often find ourselves writing multiple
> consecutive functions with identical template parameters. (As an example,
> we can have a look at, say, libstdc++'s bits/stl_algo.h ;  or just any
> templated class with multiple methods implemented outside of the class
> definition).
>
> Defining members of a template class outside the class is a pain..
>
>
There was a proposal a while back about "Class Namespace" (a quick search
brings up this link, but I'm not sure this is the latest draft:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0223r0.html).
 This proposal is smaller in scope then the OPs idea, but would solve the
issue for class templates.

I started working on the implementation in clang, but unfortunately I got
distracted... (I have the syntax handled but no semantic actions).

regards,
mitch

--
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/701a4af0-ba41-4546-b7db-e653a14392a0%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Sunday, April 23, 2017 at 10:46:44 PM UTC+2, d2=
5f...@outlook.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt;=
=20
<br>&gt; On 24 Apr 2017, at 03:54, <a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"ErkS9cDdDgAJ" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;j=
avascript:&#39;;return true;">eya...@technion.ac.il</a> wrote:
<br>&gt;=20
<br>&gt; Hello,
<br>&gt;=20
<br>&gt; This is my first post to this, um, list/group, so please indulge a=
ny flagrant ignorance.
<br>&gt;=20
<br>&gt; When writing templated code, we often find ourselves writing multi=
ple consecutive functions with identical template parameters. (As an exampl=
e, we can have a look at, say, libstdc++&#39;s bits/stl_algo.h ; =C2=A0or j=
ust any templated class with multiple methods implemented outside of the cl=
ass definition).
<br>
<br>Defining members of a template class outside the class is a pain..
<br><br></blockquote><div><br></div><div>There was a proposal a while back =
about &quot;Class Namespace&quot; (a quick search brings up this link, but =
I&#39;m not sure this is the latest draft: http://www.open-std.org/jtc1/sc2=
2/wg21/docs/papers/2016/p0223r0.html). =C2=A0This proposal is smaller in sc=
ope then the OPs idea, but would solve the issue for class templates.</div>=
<div><br></div><div>I started working on the implementation in clang, but u=
nfortunately I got distracted... (I have the syntax handled but no semantic=
 actions).</div><div><br></div><div>regards,</div><div>mitch</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/701a4af0-ba41-4546-b7db-e653a14392a0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/701a4af0-ba41-4546-b7db-e653a14392a0=
%40isocpp.org</a>.<br />

------=_Part_996_1377084515.1493021652192--

------=_Part_995_1463864822.1493021652192--

.

------=_Part_1480_1918581720.1493047086531
Content-Type: multipart/alternative;
 boundary="----=_Part_1481_1861398311.1493047086531"

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

I actually think that's a more complicated suggestion, since it requires=20
some resolution work to find the right class. On the other hand, it better=
=20
addresses the annoyance of having to repeat lots of text when implementing=
=20
class methods.

But be that as it may - what's the status of that proposal? I see that it's=
=20
been 'assigned' to the Evolution subgroup; should I post to that mailing=20
lists about this whole business?

Also, do you think it's reasonable/advisable to draft a proposal in a=20
similar format and submit it more officially?


On Monday, April 24, 2017 at 10:14:12 AM UTC+2, P=C3=A9ter Radics wrote:
>
>
>
> On Sunday, April 23, 2017 at 10:46:44 PM UTC+2, d25f...@outlook.com wrote=
:
>>
>> >=20
>> > On 24 Apr 2017, at 03:54, eya...@technion.ac.il wrote:=20
>> >=20
>> > Hello,=20
>> >=20
>> > This is my first post to this, um, list/group, so please indulge any=
=20
>> flagrant ignorance.=20
>> >=20
>> > When writing templated code, we often find ourselves writing multiple=
=20
>> consecutive functions with identical template parameters. (As an example=
,=20
>> we can have a look at, say, libstdc++'s bits/stl_algo.h ;  or just any=
=20
>> templated class with multiple methods implemented outside of the class=
=20
>> definition).=20
>>
>> Defining members of a template class outside the class is a pain..=20
>>
>>
> There was a proposal a while back about "Class Namespace" (a quick search=
=20
> brings up this link, but I'm not sure this is the latest draft:=20
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0223r0.html).=20
>  This proposal is smaller in scope then the OPs idea, but would solve the=
=20
> issue for class templates.
>
> I started working on the implementation in clang, but unfortunately I got=
=20
> distracted... (I have the syntax handled but no semantic actions).
>
> regards,
> mitch
>

--=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/53267650-79b8-431a-abd4-0d0d93991645%40isocpp.or=
g.

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

<div dir=3D"ltr">I actually think that&#39;s a more complicated suggestion,=
 since it requires some resolution work to find the right class. On the oth=
er hand, it better addresses the annoyance of having to repeat lots of text=
 when implementing class methods.<br><br>But be that as it may - what&#39;s=
 the status of that proposal? I see that it&#39;s been &#39;assigned&#39; t=
o the Evolution subgroup; should I post to that mailing lists about this wh=
ole business?<br><br>Also, do you think it&#39;s reasonable/advisable to dr=
aft a proposal in a similar format and submit it more officially?<br><br><b=
r>On Monday, April 24, 2017 at 10:14:12 AM UTC+2, P=C3=A9ter Radics wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><br>On Sun=
day, April 23, 2017 at 10:46:44 PM UTC+2, <a>d25f...@outlook.com</a> wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">&gt;=20
<br>&gt; On 24 Apr 2017, at 03:54, <a rel=3D"nofollow">eya...@technion.ac.i=
l</a> wrote:
<br>&gt;=20
<br>&gt; Hello,
<br>&gt;=20
<br>&gt; This is my first post to this, um, list/group, so please indulge a=
ny flagrant ignorance.
<br>&gt;=20
<br>&gt; When writing templated code, we often find ourselves writing multi=
ple consecutive functions with identical template parameters. (As an exampl=
e, we can have a look at, say, libstdc++&#39;s bits/stl_algo.h ; =C2=A0or j=
ust any templated class with multiple methods implemented outside of the cl=
ass definition).
<br>
<br>Defining members of a template class outside the class is a pain..
<br><br></blockquote><div><br></div><div>There was a proposal a while back =
about &quot;Class Namespace&quot; (a quick search brings up this link, but =
I&#39;m not sure this is the latest draft: <a href=3D"http://www.open-std.o=
rg/jtc1/sc22/wg21/docs/papers/2016/p0223r0.html" target=3D"_blank" rel=3D"n=
ofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhtt=
p%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0=
223r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHIy2eFz_y_FOH25Jh2mznLOL=
wKLA&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/u=
rl?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%=
2F2016%2Fp0223r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHIy2eFz_y_FOH=
25Jh2mznLOLwKLA&#39;;return true;">http://www.open-std.org/jtc1/<wbr>sc22/w=
g21/docs/papers/2016/<wbr>p0223r0.html</a>). =C2=A0This proposal is smaller=
 in scope then the OPs idea, but would solve the issue for class templates.=
</div><div><br></div><div>I started working on the implementation in clang,=
 but unfortunately I got distracted... (I have the syntax handled but no se=
mantic actions).</div><div><br></div><div>regards,</div><div>mitch</div></d=
iv></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/53267650-79b8-431a-abd4-0d0d93991645%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/53267650-79b8-431a-abd4-0d0d93991645=
%40isocpp.org</a>.<br />

------=_Part_1481_1861398311.1493047086531--

------=_Part_1480_1918581720.1493047086531--

.

On 2017-04-24 11:18, eyalroz@technion.ac.il wrote:
> On Monday, April 24, 2017 at 10:14:12 AM UTC+2, P=C3=A9ter Radics wrote:
>> There was a proposal a while back about "Class Namespace" (a quick searc=
h=20
>> brings up this link, but I'm not sure this is the latest draft:=20
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0223r0.html).=
=20

It is. I didn't get a chance to present it at Jacksonville, but the
informal feedback I received was that it needed more work. (Alas, now I
can't recall what folks were wanting...)

>> This proposal is smaller in scope then the OPs idea, but would solve the=
=20
>> issue for class templates.
>
> I actually think that's a more complicated suggestion, since it requires=
=20
> some resolution work to find the right class.

How so? It's a fairly straight-forward transformation. This:

  [TEMPLATE] // template <...>
  namespace CLASS_SPEC {
    TYPE DECL // e.g. int foo(...)
  }

....is equivalent to:

  [TEMPLATE] TYPE CLASS_SPEC::DECL

....and very nearly equivalent to:

  [TEMPLATE] CLASS_SPEC {
    TYPE DECL
  };

I don't see why the compiler would have to work any harder under the
proposal than it already needs to today. A simple implementation can
just memoize the namespace tokens and then transform every declaration
within the scope using said tokens to match its C++current equivalent.

> But be that as it may - what's the status of that proposal? I see that it=
's=20
> been 'assigned' to the Evolution subgroup; should I post to that mailing=
=20
> lists about this whole business?

See above. Needs to be presented. Feedback is always appreciated!

> Also, do you think it's reasonable/advisable to draft a proposal in a=20
> similar format and submit it more officially?

Please talk to me before submitting a similar proposal; it is probably
better to update the existing proposal instead, unless you are proposing
something significantly different. (Even if you want to propose an
alternative, maybe I would like to help :-).)

--=20
Matthew

--=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/58FF63C9.7040202%40gmail.com.

.

On 04/24/2017 12:07 AM, Jens Maurer wrote:
> On 04/23/2017 10:46 PM, d25fe0be@outlook.com wrote:
>>> For a long while now I've been wondering why it is that we have to do so, i.e. write code such as
>>>
>>> template <typename T> void foo();
>>> template <typename T> void bar();
>> Since for the above declarations, 'T' for 'foo' and 'bar' are not required to be the same (since they can't be related anyway),
> Sure, but the main use case for this feature is probably
>
> template<class T>
> void C<T>::foo()
> { ... }
>
> template<class T>
> void C<T>::bar()
> { ... }
>
> where the "T"s are, in fact, related.

Perhaps we should address this directly:

template <class T>
namespace class C<T>  {
     void foo() { ... }
     void bar() { ... }
};


"namespace class" means that any top-level identifiers are now in the
named class.  It does not allow declaring new names, and definitions are
not implied inline.  It just changes the meaning of "foo" to template
<class T> class C<T>::foo.

--
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/373c2fe0-d3a9-6339-50d6-b1acf2ff786a%40scylladb.com.

.

On 04/25/2017 06:28 PM, Avi Kivity wrote:
>
>
> On 04/24/2017 12:07 AM, Jens Maurer wrote:
>> On 04/23/2017 10:46 PM, d25fe0be@outlook.com wrote:
>>>> For a long while now I've been wondering why it is that we have to
>>>> do so, i.e. write code such as
>>>>
>>>> template <typename T> void foo();
>>>> template <typename T> void bar();
>>> Since for the above declarations, 'T' for 'foo' and 'bar' are not
>>> required to be the same (since they can't be related anyway),
>> Sure, but the main use case for this feature is probably
>>
>> template<class T>
>> void C<T>::foo()
>> { ... }
>>
>> template<class T>
>> void C<T>::bar()
>> { ... }
>>
>> where the "T"s are, in fact, related.
>
> Perhaps we should address this directly:
>
> template <class T>
> namespace class C<T>  {
>     void foo() { ... }
>     void bar() { ... }
> };
>
>
> "namespace class" means that any top-level identifiers are now in the
> named class.  It does not allow declaring new names, and definitions
> are not implied inline.  It just changes the meaning of "foo" to
> template <class T> class C<T>::foo.


A few responses below, I see it's already a proposal:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0223r0.html)

--
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/9a077a1a-e850-4112-87ae-e133153ad468%40scylladb.com.

.

On 2017-04-29 12:49, Eyal Rozenberg wrote:
> Your proposal makes sense. I also think my proposal makes sense, and
> the justification is at least partially similar, i.e. "Why should a
> template specification apply to just a single
> definition/declaration?" as an example of DRY.
> [...]
> What do you think? (You = Matthew and everybody else)

The concern I have with your proposal, that I think is shared by others,
is that your scope is a *pure* token repetition; that is, the template
parameters of the scope are each *independently* applied to the items
inside the scope. Compare with P0223 where - yes, even if the
*implementation* may work similarly - the entities in the scope are
logically related.

Also, it just occurs to me, I think I can also solve your problem with
macros:

  #define MY_TEMPLATE \
    template <typename InputIterator, typename Predicate>

  MY_TEMPLATE bool all_of(InputIterator first, Predicate comp);
  MY_TEMPLATE bool any_of(InputIterator first, Predicate comp);

....which lessens the motivation. While I *can* do the same thing for
classes, it's more awkward:

  #define MY_CLASS_TEMPLATE template <typename T>
  #define MY_CLASS_CLASS List<T>::

  MY_CLASS_TEMPLATE MY_CLASS_CLASS List(...) { ... }
  MY_CLASS_TEMPLATE List<T>& MY_CLASS_CLASS operator=(...) { ... }
  MY_CLASS_TEMPLATE List<T>::iterator MY_CLASS_CLASS find(...) { ... }

Unlike the previous example, this is hardly an improvement over writing
out everything the long way. Also, P0223 offers an additional benefit
that doesn't apply to your case; namely, ability to use the class name
or types that are members of the class without extra qualifiers.

--
Matthew

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

.