Consider:

template <typename T>
class Foo {
  // whatever
public:
  void bar();
  void baz();
  void another_fn();
  // ...
};

To define the functions, you would have to write:

template <typename T>
void Foo::bar() { /* ... */ }

template <typename T>
void Foo::baz() { /* ... */ }

template <typename T>
void Foo::another_fn() { /* ... */ }

Wouldn=E2=80=99t it be better if we could write:

template <typename T> {
  void Foo::bar() { /* ... */ }
  void Foo::baz() { /* ... */ }
  void Foo::another_fn() { /* ... */ }
}

Pro:
- less typing (although that is not the motivating reason)
- cleaner, clearer syntax, improving maintainability
- easier to check correctness

What do people think?

--=20

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

.

On 22 May 2015 at 18:20, Douglas Boffey <douglas.boffey@gmail.com> wrote:
> Consider:
>
> template <typename T>
> class Foo {
>   // whatever
> public:
>   void bar();
>   void baz();
>   void another_fn();
>   // ...
> };
>
> To define the functions, you would have to write:
>
> template <typename T>
> void Foo::bar() { /* ... */ }
>
> template <typename T>
> void Foo::baz() { /* ... */ }
>
> template <typename T>
> void Foo::another_fn() { /* ... */ }
>
> Wouldn=E2=80=99t it be better if we could write:
>
> template <typename T> {
>   void Foo::bar() { /* ... */ }
>   void Foo::baz() { /* ... */ }
>   void Foo::another_fn() { /* ... */ }
> }
>
> Pro:
> - less typing (although that is not the motivating reason)
> - cleaner, clearer syntax, improving maintainability
> - easier to check correctness
>
> What do people think?


I don't see how this is superior to writing the brief-version as a synopsis
comment and just writing the actual class definition with the member functi=
on
template definitions in it.

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

.

--089e013a1634ba36580516ad53c6
Content-Type: text/plain; charset=UTF-8

On Fri, May 22, 2015 at 11:23 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> I don't see how this is superior to writing the brief-version as a synopsis
> comment


Consistency of comments are not checked by the compiler and hence
inevitably suffer bit rot.


> and just writing the actual class definition with the member function
> template definitions in it.
>

Does not work for specialization nor explicit instantiation outside of the
header.

/john

--

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

--089e013a1634ba36580516ad53c6
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 F=
ri, May 22, 2015 at 11:23 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilain=
en@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don&=
#39;t see how this is superior to writing the brief-version as a synopsis<b=
r>
comment</blockquote><div><br></div><div>Consistency of comments are not che=
cked by the compiler and hence inevitably suffer bit rot.</div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"> and just writing the actual class defi=
nition with the member function<br>
template definitions in it.<br></blockquote><div><br></div><div>Does not wo=
rk for specialization nor explicit instantiation outside of the header.</di=
v><div><br></div><div>/john</div><div><br></div></div></div></div>

<p></p>

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

--089e013a1634ba36580516ad53c6--

.

On 22 May 2015 at 18:29, John Yates <john@yates-sheets.org> wrote:
> On Fri, May 22, 2015 at 11:23 AM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>>
>> I don't see how this is superior to writing the brief-version as a
>> synopsis
>> comment
>
>
> Consistency of comments are not checked by the compiler and hence inevitably
> suffer bit rot.

I don't see how that's inevitable. The author would be producing a
brief synopsis
that his users would rely on, if that synopsis bitrots, the users will complain.

>
>>
>> and just writing the actual class definition with the member function
>> template definitions in it.
>
>
> Does not work for specialization nor explicit instantiation outside of the
> header.


I am unconvinced those are common enough to motivate a language change
to support such definition-blocks.

--

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

.

> just writing the actual class definition with the member function
> template definitions in it.

I was under the impression that writing the definitions of member
functions within a class definition was a pretty strong hint that the
compiler should inline the functions in code.

On 5/22/15, John Yates <john@yates-sheets.org> wrote:
> On Fri, May 22, 2015 at 11:23 AM, Ville Voutilainen <
> ville.voutilainen@gmail.com> wrote:
>
>> I don't see how this is superior to writing the brief-version as a
>> synopsis
>> comment
>
>
> Consistency of comments are not checked by the compiler and hence
> inevitably suffer bit rot.
>
>
>> and just writing the actual class definition with the member function
>> template definitions in it.
>>
>
> Does not work for specialization nor explicit instantiation outside of the
> header.
>
> /john
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

.

On 22 May 2015 at 18:34, Douglas Boffey <douglas.boffey@gmail.com> wrote:
>> just writing the actual class definition with the member function
>> template definitions in it.
>
> I was under the impression that writing the definitions of member
> functions within a class definition was a pretty strong hint that the
> compiler should inline the functions in code.


That's a red herring, this thing is a class template so the member function
bodies need to be visible to users anyway, so they are eligible for such
inlining regardless of whether they are in the class definition or outside it.

--

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

.

--089e0111c016f650a30516ae1c2f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think this is an excellent idea.  I've wanted this so much that in the
past I've made all of my free functions static members of a dummy struct
and written them all inline, just to avoid the notational bloat.

That's really what this is about - notational bloat, which impedes
readability, comprehension, and overall "ease".

This:

template <typename T> {
  void Foo::bar() { /* ... */ }
  void Foo::baz() { /* ... */ }
  void Foo::another_fn() { /* ... */ }
}

is easier to read, write, port, copy, and grok, than this:

template <typename T>
void Foo::bar() { /* ... */ }

template <typename T>
void Foo::baz() { /* ... */ }

template <typename T>
void Foo::another_fn() { /* ... */ }

I would love to see this, purely from the perspective of elegance.


On Fri, May 22, 2015 at 8:20 AM, Douglas Boffey <douglas.boffey@gmail.com>
wrote:

> Consider:
>
> template <typename T>
> class Foo {
>   // whatever
> public:
>   void bar();
>   void baz();
>   void another_fn();
>   // ...
> };
>
> To define the functions, you would have to write:
>
> template <typename T>
> void Foo::bar() { /* ... */ }
>
> template <typename T>
> void Foo::baz() { /* ... */ }
>
> template <typename T>
> void Foo::another_fn() { /* ... */ }
>
> Wouldn=E2=80=99t it be better if we could write:
>
> template <typename T> {
>   void Foo::bar() { /* ... */ }
>   void Foo::baz() { /* ... */ }
>   void Foo::another_fn() { /* ... */ }
> }
>
> Pro:
> - less typing (although that is not the motivating reason)
> - cleaner, clearer syntax, improving maintainability
> - easier to check correctness
>
> What do people think?
>
> --
>
> ---
> 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/.
>

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

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

<div dir=3D"ltr">I think this is an excellent idea.=C2=A0 I&#39;ve wanted t=
his so much that in the past I&#39;ve made all of my free functions static =
members of a dummy struct and written them all inline, just to avoid the no=
tational bloat.<div><br></div><div>That&#39;s really what this is about - n=
otational bloat, which impedes readability, comprehension, and overall &quo=
t;ease&quot;. =C2=A0</div><div><br></div><div>This:</div><div><br></div><di=
v><span style=3D"font-size:12.8000001907349px">template &lt;typename T&gt; =
{</span><br style=3D"font-size:12.8000001907349px"><span style=3D"font-size=
:12.8000001907349px">=C2=A0 void Foo::bar() { /* ... */ }</span><br style=
=3D"font-size:12.8000001907349px"><span style=3D"font-size:12.8000001907349=
px">=C2=A0 void Foo::baz() { /* ... */ }</span><br style=3D"font-size:12.80=
00001907349px"><span style=3D"font-size:12.8000001907349px">=C2=A0 void Foo=
::another_fn() { /* ... */ }</span><br style=3D"font-size:12.8000001907349p=
x"><span style=3D"font-size:12.8000001907349px">}</span></div><div><span st=
yle=3D"font-size:12.8000001907349px"><br></span></div><div><span style=3D"f=
ont-size:12.8000001907349px">is easier to read, write, port, copy, and grok=
, than this:</span></div><div><br style=3D"font-size:12.8000001907349px"><s=
pan style=3D"font-size:12.8000001907349px">template &lt;typename T&gt;</spa=
n><br style=3D"font-size:12.8000001907349px"><span style=3D"font-size:12.80=
00001907349px">void Foo::bar() { /* ... */ }</span><br style=3D"font-size:1=
2.8000001907349px"><br style=3D"font-size:12.8000001907349px"><span style=
=3D"font-size:12.8000001907349px">template &lt;typename T&gt;</span><br sty=
le=3D"font-size:12.8000001907349px"><span style=3D"font-size:12.80000019073=
49px">void Foo::baz() { /* ... */ }</span><br style=3D"font-size:12.8000001=
907349px"><br style=3D"font-size:12.8000001907349px"><span style=3D"font-si=
ze:12.8000001907349px">template &lt;typename T&gt;</span><br style=3D"font-=
size:12.8000001907349px"><span style=3D"font-size:12.8000001907349px">void =
Foo::another_fn() { /* ... */ }</span><br style=3D"font-size:12.80000019073=
49px"><span style=3D"font-size:12.8000001907349px"><br></span></div><div><s=
pan style=3D"font-size:12.8000001907349px">I would love to see this, purely=
 from the perspective of elegance.</span></div><div><span style=3D"font-siz=
e:12.8000001907349px"><br></span></div></div><div class=3D"gmail_extra"><br=
><div class=3D"gmail_quote">On Fri, May 22, 2015 at 8:20 AM, Douglas Boffey=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:douglas.boffey@gmail.com" target=
=3D"_blank">douglas.boffey@gmail.com</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">Consider:<br>
<br>
template &lt;typename T&gt;<br>
class Foo {<br>
=C2=A0 // whatever<br>
public:<br>
=C2=A0 void bar();<br>
=C2=A0 void baz();<br>
=C2=A0 void another_fn();<br>
=C2=A0 // ...<br>
};<br>
<br>
To define the functions, you would have to write:<br>
<br>
template &lt;typename T&gt;<br>
void Foo::bar() { /* ... */ }<br>
<br>
template &lt;typename T&gt;<br>
void Foo::baz() { /* ... */ }<br>
<br>
template &lt;typename T&gt;<br>
void Foo::another_fn() { /* ... */ }<br>
<br>
Wouldn=E2=80=99t it be better if we could write:<br>
<br>
template &lt;typename T&gt; {<br>
=C2=A0 void Foo::bar() { /* ... */ }<br>
=C2=A0 void Foo::baz() { /* ... */ }<br>
=C2=A0 void Foo::another_fn() { /* ... */ }<br>
}<br>
<br>
Pro:<br>
- less typing (although that is not the motivating reason)<br>
- cleaner, clearer syntax, improving maintainability<br>
- easier to check correctness<br>
<br>
What do people think?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

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

--089e0111c016f650a30516ae1c2f--

.

On Friday 22 May 2015 16:20:23 Douglas Boffey wrote:
> Consider:
>=20
> template <typename T>
> class Foo {
>   // whatever
> public:
>   void bar();
>   void baz();
>   void another_fn();
>   // ...
> };
>=20
> To define the functions, you would have to write:
>=20
> template <typename T>
> void Foo::bar() { /* ... */ }
>=20
> template <typename T>
> void Foo::baz() { /* ... */ }
>=20
> template <typename T>
> void Foo::another_fn() { /* ... */ }
>=20
> Wouldn=E2=80=99t it be better if we could write:
>=20
> template <typename T> {
>   void Foo::bar() { /* ... */ }
>   void Foo::baz() { /* ... */ }
>   void Foo::another_fn() { /* ... */ }
> }
>=20
> Pro:
> - less typing (although that is not the motivating reason)
> - cleaner, clearer syntax, improving maintainability
> - easier to check correctness
>=20
> What do people think?

That syntax confusing as it doesn't take into account member template=20
functions or nested template classes.

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

.

--20cf303f64061f8fd90516af2d02
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I don't see why that shoukd not work. I like the idea. Variables declared
in it automatically could become variable templates.

Am 22.05.2015 18:35 schrieb "Andrey Semashev" <andrey.semashev@gmail.com>:
>
> On Friday 22 May 2015 16:20:23 Douglas Boffey wrote:
> > Consider:
> >
> > template <typename T>
> > class Foo {
> >   // whatever
> > public:
> >   void bar();
> >   void baz();
> >   void another_fn();
> >   // ...
> > };
> >
> > To define the functions, you would have to write:
> >
> > template <typename T>
> > void Foo::bar() { /* ... */ }
> >
> > template <typename T>
> > void Foo::baz() { /* ... */ }
> >
> > template <typename T>
> > void Foo::another_fn() { /* ... */ }
> >
> > Wouldn=E2=80=99t it be better if we could write:
> >
> > template <typename T> {
> >   void Foo::bar() { /* ... */ }
> >   void Foo::baz() { /* ... */ }
> >   void Foo::another_fn() { /* ... */ }
> > }
> >
> > Pro:
> > - less typing (although that is not the motivating reason)
> > - cleaner, clearer syntax, improving maintainability
> > - easier to check correctness
> >
> > What do people think?
>
> That syntax confusing as it doesn't take into account member template
> functions or nested template classes.
>
> --
>
> ---
> 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/.

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

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

<p dir=3D"ltr">I don&#39;t see why that shoukd not work. I like the idea. V=
ariables declared in it automatically could become variable templates. </p>
<p dir=3D"ltr">Am 22.05.2015 18:35 schrieb &quot;Andrey Semashev&quot; &lt;=
<a href=3D"mailto:andrey.semashev@gmail.com">andrey.semashev@gmail.com</a>&=
gt;:<br>
&gt;<br>
&gt; On Friday 22 May 2015 16:20:23 Douglas Boffey wrote:<br>
&gt; &gt; Consider:<br>
&gt; &gt;<br>
&gt; &gt; template &lt;typename T&gt;<br>
&gt; &gt; class Foo {<br>
&gt; &gt;=C2=A0 =C2=A0// whatever<br>
&gt; &gt; public:<br>
&gt; &gt;=C2=A0 =C2=A0void bar();<br>
&gt; &gt;=C2=A0 =C2=A0void baz();<br>
&gt; &gt;=C2=A0 =C2=A0void another_fn();<br>
&gt; &gt;=C2=A0 =C2=A0// ...<br>
&gt; &gt; };<br>
&gt; &gt;<br>
&gt; &gt; To define the functions, you would have to write:<br>
&gt; &gt;<br>
&gt; &gt; template &lt;typename T&gt;<br>
&gt; &gt; void Foo::bar() { /* ... */ }<br>
&gt; &gt;<br>
&gt; &gt; template &lt;typename T&gt;<br>
&gt; &gt; void Foo::baz() { /* ... */ }<br>
&gt; &gt;<br>
&gt; &gt; template &lt;typename T&gt;<br>
&gt; &gt; void Foo::another_fn() { /* ... */ }<br>
&gt; &gt;<br>
&gt; &gt; Wouldn=E2=80=99t it be better if we could write:<br>
&gt; &gt;<br>
&gt; &gt; template &lt;typename T&gt; {<br>
&gt; &gt;=C2=A0 =C2=A0void Foo::bar() { /* ... */ }<br>
&gt; &gt;=C2=A0 =C2=A0void Foo::baz() { /* ... */ }<br>
&gt; &gt;=C2=A0 =C2=A0void Foo::another_fn() { /* ... */ }<br>
&gt; &gt; }<br>
&gt; &gt;<br>
&gt; &gt; Pro:<br>
&gt; &gt; - less typing (although that is not the motivating reason)<br>
&gt; &gt; - cleaner, clearer syntax, improving maintainability<br>
&gt; &gt; - easier to check correctness<br>
&gt; &gt;<br>
&gt; &gt; What do people think?<br>
&gt;<br>
&gt; That syntax confusing as it doesn&#39;t take into account member templ=
ate<br>
&gt; functions or nested template classes.<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; ---<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>

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

--20cf303f64061f8fd90516af2d02--

.

On Friday 22 May 2015 19:41:55 Johannes Schaub wrote:
> I don't see why that shoukd not work.

It will only work if you specify template arguments in every definition, i.=
e.:

 template <typename T> {

   void Foo<T>::bar() { /* ... */ }
   void Foo<T>::baz() { /* ... */ }
   void Foo<T>::another_fn() { /* ... */ }
=20
 }

or

 template <typename T> {

   void Foo::bar<T>() { /* ... */ }
   void Foo::baz<T>() { /* ... */ }
   void Foo::another_fn<T>() { /* ... */ }
=20
 }

or

 template <typename T>
 template <typename U> {

   void Foo<T>::bar<U>() { /* ... */ }
   void Foo<T>::baz<U>() { /* ... */ }
   void Foo<T>::another_fn<U>() { /* ... */ }
=20
 }

Otherwise the definition would be ambiguous. Personally, I don't think ther=
e's=20
much benefit from this change.

> Variables declared in it automatically could become variable templates.

That would most certainly be a gotcha for me.

> Am 22.05.2015 18:35 schrieb "Andrey Semashev" <andrey.semashev@gmail.com>=
:
> > On Friday 22 May 2015 16:20:23 Douglas Boffey wrote:
> > > Consider:
> > >=20
> > > template <typename T>
> > > class Foo {
> > >=20
> > >   // whatever
> > >=20
> > > public:
> > >   void bar();
> > >   void baz();
> > >   void another_fn();
> > >   // ...
> > >=20
> > > };
> > >=20
> > > To define the functions, you would have to write:
> > >=20
> > > template <typename T>
> > > void Foo::bar() { /* ... */ }
> > >=20
> > > template <typename T>
> > > void Foo::baz() { /* ... */ }
> > >=20
> > > template <typename T>
> > > void Foo::another_fn() { /* ... */ }
> > >=20
> > > Wouldn=E2=80=99t it be better if we could write:
> > >=20
> > > template <typename T> {
> > >=20
> > >   void Foo::bar() { /* ... */ }
> > >   void Foo::baz() { /* ... */ }
> > >   void Foo::another_fn() { /* ... */ }
> > >=20
> > > }
> > >=20
> > > Pro:
> > > - less typing (although that is not the motivating reason)
> > > - cleaner, clearer syntax, improving maintainability
> > > - easier to check correctness
> > >=20
> > > What do people think?
> >=20
> > That syntax confusing as it doesn't take into account member template
> > functions or nested template classes.
> >=20
> > --
> >=20
> > ---
> > You received this message because you are subscribed to the Google Grou=
ps
>=20
> "ISO C++ Standard - Future Proposals" group.
>=20
> > To unsubscribe from this group and stop receiving emails from it, send =
an
>=20
> email to std-proposals+unsubscribe@isocpp.org.
>=20
> > To post to this group, send email to std-proposals@isocpp.org.
> > Visit this group at
>=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--=20

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

.

On 5/22/15, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> On 22 May 2015 at 18:34, Douglas Boffey <douglas.boffey@gmail.com> wrote:
>>> just writing the actual class definition with the member function
>>> template definitions in it.
>>
>> I was under the impression that writing the definitions of member
>> functions within a class definition was a pretty strong hint that the
>> compiler should inline the functions in code.
>
>
> That's a red herring, this thing is a class template so the member functi=
on
> bodies need to be visible to users anyway, so they are eligible for such
> inlining regardless of whether they are in the class definition or outsid=
e
> it.
>
No one is arguing that class templates can not be visible.  I am
claiming there is a semantic difference, equivalent to using the
=E2=80=98inline=E2=80=99 specifier for a function.  Admittedly, the compile=
r can
ignore such hints.

Therefore, with respect, it is not the red herring you claim.
> --
>
> ---
> 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/.
>

--=20

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

.

On 23 May 2015 at 12:35, Douglas Boffey <douglas.boffey@gmail.com> wrote:
>>> I was under the impression that writing the definitions of member
>>> functions within a class definition was a pretty strong hint that the
>>> compiler should inline the functions in code.
>> That's a red herring, this thing is a class template so the member funct=
ion
>> bodies need to be visible to users anyway, so they are eligible for such
>> inlining regardless of whether they are in the class definition or outsi=
de
>> it.
> No one is arguing that class templates can not be visible.  I am
> claiming there is a semantic difference, equivalent to using the
> =E2=80=98inline=E2=80=99 specifier for a function.  Admittedly, the compi=
ler can
> ignore such hints.

What _semantic_ difference? There isn't any.

> Therefore, with respect, it is not the red herring you claim.


It most certainly is.

--=20

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

.

On 5/23/15, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> On 23 May 2015 at 12:35, Douglas Boffey <douglas.boffey@gmail.com> wrote:
>>>> I was under the impression that writing the definitions of member
>>>> functions within a class definition was a pretty strong hint that the
>>>> compiler should inline the functions in code.
>>> That's a red herring, this thing is a class template so the member
>>> function
>>> bodies need to be visible to users anyway, so they are eligible for suc=
h
>>> inlining regardless of whether they are in the class definition or
>>> outside
>>> it.
>> No one is arguing that class templates can not be visible.  I am
>> claiming there is a semantic difference, equivalent to using the
>> =E2=80=98inline=E2=80=99 specifier for a function.  Admittedly, the comp=
iler can
>> ignore such hints.
>
> What _semantic_ difference? There isn't any.
>
>> Therefore, with respect, it is not the red herring you claim.
>
>
> It most certainly is.
>
As I have already stated (twice), the semantic difference is in
advising the compiler to expand the function inline.  Is that too
difficult to understand?
> --
>
> ---
> 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/.
>

--=20

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

.

On 23 May 2015 at 12:53, Douglas Boffey <douglas.boffey@gmail.com> wrote:
> As I have already stated (twice), the semantic difference is in
> advising the compiler to expand the function inline.  Is that too
> difficult to understand?


Yes, because "adivising the compiler to expand the function inline" is not
a semantic difference.

--

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

.

--089e0115eb7026fff00516bf8765
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

El 23/5/2015 10:09, escribi=C3=B3:
>
>
> El 22/5/2015 12:20, "Douglas Boffey" <douglas.boffey@gmail.com> escribi=
=C3=B3:
> >
> > Consider:
> >
> > template <typename T>
> > class Foo {
> >   // whatever
> > public:
> >   void bar();
> >   void baz();
> >   void another_fn();
> >   // ...
> > };
>
> FWIW, I think that something similar has been proposed some years ago:
>
> //no namespace version:

Errata: "non template version"

> namespace class Foo {
> void bar() { ... }
> void baz() { ... }
> }
>
> // templated version:
> template <typename T>
> namespace class Foo {
> void bar() { ... }
> void baz() { ... }
> ...rest of the definitions
> }
>
> It was slightly different since blocks are class-specific.
> I don't remember what crushed this.
>
> >
> > To define the functions, you would have to write:
> >
> > template <typename T>
> > void Foo::bar() { /* ... */ }
> >
> > template <typename T>
> > void Foo::baz() { /* ... */ }
> >
> > template <typename T>
> > void Foo::another_fn() { /* ... */ }
> >
> > Wouldn=E2=80=99t it be better if we could write:
> >
> > template <typename T> {
> >   void Foo::bar() { /* ... */ }
> >   void Foo::baz() { /* ... */ }
> >   void Foo::another_fn() { /* ... */ }
> > }
> >
> > Pro:
> > - less typing (although that is not the motivating reason)
> > - cleaner, clearer syntax, improving maintainability
> > - easier to check correctness
> >
> > What do people think?
> >
> > --
> >
> > ---
> > 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/.

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

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

<p dir=3D"ltr"><br>
El 23/5/2015 10:09, escribi=C3=B3:<br>
&gt;<br>
&gt;<br>
&gt; El 22/5/2015 12:20, &quot;Douglas Boffey&quot; &lt;<a href=3D"mailto:d=
ouglas.boffey@gmail.com">douglas.boffey@gmail.com</a>&gt; escribi=C3=B3:<br=
>
&gt; &gt;<br>
&gt; &gt; Consider:<br>
&gt; &gt;<br>
&gt; &gt; template &lt;typename T&gt;<br>
&gt; &gt; class Foo {<br>
&gt; &gt; =C2=A0 // whatever<br>
&gt; &gt; public:<br>
&gt; &gt; =C2=A0 void bar();<br>
&gt; &gt; =C2=A0 void baz();<br>
&gt; &gt; =C2=A0 void another_fn();<br>
&gt; &gt; =C2=A0 // ...<br>
&gt; &gt; };<br>
&gt;<br>
&gt; FWIW, I think that something similar has been proposed some years ago:=
<br>
&gt;<br>
&gt; //no namespace version:</p>
<p dir=3D"ltr">Errata: &quot;non template version&quot;</p>
<p dir=3D"ltr">&gt; namespace class Foo {<br>
&gt; void bar() { ... }<br>
&gt; void baz() { ... }<br>
&gt; }<br>
&gt;<br>
&gt; // templated version:<br>
&gt; template &lt;typename T&gt;<br>
&gt; namespace class Foo {<br>
&gt; void bar() { ... }<br>
&gt; void baz() { ... }<br>
&gt; ...rest of the definitions<br>
&gt; }<br>
&gt;<br>
&gt; It was slightly different since blocks are class-specific.<br>
&gt; I don&#39;t remember what crushed this.<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; To define the functions, you would have to write:<br>
&gt; &gt;<br>
&gt; &gt; template &lt;typename T&gt;<br>
&gt; &gt; void Foo::bar() { /* ... */ }<br>
&gt; &gt;<br>
&gt; &gt; template &lt;typename T&gt;<br>
&gt; &gt; void Foo::baz() { /* ... */ }<br>
&gt; &gt;<br>
&gt; &gt; template &lt;typename T&gt;<br>
&gt; &gt; void Foo::another_fn() { /* ... */ }<br>
&gt; &gt;<br>
&gt; &gt; Wouldn=E2=80=99t it be better if we could write:<br>
&gt; &gt;<br>
&gt; &gt; template &lt;typename T&gt; {<br>
&gt; &gt; =C2=A0 void Foo::bar() { /* ... */ }<br>
&gt; &gt; =C2=A0 void Foo::baz() { /* ... */ }<br>
&gt; &gt; =C2=A0 void Foo::another_fn() { /* ... */ }<br>
&gt; &gt; }<br>
&gt; &gt;<br>
&gt; &gt; Pro:<br>
&gt; &gt; - less typing (although that is not the motivating reason)<br>
&gt; &gt; - cleaner, clearer syntax, improving maintainability<br>
&gt; &gt; - easier to check correctness<br>
&gt; &gt;<br>
&gt; &gt; What do people think?<br>
&gt; &gt;<br>
&gt; &gt; --<br>
&gt; &gt;<br>
&gt; &gt; ---<br>
&gt; &gt; You received this message because you are subscribed to the Googl=
e Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; &gt; To unsubscribe from this group and stop receiving emails from it,=
 send an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org"=
>std-proposals+unsubscribe@isocpp.org</a>.<br>
&gt; &gt; To post to this group, send email to <a href=3D"mailto:std-propos=
als@isocpp.org">std-proposals@isocpp.org</a>.<br>
&gt; &gt; 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-p=
roposals/</a>.<br>
</p>

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

--089e0115eb7026fff00516bf8765--

.

--089e015372122007440516bf8793
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

El 22/5/2015 12:20, "Douglas Boffey" <douglas.boffey@gmail.com> escribi=C3=
=B3:
>
> Consider:
>
> template <typename T>
> class Foo {
>   // whatever
> public:
>   void bar();
>   void baz();
>   void another_fn();
>   // ...
> };

FWIW, I think that something similar has been proposed some years ago:

//no namespace version:
namespace class Foo {
void bar() { ... }
void baz() { ... }
}

// templated version:
template <typename T>
namespace class Foo {
void bar() { ... }
void baz() { ... }
....rest of the definitions
}

It was slightly different since blocks are class-specific.
I don't remember what crushed this.

>
> To define the functions, you would have to write:
>
> template <typename T>
> void Foo::bar() { /* ... */ }
>
> template <typename T>
> void Foo::baz() { /* ... */ }
>
> template <typename T>
> void Foo::another_fn() { /* ... */ }
>
> Wouldn=E2=80=99t it be better if we could write:
>
> template <typename T> {
>   void Foo::bar() { /* ... */ }
>   void Foo::baz() { /* ... */ }
>   void Foo::another_fn() { /* ... */ }
> }
>
> Pro:
> - less typing (although that is not the motivating reason)
> - cleaner, clearer syntax, improving maintainability
> - easier to check correctness
>
> What do people think?
>
> --
>
> ---
> 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/.

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

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

<p dir=3D"ltr"><br>
El 22/5/2015 12:20, &quot;Douglas Boffey&quot; &lt;<a href=3D"mailto:dougla=
s.boffey@gmail.com">douglas.boffey@gmail.com</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt; Consider:<br>
&gt;<br>
&gt; template &lt;typename T&gt;<br>
&gt; class Foo {<br>
&gt; =C2=A0 // whatever<br>
&gt; public:<br>
&gt; =C2=A0 void bar();<br>
&gt; =C2=A0 void baz();<br>
&gt; =C2=A0 void another_fn();<br>
&gt; =C2=A0 // ...<br>
&gt; };</p>
<p dir=3D"ltr">FWIW, I think that something similar has been proposed some =
years ago:</p>
<p dir=3D"ltr">//no namespace version:<br>
namespace class Foo {<br>
void bar() { ... }<br>
void baz() { ... }<br>
}</p>
<p dir=3D"ltr">// templated version:<br>
template &lt;typename T&gt;<br>
namespace class Foo {<br>
void bar() { ... }<br>
void baz() { ... }<br>
....rest of the definitions<br>
}</p>
<p dir=3D"ltr">It was slightly different since blocks are class-specific.<b=
r>
I don&#39;t remember what crushed this.</p>
<p dir=3D"ltr">&gt;<br>
&gt; To define the functions, you would have to write:<br>
&gt;<br>
&gt; template &lt;typename T&gt;<br>
&gt; void Foo::bar() { /* ... */ }<br>
&gt;<br>
&gt; template &lt;typename T&gt;<br>
&gt; void Foo::baz() { /* ... */ }<br>
&gt;<br>
&gt; template &lt;typename T&gt;<br>
&gt; void Foo::another_fn() { /* ... */ }<br>
&gt;<br>
&gt; Wouldn=E2=80=99t it be better if we could write:<br>
&gt;<br>
&gt; template &lt;typename T&gt; {<br>
&gt; =C2=A0 void Foo::bar() { /* ... */ }<br>
&gt; =C2=A0 void Foo::baz() { /* ... */ }<br>
&gt; =C2=A0 void Foo::another_fn() { /* ... */ }<br>
&gt; }<br>
&gt;<br>
&gt; Pro:<br>
&gt; - less typing (although that is not the motivating reason)<br>
&gt; - cleaner, clearer syntax, improving maintainability<br>
&gt; - easier to check correctness<br>
&gt;<br>
&gt; What do people think?<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; ---<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>

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

--089e015372122007440516bf8793--

.

2015-05-22 17:20 GMT+02:00 Douglas Boffey <douglas.boffey@gmail.com>:
> Consider:
>
> template <typename T>
> class Foo {
>   // whatever
> public:
>   void bar();
>   void baz();
>   void another_fn();
>   // ...
> };
>
> To define the functions, you would have to write:
>
> template <typename T>
> void Foo::bar() { /* ... */ }
>
> template <typename T>
> void Foo::baz() { /* ... */ }
>
> template <typename T>
> void Foo::another_fn() { /* ... */ }
>
> Wouldn=E2=80=99t it be better if we could write:
>
> template <typename T> {
>   void Foo::bar() { /* ... */ }
>   void Foo::baz() { /* ... */ }
>   void Foo::another_fn() { /* ... */ }
> }
>
> Pro:
> - less typing (although that is not the motivating reason)
> - cleaner, clearer syntax, improving maintainability
> - easier to check correctness
>
> What do people think?
>

OK, let's be more serious this time :) I think for what the goal of it
is (avoid repetition of the template header in order to declare member
functions of class templates), this is an overkill-feature on one
side, and too little on another side. I mean, you still have to repeat
the class names, and you open up the gate of declaring anything else
as a template.

I think a more limited and more-to-the-point syntax could be

template<typename T>
class Foo {
  void bar();
  void baz();
};

template<typename T>
class ::Foo {
  // declare the definitions here
  void bar() {

  }

  void baz() {

  }
};


Notice the "::Foo", which says "redeclare Foo and zero or more of its
members". If there's a declaration in it that wasn't declared in the
initial definition of the class template, the program is ill-formed.

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

.

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

Ok, even if I chose the wrong word, it doesn=E2=80=99t invalidate my point.

On Sat, May 23, 2015 at 10:55 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 23 May 2015 at 12:53, Douglas Boffey <douglas.boffey@gmail.com> wrote:
> > As I have already stated (twice), the semantic difference is in
> > advising the compiler to expand the function inline.  Is that too
> > difficult to understand?
>
>
> Yes, because "adivising the compiler to expand the function inline" is no=
t
> a semantic difference.
>
> --
>
> ---
> 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/.
>

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

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

<div dir=3D"ltr">Ok, even if I chose the wrong word, it doesn=E2=80=99t inv=
alidate my point.<br></div><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On Sat, May 23, 2015 at 10:55 AM, Ville Voutilainen <span dir=3D"=
ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">v=
ille.voutilainen@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><span class=3D"">On 23 May 2015 at 12:53, Douglas Boffey &lt;<a hre=
f=3D"mailto:douglas.boffey@gmail.com">douglas.boffey@gmail.com</a>&gt; wrot=
e:<br>
&gt; As I have already stated (twice), the semantic difference is in<br>
&gt; advising the compiler to expand the function inline.=C2=A0 Is that too=
<br>
&gt; difficult to understand?<br>
<br>
<br>
</span>Yes, because &quot;adivising the compiler to expand the function inl=
ine&quot; is not<br>
a semantic difference.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a113d559023c2360516bfce1e--

.

2015-05-22 17:20 GMT+02:00 Douglas Boffey <douglas.boffey@gmail.com>:
> Consider:
>
> template <typename T>
> class Foo {
>   // whatever
> public:
>   void bar();
>   void baz();
>   void another_fn();
>   // ...
> };
>
> To define the functions, you would have to write:
>
> template <typename T>
> void Foo::bar() { /* ... */ }
>
> template <typename T>
> void Foo::baz() { /* ... */ }
>
> template <typename T>
> void Foo::another_fn() { /* ... */ }
>
> Wouldn=E2=80=99t it be better if we could write:
>
> template <typename T> {
>   void Foo::bar() { /* ... */ }
>   void Foo::baz() { /* ... */ }
>   void Foo::another_fn() { /* ... */ }
> }
>
> Pro:
> - less typing (although that is not the motivating reason)
> - cleaner, clearer syntax, improving maintainability
> - easier to check correctness
>
> What do people think?
>

Alternatively, we can introduce "auto" alias templates that will alias
to dependent types:

template<typename T>
auto using T1 =3D T;

template<typename, typename T>
auto using T2 =3D T;

Then you write

void Foo<T1>::bar() {

}

void Foo<T2>::bar() {

}

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

.

2015-05-23 15:43 GMT+02:00 Johannes Schaub <schaub.johannes@googlemail.com>=
:
> 2015-05-22 17:20 GMT+02:00 Douglas Boffey <douglas.boffey@gmail.com>:
>> Consider:
>>
>> template <typename T>
>> class Foo {
>>   // whatever
>> public:
>>   void bar();
>>   void baz();
>>   void another_fn();
>>   // ...
>> };
>>
>> To define the functions, you would have to write:
>>
>> template <typename T>
>> void Foo::bar() { /* ... */ }
>>
>> template <typename T>
>> void Foo::baz() { /* ... */ }
>>
>> template <typename T>
>> void Foo::another_fn() { /* ... */ }
>>
>> Wouldn=E2=80=99t it be better if we could write:
>>
>> template <typename T> {
>>   void Foo::bar() { /* ... */ }
>>   void Foo::baz() { /* ... */ }
>>   void Foo::another_fn() { /* ... */ }
>> }
>>
>> Pro:
>> - less typing (although that is not the motivating reason)
>> - cleaner, clearer syntax, improving maintainability
>> - easier to check correctness
>>
>> What do people think?
>>
>
> Alternatively, we can introduce "auto" alias templates that will alias
> to dependent types:
>
> template<typename T>
> auto using T1 =3D T;
>
> template<typename, typename T>
> auto using T2 =3D T;
>
> Then you write
>
> void Foo<T1>::bar() {
>
> }
>
> void Foo<T2>::bar() {
>
> }

Sorry, this should have been

void Foo<T1>::bar() {

}

void Foo<T1>::baz() {

}

Must be too little sleep today

--=20

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

.

On 23 May 2015 at 16:32, Douglas Boffey <douglas.boffey@gmail.com> wrote:
> Ok, even if I chose the wrong word, it doesn=E2=80=99t invalidate my poin=
t.

Your point seems to be at best unsubstantiated and at worst a misconception=
..
I get the notational convenience of this idea, but I fail to see it
convincing enough
to warrant a language change. Such syntactic sugar would be nice, but I don=
't
see it as nice enough to change every front-end on the planet to support it=
..

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

.