Topic: Small contribution to readability (of at least my code)


Author: John Yates <john@yates-sheets.org>
Date: Sat, 14 Nov 2015 14:14:05 -0500
Raw View
--047d7b33cef0cbd1f4052484faaa
Content-Type: text/plain; charset=UTF-8

I attempt to have one class per header.  This allows me to follow a
file-wide organizing principle.

(This description will sidestep my treatment of a protected interface.)

The top of my class enumerates only the public interface (primarily method
declarations).  I never include any (inline) method bodies.  Once done with
the public interface I place an 80 character ////... boundary mark to
indicate that beyond that point one will find only private members and
method definitions.  For example

--- MyClass.hpp ---

#pragma once
#include "incl1.hpp"
#include "incl2.hpp"

class MyClass
  /// Doxygen markup positionally associated with MyClass...
{
public:
  MyClass(int =0);

  int val() const;
  void val(int);

////////////////////////////////////////////////////////////////////////////////
private:
  int val_;       ///< Doxygen markup positionally associated with data
member...

};  // end of MyClass

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -

inline
MyClass::MyClass
  /// Doxygen markup positionally associated with constructor...
  ( int val
  )
  : val_(val)
{}

inline
int MyClass::val
  /// Doxygen markup positionally associated with method...
  () const
{
  return val_;
}

inline
void MyClass::val
  /// Doxygen markup positionally associated with method...
  ( int val       ///< Doxygen markup positionally associated with parameter
....
  )
{
  val_ = val;
}

-------------

While this style is textually longer it has a number of benefits.  Clearly
the public interface is presented in a form that is very easy to consult
once one is familiar with the class.  Often it is even a nearly ideal
presentation even for ones first exposure.

If you believe as I do that the part of the gradual movement towards
left-to-right declarations is a recognition that a name should be
introduced before being described then you will understand my philosophy of
Doxygen markup.  It always follows the name being documented.  This works
at a human level because it is usually easy to spot the name being
introduced.

Finally, apart for the preceding inline token,  the formatting of methods
at the bottom of the header is identical to the formatting that I employ in
the corresponding implementation file.  This makes moving a method between
header and implementation truly nothing more than cut and paste (and of
course deleting the orphaned inline token).

Sadly a number of these virtues diminish when the class is templatized:

--- MyTemplateClass.hpp ---

#pragma once
#include "incl1.hpp"
#include "incl2.hpp"

template<typename TYPE1, typename TYPE2>
class MyTemplateClass
  /// Doxygen markup positionally associated with MyTemplateClass...
{
public:
  MyTemplateClass(int =0);

  int val() const;
  void val(int);

////////////////////////////////////////////////////////////////////////////////
private:
  int val_;       ///< Doxygen markup positionally associated with data
member...

};  // end of MyTemplateClass

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -

template<typename TYPE1, typename TYPE2>
inline
MyTemplateClass<TYPE1, TYPE2>::MyTemplateClass
  /// Doxygen markup positionally associated with constructor...
  ( int val
  )
  : val_(val)
{}

template<typename TYPE1, typename TYPE2>
inline
int MyTemplateClass<TYPE1, TYPE2>::val
  /// Doxygen markup positionally associated with method...
  () const
{
  return val_;
}

template<typename TYPE1, typename TYPE2>
inline
void MyTemplateClass<TYPE1, TYPE2>::val
  /// Doxygen markup positionally associated with method...
  ( int val       ///< Doxygen markup positionally associated with
parameter...
  )
{
  val_ = val;
}

-------------

Now the cost of separating method declaration at the top of the class from
definition further down is a tougher sell.  Spotting the method name within
the template baggage is less easy.  And there is no implementation .cpp
file to which definitions might potentially get moved.

A possible solution occurred to me when I recently had cause to write the
following:

class C {
public:
  struct S;
  struct S { int a; };
};

That is a type declared forward within a class can be resolved within that
class.  So why can we not allow the same thing for methods:

template<typename TYPE1, typename TYPE2>
class MyTemplateClass
  /// Doxygen markup positionally associated with MyTemplateClass...
{
public:
  MyTemplateClass(int =0);

  int val() const;
  void val(int);

////////////////////////////////////////////////////////////////////////////////
private:
  int val_;       ///< Doxygen markup positionally associated with data
member...

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -

  MyTemplateClass
    /// Doxygen markup positionally associated with constructor...
    ( int val
    )
    : val_(val)
  {}

  int val
    /// Doxygen markup positionally associated with method...
    () const
  {
    return val_;
  }

  void val
    /// Doxygen markup positionally associated with method...
    ( int val       ///< Doxygen markup positionally associated with
parameter...
    )
  {
    val_ = val;
  }

};  // end of MyTemplateClass


If I could write that I probably would do it everywhere.

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

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

<div dir=3D"ltr">I attempt to have one class per header.=C2=A0 This allows =
me to follow a file-wide organizing principle.<div><br></div><div>(This des=
cription will sidestep my treatment of a protected interface.)</div><div><b=
r></div><div>The top of my class enumerates only the public interface (prim=
arily method declarations).=C2=A0 I never include any (inline) method bodie=
s.=C2=A0 Once done with the public interface I place an 80 character ////..=
.. boundary mark to indicate that beyond that point one will find only priva=
te members and method definitions.=C2=A0 For example</div><div><br></div><d=
iv><font face=3D"monospace, monospace">--- MyClass.hpp ---</font></div><div=
><font face=3D"monospace, monospace"><br></font></div><div><font face=3D"mo=
nospace, monospace">#pragma once</font></div><div><font face=3D"monospace, =
monospace">#include &quot;incl1.hpp&quot;<br></font><div><div><font face=3D=
"monospace, monospace">#include &quot;incl2.hpp&quot;<br></font><div></div>=
</div><div><font face=3D"monospace, monospace"><br></font></div><div><font =
face=3D"monospace, monospace">class=C2=A0</font><span style=3D"font-family:=
monospace,monospace">MyClass</span></div><div><font face=3D"monospace, mono=
space">=C2=A0 /// Doxygen markup positionally associated with MyClass...</f=
ont></div><div><font face=3D"monospace, monospace">{</font></div><div><font=
 face=3D"monospace, monospace">public:</font></div><div><font face=3D"monos=
pace, monospace">=C2=A0=C2=A0</font><span style=3D"font-family:monospace,mo=
nospace">MyClass</span><span style=3D"font-family:monospace,monospace">(int=
 =3D0);</span></div><div><font face=3D"monospace, monospace"><br></font></d=
iv><div><font face=3D"monospace, monospace">=C2=A0 int val() const;</font><=
/div><div><font face=3D"monospace, monospace">=C2=A0 void val(int);</font><=
/div><div><font face=3D"monospace, monospace"><br></font></div><div><font f=
ace=3D"monospace, monospace">//////////////////////////////////////////////=
//////////////////////////////////<br></font></div><div><font face=3D"monos=
pace, monospace">private:</font></div><div><font face=3D"monospace, monospa=
ce">=C2=A0 int val_; =C2=A0 =C2=A0 =C2=A0 ///&lt; Doxygen markup</font><spa=
n style=3D"font-family:monospace,monospace">=C2=A0</span><span style=3D"fon=
t-family:monospace,monospace">positionally associated with data member</spa=
n><span style=3D"font-family:monospace,monospace">...</span></div><div><fon=
t face=3D"monospace, monospace"><br></font></div><div><font face=3D"monospa=
ce, monospace">};=C2=A0 // end of MyClass<br></font></div><div><font face=
=3D"monospace, monospace"><br></font></div><div><font face=3D"monospace, mo=
nospace">// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=
 - - - - - - -<br></font></div><div><font face=3D"monospace, monospace"><br=
></font></div><div><font face=3D"monospace, monospace">inline</font></div><=
div><span style=3D"font-family:monospace,monospace">MyClass</span><font fac=
e=3D"monospace, monospace">::</font><span style=3D"font-family:monospace,mo=
nospace">MyClass</span></div><div><font face=3D"monospace, monospace">=C2=
=A0 /// Doxygen markup</font><span style=3D"font-family:monospace,monospace=
">=C2=A0</span><span style=3D"font-family:monospace,monospace">positionally=
 associated with constructor</span><span style=3D"font-family:monospace,mon=
ospace">...</span></div><div><font face=3D"monospace, monospace">=C2=A0 ( i=
nt val<br></font></div><div><font face=3D"monospace, monospace">=C2=A0 )</f=
ont></div><div><font face=3D"monospace, monospace">=C2=A0 : val_(val)</font=
></div><div><font face=3D"monospace, monospace">{}</font></div><div><font f=
ace=3D"monospace, monospace"><br></font></div><div><font face=3D"monospace,=
 monospace">inline</font></div><div><font face=3D"monospace, monospace">int=
=C2=A0</font><span style=3D"font-family:monospace,monospace">MyClass</span>=
<span style=3D"font-family:monospace,monospace">::val</span></div><div><div=
><font face=3D"monospace, monospace">=C2=A0 /// Doxygen markup</font><span =
style=3D"font-family:monospace,monospace">=C2=A0</span><span style=3D"font-=
family:monospace,monospace">positionally associated with method</span><span=
 style=3D"font-family:monospace,monospace">...</span></div></div><div><font=
 face=3D"monospace, monospace">=C2=A0 () const</font></div><div><font face=
=3D"monospace, monospace">{</font></div><div><font face=3D"monospace, monos=
pace">=C2=A0 return val_;</font></div><div><font face=3D"monospace, monospa=
ce">}</font></div><div><font face=3D"monospace, monospace"><br></font></div=
><div><font face=3D"monospace, monospace">inline</font></div><div><font fac=
e=3D"monospace, monospace">void=C2=A0</font><span style=3D"font-family:mono=
space,monospace">MyClass</span><span style=3D"font-family:monospace,monospa=
ce">::val</span></div><div><div><font face=3D"monospace, monospace">=C2=A0 =
/// Doxygen markup</font><span style=3D"font-family:monospace,monospace">=
=C2=A0</span><span style=3D"font-family:monospace,monospace">positionally a=
ssociated with method</span><span style=3D"font-family:monospace,monospace"=
>...</span></div></div><div><font face=3D"monospace, monospace">=C2=A0 ( in=
t val =C2=A0 =C2=A0 =C2=A0 ///&lt; Doxygen markup</font><span style=3D"font=
-family:monospace,monospace">=C2=A0</span><span style=3D"font-family:monosp=
ace,monospace">positionally associated with parameter</span><span style=3D"=
font-family:monospace,monospace">...</span></div><div><span style=3D"font-f=
amily:monospace,monospace">=C2=A0 )</span><br></div><div><font face=3D"mono=
space, monospace">{</font></div><div><font face=3D"monospace, monospace">=
=C2=A0 val_ =3D val;</font></div><div><font face=3D"monospace, monospace">}=
</font></div><div><div><font face=3D"monospace, monospace"><br></font></div=
><div><font face=3D"monospace, monospace">-------------</font></div></div><=
div><font face=3D"monospace, monospace"><br></font></div><div>While this st=
yle is textually longer it has a number of benefits.=C2=A0 Clearly the publ=
ic interface is presented in a form that is very easy to consult once one i=
s familiar with the class.=C2=A0 Often it is even a nearly ideal presentati=
on even for ones first exposure.</div><div><br></div><div>If you believe as=
 I do that the part of the gradual movement towards left-to-right declarati=
ons is a recognition that a name should be introduced before being describe=
d then you will understand my philosophy of Doxygen markup.=C2=A0 It always=
 follows the name being documented.=C2=A0 This works at a human level becau=
se it is usually easy to spot the name being introduced.</div><div><br></di=
v><div>Finally, apart for the preceding <font face=3D"monospace, monospace"=
>inline</font> token, =C2=A0the formatting of methods at the bottom of the =
header is identical to the formatting that I employ in the corresponding im=
plementation file.=C2=A0 This makes moving a method between header and impl=
ementation truly nothing more than cut and paste (and of course deleting th=
e orphaned <font face=3D"monospace, monospace">inline</font> token).</div><=
div><br></div><div>Sadly a number of these virtues diminish when the class =
is templatized:</div><div><br></div><div><font face=3D"monospace, monospace=
"><div>--- MyTemplateClass.hpp ---</div><div><br></div><div>#pragma once</d=
iv><div>#include &quot;incl1.hpp&quot;</div><div>#include &quot;incl2.hpp&q=
uot;</div><div><br></div><div>template&lt;typename TYPE1, typename TYPE2&gt=
;</div><div>class MyTemplateClass</div><div>=C2=A0 /// Doxygen markup posit=
ionally associated with MyTemplateClass...</div><div>{</div><div>public:</d=
iv><div>=C2=A0 MyTemplateClass(int =3D0);</div><div><br></div><div>=C2=A0 i=
nt val() const;</div><div>=C2=A0 void val(int);</div><div><br></div><div>//=
///////////////////////////////////////////////////////////////////////////=
///</div><div>private:</div><div>=C2=A0 int val_; =C2=A0 =C2=A0 =C2=A0 ///&=
lt; Doxygen markup positionally associated with data member...</div><div><b=
r></div><div>};=C2=A0 // end of MyTemplateClass</div><div><br></div><div>//=
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - =
- -</div><div><br></div><div>template&lt;typename TYPE1, typename TYPE2&gt;=
</div><div>inline</div><div>MyTemplateClass&lt;TYPE1, TYPE2&gt;::MyTemplate=
Class</div><div>=C2=A0 /// Doxygen markup positionally associated with cons=
tructor...</div><div>=C2=A0 ( int val</div><div>=C2=A0 )</div><div>=C2=A0 :=
 val_(val)</div><div>{}</div><div><br></div><div>template&lt;typename TYPE1=
, typename TYPE2&gt;</div><div>inline</div><div>int MyTemplateClass&lt;TYPE=
1, TYPE2&gt;::val</div><div>=C2=A0 /// Doxygen markup positionally associat=
ed with method...</div><div>=C2=A0 () const</div><div>{</div><div>=C2=A0 re=
turn val_;</div><div>}</div><div><br></div><div>template&lt;typename TYPE1,=
 typename TYPE2&gt;</div><div>inline</div><div>void MyTemplateClass&lt;TYPE=
1, TYPE2&gt;::val</div><div>=C2=A0 /// Doxygen markup positionally associat=
ed with method...</div><div>=C2=A0 ( int val =C2=A0 =C2=A0 =C2=A0 ///&lt; D=
oxygen markup positionally associated with parameter...</div><div>=C2=A0 )<=
/div><div>{</div><div>=C2=A0 val_ =3D val;</div><div>}</div><div><br></div>=
<div>-------------</div></font><br>Now the cost of separating method declar=
ation at the top of the class from definition further down is a tougher sel=
l.=C2=A0 Spotting the method name within the template baggage is less easy.=
=C2=A0 And there is no implementation .cpp file to which definitions might =
potentially get moved.</div></div></div><div><br></div><div>A possible solu=
tion occurred to me when I recently had cause to write the following:</div>=
<div><br></div><div><div><font face=3D"monospace, monospace">class C {</fon=
t></div><div><font face=3D"monospace, monospace">public:</font></div><div><=
font face=3D"monospace, monospace">=C2=A0 struct S;</font></div><div><font =
face=3D"monospace, monospace">=C2=A0 struct S { int a; };</font></div><div>=
<font face=3D"monospace, monospace">};</font></div></div><div><br></div><di=
v>That is a type declared forward within a class can be resolved within tha=
t class.=C2=A0 So why can we not allow the same thing for methods:</div><di=
v><br></div><div><div><font face=3D"monospace, monospace">template&lt;typen=
ame TYPE1, typename TYPE2&gt;</font></div><div><font face=3D"monospace, mon=
ospace">class MyTemplateClass</font></div><div><font face=3D"monospace, mon=
ospace">=C2=A0 /// Doxygen markup positionally associated with MyTemplateCl=
ass...</font></div><div><font face=3D"monospace, monospace">{</font></div><=
div><font face=3D"monospace, monospace">public:</font></div><div><font face=
=3D"monospace, monospace">=C2=A0 MyTemplateClass(int =3D0);</font></div><di=
v><font face=3D"monospace, monospace"><br></font></div><div><font face=3D"m=
onospace, monospace">=C2=A0 int val() const;</font></div><div><font face=3D=
"monospace, monospace">=C2=A0 void val(int);</font></div><div><font face=3D=
"monospace, monospace"><br></font></div><div><font face=3D"monospace, monos=
pace">/////////////////////////////////////////////////////////////////////=
///////////</font></div><div><font face=3D"monospace, monospace">private:</=
font></div><div><font face=3D"monospace, monospace">=C2=A0 int val_; =C2=A0=
 =C2=A0 =C2=A0 ///&lt; Doxygen markup positionally associated with data mem=
ber...</font></div><div><font face=3D"monospace, monospace"><br></font></di=
v><div><font face=3D"monospace, monospace">// - - - - - - - - - - - - - - -=
 - - - - - - - - - - - - - - - - - - - - - - - -</font></div><div><font fac=
e=3D"monospace, monospace"><br></font></div><div><font face=3D"monospace, m=
onospace">=C2=A0 MyTemplateClass</font></div><div><font face=3D"monospace, =
monospace">=C2=A0 =C2=A0 /// Doxygen markup positionally associated with co=
nstructor...</font></div><div><font face=3D"monospace, monospace">=C2=A0 =
=C2=A0 ( int val</font></div><div><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 )</font></div><div><font face=3D"monospace, monospace">=C2=A0 =
=C2=A0 : val_(val)</font></div><div><font face=3D"monospace, monospace">=C2=
=A0 {}</font></div><div><font face=3D"monospace, monospace"><br></font></di=
v><div><font face=3D"monospace, monospace">=C2=A0 int val</font></div><div>=
<font face=3D"monospace, monospace">=C2=A0 =C2=A0 /// Doxygen markup positi=
onally associated with method...</font></div><div><font face=3D"monospace, =
monospace">=C2=A0 =C2=A0 () const</font></div><div><font face=3D"monospace,=
 monospace">=C2=A0 {</font></div><div><font face=3D"monospace, monospace">=
=C2=A0 =C2=A0 return val_;</font></div><div><font face=3D"monospace, monosp=
ace">=C2=A0 }</font></div><div><font face=3D"monospace, monospace"><br></fo=
nt></div><div><font face=3D"monospace, monospace">=C2=A0 void val</font></d=
iv><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 /// Doxygen marku=
p positionally associated with method...</font></div><div><font face=3D"mon=
ospace, monospace">=C2=A0 =C2=A0 ( int val =C2=A0 =C2=A0 =C2=A0 ///&lt; Dox=
ygen markup positionally associated with parameter...</font></div><div><fon=
t face=3D"monospace, monospace">=C2=A0 =C2=A0 )</font></div><div><font face=
=3D"monospace, monospace">=C2=A0 {</font></div><div><font face=3D"monospace=
, monospace">=C2=A0 =C2=A0 val_ =3D val;</font></div><div><font face=3D"mon=
ospace, monospace">=C2=A0 }</font></div><div><font face=3D"monospace, monos=
pace"><br></font></div><div><font face=3D"monospace, monospace">}; =C2=A0//=
 end of MyTemplateClass</font></div></div><br><div><br></div><div>If I coul=
d write that I probably would do it everywhere.</div><div><br></div><div>/j=
ohn</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 />

--047d7b33cef0cbd1f4052484faaa--

.


Author: Larry Evans <cppljevans@suddenlink.net>
Date: Sat, 14 Nov 2015 15:42:57 -0600
Raw View
On 11/14/2015 01:14 PM, John Yates wrote:
> I attempt to have one class per header.  This allows me to follow a
> file-wide organizing principle.
>
Hi John,

I'd guess This topic is better covered in other newsgroups.
Try googling "c++.moderated coding style" to find a better
place to post you message.

BTW, I like your idea:

  a name should be introduced before being described

which is a rule I use.

-regards,
Larry



--

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

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 15 Nov 2015 07:05:57 -0800 (PST)
Raw View
------=_Part_61_1371115111.1447599957442
Content-Type: multipart/alternative;
 boundary="----=_Part_62_1264802048.1447599957443"

------=_Part_62_1264802048.1447599957443
Content-Type: text/plain; charset=UTF-8

On Saturday, November 14, 2015 at 2:14:08 PM UTC-5, John Yates wrote:
>
> If you believe as I do that the part of the gradual movement towards
> left-to-right declarations is a recognition that a name should be
> introduced before being described then you will understand my philosophy of
> Doxygen markup.
>

Here's my feeling on this.

Normally in C++, you aren't allowed to talk about a name before it gets
used. If a name appears later in a file, too bad; you have to forward
declare it or you get a compiler error.

This is true everywhere... *except* in a class definition. There, you are
allowed to talk about names that appear later in the class. This was *specifically
added* to the language, because nowhere else does the language work this
way. Adding this feature made compilers rather more difficult to write. But
it makes code much easier to write, since you *don't* have to declare every
member before writing the definitions of those member functions. Not to
mention, it makes things like CRTP-mixins possible, where a base class can
cast itself to the derived class type and access its members; that would
not be possible if C++ didn't allow delayed name lookup.

In short, it is a very good thing that C++ allows this.

My feeling is that if you need to forward declare a member function, you
ought to just define it outside of the class definition. Yes, I know that
this makes it rather difficult for template classes, due to the gigantic
prefix associated with the function name. But we have C++ tools for
creating member function definitions automatically nowadays. It's not that
big of a deal.

--

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

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

<div dir=3D"ltr">On Saturday, November 14, 2015 at 2:14:08 PM UTC-5, John Y=
ates wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv><div><div></div><div>If you believe as I do that the part of the gradual=
 movement towards left-to-right declarations is a recognition that a name s=
hould be introduced before being described then you will understand my phil=
osophy of Doxygen markup.<br></div></div></div></div></blockquote><div><br>=
Here&#39;s my feeling on this.<br><br>Normally in C++, you aren&#39;t allow=
ed to talk about a name before it gets used. If a name appears later in a f=
ile, too bad; you have to forward declare it or you get a compiler error.<b=
r><br>This is true everywhere... <i>except</i> in a class definition. There=
, you are allowed to talk about names that appear later in the class. This =
was <i>specifically added</i> to the language, because nowhere else does th=
e language work this way. Adding this feature made compilers rather more di=
fficult to write. But it makes code much easier to write, since you <i>don&=
#39;t</i> have to declare every member before writing the definitions of th=
ose member functions. Not to mention, it makes things like CRTP-mixins poss=
ible, where a base class can cast itself to the derived class type and acce=
ss its members; that would not be possible if C++ didn&#39;t allow delayed =
name lookup.<br><br>In short, it is a very good thing that C++ allows this.=
<br><br>My feeling is that if you need to forward declare a member function=
, you ought to just define it outside of the class definition. Yes, I know =
that this makes it rather difficult for template classes, due to the gigant=
ic prefix associated with the function name. But we have C++ tools for crea=
ting member function definitions automatically nowadays. It&#39;s not that =
big of a deal.<br></div></div>

<p></p>

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

------=_Part_62_1264802048.1447599957443--
------=_Part_61_1371115111.1447599957442--

.


Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 16 Nov 2015 10:13:13 -0500
Raw View
On 2015-11-15 05:24, Andrew Tomazos wrote:
> I think there is a good idea in here.
>
> Rather than making this narrow change, I'd prefer to see a larger proposal
> for allowing a separate forward declaration of the public interface of a
> class from the definition of the class.
>
> Perhaps something like:
>
> public class MyClass {
>   MyClass(int = 0);
>
>   int val() const;
>   void val(int);
> };
>
> class MyClass {
> public:
>   MyClass(int = 0) { ... }
>
>   int val() const { ... }
>   void val(int) { ... }
>
> private:
>   int val_;
> };

I don't think this will work. The size of the class needs to be known
publicly. Adding NSDM's after the fact will break things. (And adding
any other members opens a can of worms to abuse / circumvention of
access protections.)

That said, my first thought reading through the OP's post was to have a
way to provide method definitions that doesn't require repeating the
class name (and template) boiler plate. Something closer to a namespace
block might be better for this purpose. Ideally, access statements would
be forbidden (and unnecessary) in this context, and only definitions of
previously declared members would be allowed. IOW, a way to turn this:

  A::A() { ... }
  int A::foo(int) { ... }
  int A::bar = ...;

....into this:

  <block scope for A> {
  A() { ... }
  int foo(int) { ... }
  int bar = ...;
  }

The syntax for introducing the block scope might be something like
'template<typename T> class namespace Bar<T>' (template example given
for completeness; omit template stuff for non-template classes).

This is a syntax change, but NOT a semantic change; just like a
namespace, the effect is simply as if everything in the scope is
implicitly prefixed with the class decoration.

(Say, wasn't there a request for template block scopes already?)

--
Matthew

--

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

.


Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 16 Nov 2015 12:19:31 -0500
Raw View
On 2015-11-16 11:59, Andrew Tomazos wrote:
> On Mon, Nov 16, 2015 at 4:13 PM, Matthew Woehlke wrote:
>> On 2015-11-15 05:24, Andrew Tomazos wrote:
>>> I think there is a good idea in here.
>>>
>>> Rather than making this narrow change, I'd prefer to see a larger
>>> proposal for allowing a separate forward declaration of the
>>> public interface of a class from the definition of the class.
>>>
>>> Perhaps something like:
>>>
>>> public class MyClass {
>>>   MyClass(int = 0);
>>>
>>>   int val() const;
>>>   void val(int);
>>> };
>>>
>>> class MyClass {
>>> public:
>>>   MyClass(int = 0) { ... }
>>>
>>>   int val() const { ... }
>>>   void val(int) { ... }
>>>
>>> private:
>>>   int val_;
>>> };
>>
>> I don't think this will work. The size of the class needs to be known
>> publicly. Adding NSDM's after the fact will break things. (And adding
>> any other members opens a can of worms to abuse / circumvention of
>> access protections.)
>
> You've misunderstood how it works.  The class isn't complete (as usual)
> until the class definition (the second thing).

Ah. Yes, I missed that. Okay, well then, I dislike it for other reasons.
Mainly, it does nothing to solve the redundancy when the method
definitions are not inline in the class definition (e.g. when they are
in a .cpp file). And yes, even for template classes, that can happen,
either ".tpp" pattern, or due to explicit instantiation.

In fact, I have trouble seeing how your suggestion is in any meaningful
way an improvement over what we have now. All you've really accomplished
is adding a closing brace before the private members. That may look
pretty, but it hardly seems worth a non-trivial change to both syntax
and semantics.

I much prefer my suggestion which does not change semantics, and
reflects existing syntax for namespaces.

--
Matthew

--

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

.


Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 16 Nov 2015 14:41:14 -0500
Raw View
On 2015-11-16 13:58, Andrew Tomazos wrote:
> On Mon, Nov 16, 2015 at 6:19 PM, Matthew Woehlke wrote:
>> Mainly, it does nothing to solve the redundancy when the method
>> definitions are not inline in the class definition (e.g. when they are
>> in a .cpp file). And yes, even for template classes, that can happen,
>> either ".tpp" pattern, or due to explicit instantiation.
>
> I'm not sure what you mean by "solve the redundancy".  What redundancy?  If
> you mean the redundancy between an interface and implementation - that's a
> feature, not a bug.

  template <...> class Foo { ...declarations... };
  template <...> Foo<...>::Foo(...) { ... }

All that template boilerplate is annoying. This was a major point of the
OP's original suggestion (with which I happen to agree).

>> In fact, I have trouble seeing how your suggestion is in any meaningful
>> way an improvement over what we have now. All you've really accomplished
>> is adding a closing brace before the private members. That may look
>> pretty, but it hardly seems worth a non-trivial change to both syntax
>> and semantics.
>
> It's more than adding a closing brace before the private members.

In what way? I don't see how your feature adds anything (excluding
support for duplicate member declarations) except:

  public // new
  class Foo
  {
    // declarations of public methods
  }; // new
  class Foo // new
  { // new
    // class definition
  };

> In particular the forward declaration of the public interface wouldn't be
> permitted to contain any definitions, it's purely a declaration.
>
> It doesn't change any semantics.

That *is* a semantic change (at least, what I'm considering a semantic
change). You have added an entirely new concept ("class interface
declaration") with new semantics ("may not contain definitions").

My suggestion just hoists a bunch of prefix code to a block scope,
without changing what is legal within that scope. The *existence* of
said scope is arguably semantic (although it's equivalent to a namespace
scope, which is an existing construct), but the semantics of the scope
itself are not new.

> For example, take a look at any of the class definitions of the containers
> in any standard library implementation.
>
> They are 1000+ lines long and even the public sections (plural) are 90%
> implementation details.

And why do you expect your proposal to "fix" this? That problem exists
because library writers *don't care*. If they did, they would not have
inline definitions and would keep the class private and public members
separate. Both of which *can be done in C++03*. Why do you expect that
providing a new way to do something they aren't interested in is going
to help?

--
Matthew

--

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

.


Author: =?UTF-8?Q?P=C3=A9ter?= <mitchnull@gmail.com>
Date: Tue, 17 Nov 2015 00:01:52 -0800 (PST)
Raw View
------=_Part_3263_97818969.1447747312423
Content-Type: multipart/alternative;
 boundary="----=_Part_3264_1580242627.1447747312423"

------=_Part_3264_1580242627.1447747312423
Content-Type: text/plain; charset=UTF-8



On Monday, November 16, 2015 at 4:13:30 PM UTC+1, Matthew Woehlke wrote:
>
> On 2015-11-15 05:24, Andrew Tomazos wrote:
> > I think there is a good idea in here.
> >
> > Rather than making this narrow change, I'd prefer to see a larger
> proposal
> > for allowing a separate forward declaration of the public interface of a
> > class from the definition of the class.
> >
> > Perhaps something like:
> >
> > public class MyClass {
> >   MyClass(int = 0);
> >
> >   int val() const;
> >   void val(int);
> > };
> >
> > class MyClass {
> > public:
> >   MyClass(int = 0) { ... }
> >
> >   int val() const { ... }
> >   void val(int) { ... }
> >
> > private:
> >   int val_;
> > };
>
> I don't think this will work. The size of the class needs to be known
> publicly. Adding NSDM's after the fact will break things. (And adding
> any other members opens a can of worms to abuse / circumvention of
> access protections.)
>
> That said, my first thought reading through the OP's post was to have a
> way to provide method definitions that doesn't require repeating the
> class name (and template) boiler plate. Something closer to a namespace
> block might be better for this purpose. Ideally, access statements would
> be forbidden (and unnecessary) in this context, and only definitions of
> previously declared members would be allowed. IOW, a way to turn this:
>
>   A::A() { ... }
>   int A::foo(int) { ... }
>   int A::bar = ...;
>
> ...into this:
>
>   <block scope for A> {
>   A() { ... }
>   int foo(int) { ... }
>   int bar = ...;
>   }
>
> The syntax for introducing the block scope might be something like
> 'template<typename T> class namespace Bar<T>' (template example given
> for completeness; omit template stuff for non-template classes).
>
> This is a syntax change, but NOT a semantic change; just like a
> namespace, the effect is simply as if everything in the scope is
> implicitly prefixed with the class decoration.
>
> (Say, wasn't there a request for template block scopes already?)
>

This has come up already in the "Fixing the private method issue" thread,
my idea was pretty similar to yours (see
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/xukd1mgd21I/uHjx6YR_EnQJ
and
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/xukd1mgd21I/gh5W0KS856oJ).
 Unfortunately that got nowhere because it sorta got bogged down with the
more ambitious goal of adding "real" private methods.  I'd be happy if the
"class namespace" proposal would move forward either alone, or with the
addition of extra private methods as discussed in the above thread.


--

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

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

<br><br>On Monday, November 16, 2015 at 4:13:30 PM UTC+1, Matthew Woehlke w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-11-15 05:24, Andr=
ew Tomazos wrote:
<br>&gt; I think there is a good idea in here.
<br>&gt;=20
<br>&gt; Rather than making this narrow change, I&#39;d prefer to see a lar=
ger proposal
<br>&gt; for allowing a separate forward declaration of the public interfac=
e of a
<br>&gt; class from the definition of the class.
<br>&gt;=20
<br>&gt; Perhaps something like:
<br>&gt;=20
<br>&gt; public class MyClass {
<br>&gt; =C2=A0 MyClass(int =3D 0);
<br>&gt;=20
<br>&gt; =C2=A0 int val() const;
<br>&gt; =C2=A0 void val(int);
<br>&gt; };
<br>&gt;=20
<br>&gt; class MyClass {
<br>&gt; public:
<br>&gt; =C2=A0 MyClass(int =3D 0) { ... }
<br>&gt;=20
<br>&gt; =C2=A0 int val() const { ... }
<br>&gt; =C2=A0 void val(int) { ... }
<br>&gt;=20
<br>&gt; private:
<br>&gt; =C2=A0 int val_;
<br>&gt; };
<br>
<br>I don&#39;t think this will work. The size of the class needs to be kno=
wn
<br>publicly. Adding NSDM&#39;s after the fact will break things. (And addi=
ng
<br>any other members opens a can of worms to abuse / circumvention of
<br>access protections.)
<br>
<br>That said, my first thought reading through the OP&#39;s post was to ha=
ve a
<br>way to provide method definitions that doesn&#39;t require repeating th=
e
<br>class name (and template) boiler plate. Something closer to a namespace
<br>block might be better for this purpose. Ideally, access statements woul=
d
<br>be forbidden (and unnecessary) in this context, and only definitions of
<br>previously declared members would be allowed. IOW, a way to turn this:
<br>
<br>=C2=A0 A::A() { ... }
<br>=C2=A0 int A::foo(int) { ... }
<br>=C2=A0 int A::bar =3D ...;
<br>
<br>...into this:
<br>
<br>=C2=A0 &lt;block scope for A&gt; {
<br>=C2=A0 A() { ... }
<br>=C2=A0 int foo(int) { ... }
<br>=C2=A0 int bar =3D ...;
<br>=C2=A0 }
<br>
<br>The syntax for introducing the block scope might be something like
<br>&#39;template&lt;typename T&gt; class namespace Bar&lt;T&gt;&#39; (temp=
late example given
<br>for completeness; omit template stuff for non-template classes).
<br>
<br>This is a syntax change, but NOT a semantic change; just like a
<br>namespace, the effect is simply as if everything in the scope is
<br>implicitly prefixed with the class decoration.
<br>
<br>(Say, wasn&#39;t there a request for template block scopes already?)
<br></blockquote><div>=C2=A0</div><div>This has come up already in the &quo=
t;Fixing the private method issue&quot; thread, my idea was pretty similar =
to yours (see https://groups.google.com/a/isocpp.org/d/msg/std-proposals/xu=
kd1mgd21I/uHjx6YR_EnQJ and https://groups.google.com/a/isocpp.org/d/msg/std=
-proposals/xukd1mgd21I/gh5W0KS856oJ). =C2=A0Unfortunately that got nowhere =
because it sorta got bogged down with the more ambitious goal of adding &qu=
ot;real&quot; private methods. =C2=A0I&#39;d be happy if the &quot;class na=
mespace&quot; proposal would move forward either alone, or with the additio=
n of extra private methods as discussed in the above thread.</div><div>=C2=
=A0</div>

<p></p>

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

------=_Part_3264_1580242627.1447747312423--
------=_Part_3263_97818969.1447747312423--

.


Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 17 Nov 2015 10:48:27 -0500
Raw View
On 2015-11-17 06:09, Andrew Tomazos wrote:
> On Mon, Nov 16, 2015 at 8:41 PM, Matthew Woehlke wrote:
>> On 2015-11-16 13:58, Andrew Tomazos wrote:
>>> For example, take a look at any of the class definitions of the
>>> containers in any standard library implementation.
>>>
>>> They are 1000+ lines long and even the public sections (plural) are 90%
>>> implementation details.
>>
>> And why do you expect your proposal to "fix" this? That problem exists
>> because library writers *don't care*.
>
> Defining members inside the class definition is much
> easier because the enclosing class only needs to be declared once and is
> thereafter implicit for the scope.

....but then you *must* provide definitions *in the header*. In
non-template cases, this is usually a very bad thing to do. Even in some
*template* cases it is undesirable. This makes your proposal of very
limited utility in the majority of cases.

> The current technique of defining members outside the class is onerous.  In
> particular you need to redeclare the enclosing class (and template) for
> each member defined.

I agree the *current* situation is less than ideal, but did you *read*
my suggestion? Because this is *exactly* the problem I address...

That said, I still have doubts that standard libraries are going to
change. It may be onerous, but code is written once and read many times.
If standard library authors cared about readability, they would make the
effort, even if it is currently "onerous".

For that matter, there's nothing stopping anyone from doing exactly like
your proposal, only in a comment, right now. Again... *if* they cared.

> Given that it is less onerous, I expect it to be more popular than not
> using inline member definitions.

Or... my suggestion makes *non-inline* definitions, which *are the right
thing to do* more often than not, equally less onerous.

> (Note by "member definitions" I am not only thinking about inline member
> functions.  I am also thinking about nested types, typedefs/aliases, member
> variable initializers and member templates.)

Nested types can be forward declared already. How many type aliases a)
do you *want* to be opaque, and b) have an RHS that is so long as to
cause readability problems if they appear in the "public interface
declaration"?

(You'll note I didn't mention member initializers, even though the
second half of the type alias argument applies here too. IMO it would be
nice, albeit probably an orthogonal feature, if NSDM initializers could
appear in a separate TU in the manner of SDM's. These would only be
effective for non-default ctors whose definitions follow said
initializers, but that shouldn't be a problem. Allowing this has similar
benefits to non-inline member function definitions.)

--
Matthew

--

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

.


Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 17 Nov 2015 11:54:53 -0500
Raw View
On 2015-11-17 11:22, Russell Greene wrote:
> One small issue I have with this is the current method lets you put
> includes that only the inline functions rely on after the class
> declaration. With this proposal this isn't possible.

Why not? (Note: you said "function", specifically.)

This would be the case for type aliases (and member variable
initializers, although see my previous comment). It is *not* true for
method definitions or nested types, as neither of those need to appear
in the class definition (nor is there AFAIK any specific technical
benefit to having them inline).

Personally, I only *rarely* see includes other than at the top of a file
(and those usually in files that are a terrific mess of preprocessor
conditional logic).


Example:

  class MyClass
  {
  public:
    MyClass(int = 0);
    int val() const;
    void set_val(int);

  private:
    int m_val;
  };

  // place "private" includes here

  namespace class MyClass
  {
    MyClass(int) { ... }
    int val() const { ... }
    void set_val(int) { ... }
  }

--
Matthew

--

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

.


Author: Evan Teran <evan.teran@gmail.com>
Date: Tue, 17 Nov 2015 16:10:42 -0800 (PST)
Raw View
------=_Part_3712_1382086144.1447805442553
Content-Type: multipart/alternative;
 boundary="----=_Part_3713_200351750.1447805442553"

------=_Part_3713_200351750.1447805442553
Content-Type: text/plain; charset=UTF-8


>
>
> Example:
>
>   class MyClass
>   {
>   public:
>     MyClass(int = 0);
>     int val() const;
>     void set_val(int);
>
>   private:
>     int m_val;
>   };
>
>   // place "private" includes here
>
>   namespace class MyClass
>   {
>     MyClass(int) { ... }
>     int val() const { ... }
>     void set_val(int) { ... }
>   }
>


I think this new syntax idea potentially provides real benefit. I like it a
lot. One the motivating pain points of templates is that if you separate
declaration from definition, you have to deal with very verbose template
syntax. For example:



template <class Ch, class Tr>
class String {
public:
    void some_method();
    void another_method();
};


template <class Ch, class Tr>
void String<Ch, Tr>::some_method() {
    // ...
}

template <class Ch, class Tr>
void String<Ch, Tr>::another_method() {
    // ...
}


If this could instead be written like the following code, then it would be
simpler to read, write and maintain:

template <class Ch, class Tr>
class String {
public:
    void some_method();
};


template <class Ch, class Tr>
namespace class String {

void some_method() {
    // ...
}


void another_method() {
    // ...
}
}

In my opinion this syntax or something similar to it, is:

1. easier to read, we get to drop the "noise" of the repeated template
parameters, but it is still explicit enough to know what it means

2. easier to write, for single functions, there is a slight increase in
code, but for a large group of functions, it can drastically reduce the
amount of code while not sacrificing clarity.

3. easier to maintain, if a template parameter changes, we would need to
change it far fewer places (two places instead of once per non-inline
method)

Like I said, I would very much welcome this as as option as long as the
previous syntax doesn't get removed :-).

--

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

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>Example:
<br>
<br>=C2=A0 class MyClass
<br>=C2=A0 {
<br>=C2=A0 public:
<br>=C2=A0 =C2=A0 MyClass(int =3D 0);
<br>=C2=A0 =C2=A0 int val() const;
<br>=C2=A0 =C2=A0 void set_val(int);
<br>
<br>=C2=A0 private:
<br>=C2=A0 =C2=A0 int m_val;
<br>=C2=A0 };
<br>
<br>=C2=A0 // place &quot;private&quot; includes here
<br>
<br>=C2=A0 namespace class MyClass
<br>=C2=A0 {
<br>=C2=A0 =C2=A0 MyClass(int) { ... }
<br>=C2=A0 =C2=A0 int val() const { ... }
<br>=C2=A0 =C2=A0 void set_val(int) { ... }
<br>=C2=A0 }
<br>=C2=A0</blockquote><div><br></div><div>I think this new syntax idea pot=
entially provides real benefit. I like it a lot. One the motivating pain po=
ints of templates is that if you separate declaration from definition, you =
have to deal with very verbose template syntax. For example:</div><div><br>=
</div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 1=
87); word-wrap: break-word; background-color: rgb(250, 250, 250);"><code cl=
ass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">template</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </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-p=
rettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">=
Ch</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
606;" class=3D"styled-by-prettify">Tr</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">class</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify"=
>String</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">public</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 =C2=A0 </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> some_method</span><span style=3D"colo=
r: #660;" 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"col=
or: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> another_method</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> <br><br><br></span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">template</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Ch</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" clas=
s=3D"styled-by-prettify">Tr</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #606;" class=3D"styled-by-prettify">String</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">Ch</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" =
class=3D"styled-by-prettify">Tr</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&gt;::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">some_method</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">()</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 =C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>// ...</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </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: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Ch</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">cl=
ass</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">Tr</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">String</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Ch</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Tr</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;::</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">another_method</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"co=
lor: #800;" class=3D"styled-by-prettify">// ...</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><div><br></div><div><=
br></div><div>If this could instead be written like the following code, the=
n it would be simpler to read, write and maintain:</div><div><br></div><div=
 class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-=
wrap: break-word; background-color: rgb(250, 250, 250);"><code class=3D"pre=
ttyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">template</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">class</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Ch</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;"=
 class=3D"styled-by-prettify">Tr</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">class</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">St=
ring</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">public</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> some_method</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> <br><br><br></span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">template</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #606;" class=3D"styled-by-prettify">Ch</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Tr</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">namespace</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">class<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">String</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> some_method</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"s=
tyled-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 =C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-p=
rettify">// ...</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br><b=
r></span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> another_metho=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">// ...</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span></div></code></div><div><span class=3D"styl=
ed-by-prettify" style=3D"font-family: monospace; color: rgb(102, 102, 0); b=
ackground-color: rgb(250, 250, 250);"><br></span></div>In my opinion this s=
yntax or something similar to it, is:<div><br></div><div>1. easier to read,=
 we get to drop the &quot;noise&quot; of the repeated template parameters, =
but it is still explicit enough to know what it means</div><div><br></div><=
div>2. easier to write, for single functions, there is a slight increase in=
 code, but for a large group of functions, it can drastically reduce the am=
ount of code while not sacrificing clarity.</div><div><br></div><div>3. eas=
ier to maintain, if a template parameter changes, we would need to change i=
t far fewer places (two places instead of once per non-inline method)</div>=
<div><br></div><div>Like I said, I would very much welcome this as as optio=
n as long as the previous syntax doesn&#39;t get removed :-).</div></div>

<p></p>

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

------=_Part_3713_200351750.1447805442553--
------=_Part_3712_1382086144.1447805442553--

.


Author: Larry Evans <cppljevans@suddenlink.net>
Date: Wed, 18 Nov 2015 03:05:09 -0600
Raw View
On 11/17/2015 10:11 PM, Russell Greene wrote:
> I agree. This is a really good syntax, I was confused with the proposal
> before.
>
> I would really like to see this as I am creating a large library that
> has one very large template class, and currently I have the functions in
> the class declaration, which is sacrificing clarity.
>
> I don't really like the use of namespace in the syntax though. It makes
> it seem like it actually has to do with namespaces, which
> it doesn't.

I think someone proposed use of public instead of namespace.
Would you prefer that?

I think people are just trying to avoid another keyword and
sacrificing a *little* readablity for that purpose.

>
> -Russell
>
> On Tue, Nov 17, 2015 at 5:10 PM Evan Teran <evan.teran@gmail.com
> <mailto:evan.teran@gmail.com>> wrote:
>
>
>         Example:
>
>           class MyClass
>           {
>           public:
>             MyClass(int = 0);
>             int val() const;
>             void set_val(int);
>
>           private:
>             int m_val;
>           };
>
>           // place "private" includes here
>
>           namespace class MyClass
>           {
>             MyClass(int) { ... }
>             int val() const { ... }
>             void set_val(int) { ... }
>           }
>
>
>
>     I think this new syntax idea potentially provides real benefit. I
>     like it a lot. One the motivating pain points of templates is that
>     if you separate declaration from definition, you have to deal with
>     very verbose template syntax. For example:
>
>
>     template<classCh,classTr>
>     class String{
>     public:
>         void some_method();
>         void another_method();
>     };
>
>
>     template<classCh,classTr>
>     void String<Ch,Tr>::some_method(){
>         // ...
>     }
>
>     template<classCh,classTr>
>     void String<Ch,Tr>::another_method(){
>         // ...
>     }
>
>
>     If this could instead be written like the following code, then it
>     would be simpler to read, write and maintain:
>
>     template<classCh,classTr>
>     class String{
>     public:
>         void some_method();
>     };
>
>
>     template<classCh,classTr>
>     namespace class String{
>
>     void some_method(){
>         // ...
>     }
>
>
>     void another_method(){
>         // ...
>     }
>     }
>
>     In my opinion this syntax or something similar to it, is:
>
>     1. easier to read, we get to drop the "noise" of the repeated
>     template parameters, but it is still explicit enough to know what it
>     means
>
>     2. easier to write, for single functions, there is a slight increase
>     in code, but for a large group of functions, it can drastically
>     reduce the amount of code while not sacrificing clarity.
>
>     3. easier to maintain, if a template parameter changes, we would
>     need to change it far fewer places (two places instead of once per
>     non-inline method)
>
>     Like I said, I would very much welcome this as as option as long as
>     the previous syntax doesn't get removed :-).

Yes!  I welcome this syntax simplication also.

However, what about static members?  For example:

     template<classCh,classTr>
     class String{
     public:
         String(classCh ch);//new
         void some_method();

         template<classCh Ch>
         static strch;//new
     };


     template<classCh,classTr>
     namespace class String{

         String(classCh ch){
         // ...
         }

         void some_method(){
         // ...
         }

         void another_method(){
         // ...
         }

         template<classCh Ch>
         static strch(Ch);
     };

Would this be allowed under this proposal?

-regards,
Larry


--

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

.


Author: Larry Evans <cppljevans@suddenlink.net>
Date: Wed, 18 Nov 2015 03:17:48 -0600
Raw View
On 11/18/2015 03:05 AM, Larry Evans wrote:
> On 11/17/2015 10:11 PM, Russell Greene wrote:
>> I agree. This is a really good syntax, I was confused with the proposal
>> before.
>>
>> I would really like to see this as I am creating a large library that
>> has one very large template class, and currently I have the functions in
>> the class declaration, which is sacrificing clarity.
>>
>> I don't really like the use of namespace in the syntax though. It makes
>> it seem like it actually has to do with namespaces, which
>> it doesn't.
>
> I think someone proposed use of public instead of namespace.
> Would you prefer that?
>
> I think people are just trying to avoid another keyword and
> sacrificing a *little* readablity for that purpose.
>
>>
>> -Russell
>>
>> On Tue, Nov 17, 2015 at 5:10 PM Evan Teran <evan.teran@gmail.com
>> <mailto:evan.teran@gmail.com>> wrote:
>>
>>
>>         Example:
>>
>>           class MyClass
>>           {
>>           public:
>>             MyClass(int = 0);
>>             int val() const;
>>             void set_val(int);
>>
>>           private:
>>             int m_val;
>>           };
>>
>>           // place "private" includes here
>>
>>           namespace class MyClass
>>           {
>>             MyClass(int) { ... }
>>             int val() const { ... }
>>             void set_val(int) { ... }
>>           }
>>
>>
>>
>>     I think this new syntax idea potentially provides real benefit. I
>>     like it a lot. One the motivating pain points of templates is that
>>     if you separate declaration from definition, you have to deal with
>>     very verbose template syntax. For example:
>>
>>
>>     template<classCh,classTr>
>>     class String{
>>     public:
>>         void some_method();
>>         void another_method();
>>     };
>>
>>
>>     template<classCh,classTr>
>>     void String<Ch,Tr>::some_method(){
>>         // ...
>>     }
>>
>>     template<classCh,classTr>
>>     void String<Ch,Tr>::another_method(){
>>         // ...
>>     }
>>
>>
>>     If this could instead be written like the following code, then it
>>     would be simpler to read, write and maintain:
>>
>>     template<classCh,classTr>
>>     class String{
>>     public:
>>         void some_method();
>>     };
>>
>>
>>     template<classCh,classTr>
>>     namespace class String{
>>
>>     void some_method(){
>>         // ...
>>     }
>>
>>
>>     void another_method(){
>>         // ...
>>     }
>>     }
>>
>>     In my opinion this syntax or something similar to it, is:
>>
>>     1. easier to read, we get to drop the "noise" of the repeated
>>     template parameters, but it is still explicit enough to know what it
>>     means
>>
>>     2. easier to write, for single functions, there is a slight increase
>>     in code, but for a large group of functions, it can drastically
>>     reduce the amount of code while not sacrificing clarity.
>>
>>     3. easier to maintain, if a template parameter changes, we would
>>     need to change it far fewer places (two places instead of once per
>>     non-inline method)
>>
>>     Like I said, I would very much welcome this as as option as long as
>>     the previous syntax doesn't get removed :-).
>
> Yes!  I welcome this syntax simplication also.
>
> However, what about static members?  For example:
OOPS.  Sorry for typos:
>
>      template<classCh,classTr>
>      class String{
>      public:
>          String(classCh ch);//new
>          void some_method();
Should include:
           void another_method();
>
>          template<classCh Ch>
>          static strch;//new
Should be:
           static String strch;//new
>      };
>
>
>      template<classCh,classTr>
>      namespace class String{
>
>          String(classCh ch){
>          // ...
>          }
>
>          void some_method(){
>          // ...
>          }
>
>          void another_method(){
>          // ...
>          }
>
>          template<classCh Ch>
>          static strch(Ch);
Should be:
           static String strch(Ch);
>      };
>
> Would this be allowed under this proposal?
>
> -regards,
> Larry
>
>


--

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

.


Author: Evan Teran <evan.teran@gmail.com>
Date: Wed, 18 Nov 2015 04:48:10 -0800 (PST)
Raw View
------=_Part_4627_1606485395.1447850890970
Content-Type: multipart/alternative;
 boundary="----=_Part_4628_1006614742.1447850890972"

------=_Part_4628_1006614742.1447850890972
Content-Type: text/plain; charset=UTF-8

My suggestion is for something like:

template <class Ch, class Tr>
namespace class String {
void member() {}
}


to be exactly equivalent to:

template <class Ch, class Tr>
void String<Ch, Tr>::member() {}

So for the example of a static members, constructors, etc, this would
continue to be equivalent, for example:


// typical class declaration
template <class Ch, class Tr>
class String {
public:
 String(Ch ch);
 void some_method();
 void another_method();
 static String strch(Ch ch);
};




// non-inline definition using proposed syntax
template<class Ch, class Tr>
namespace class String { /* I'm ok with any keyword besides "namespace" */


String(Ch ch) {
 // ...
}


void some_method() {
 // ...
}


void another_method() {
 // ...
}


String strch(Ch) {
 // ...
}


}


which would be the same as writing this code:

template <class Ch, class Tr>
String<Ch, Tr>::String(Ch ch) {
 // ...
}


template <class Ch, class Tr>
void String<Ch, Tr>::some_method() {
 // ...
}


template <class Ch, class Tr>
void String<Ch, Tr>::another_method() {
 // ...
}


template <class Ch, class Tr>
String<Ch, Tr> String<Ch, Tr>::strch(Ch) {
 // ...
}



On Wednesday, November 18, 2015 at 4:18:06 AM UTC-5, Larry Evans wrote:
>
> On 11/18/2015 03:05 AM, Larry Evans wrote:
> > On 11/17/2015 10:11 PM, Russell Greene wrote:
> >> I agree. This is a really good syntax, I was confused with the proposal
> >> before.
> >>
> >> I would really like to see this as I am creating a large library that
> >> has one very large template class, and currently I have the functions
> in
> >> the class declaration, which is sacrificing clarity.
> >>
> >> I don't really like the use of namespace in the syntax though. It makes
> >> it seem like it actually has to do with namespaces, which
> >> it doesn't.
> >
> > I think someone proposed use of public instead of namespace.
> > Would you prefer that?
> >
> > I think people are just trying to avoid another keyword and
> > sacrificing a *little* readablity for that purpose.
> >
> >>
> >> -Russell
> >>
> >> On Tue, Nov 17, 2015 at 5:10 PM Evan Teran <evan....@gmail.com
> <javascript:>
> >> <mailto:evan....@gmail.com <javascript:>>> wrote:
> >>
> >>
> >>         Example:
> >>
> >>           class MyClass
> >>           {
> >>           public:
> >>             MyClass(int = 0);
> >>             int val() const;
> >>             void set_val(int);
> >>
> >>           private:
> >>             int m_val;
> >>           };
> >>
> >>           // place "private" includes here
> >>
> >>           namespace class MyClass
> >>           {
> >>             MyClass(int) { ... }
> >>             int val() const { ... }
> >>             void set_val(int) { ... }
> >>           }
> >>
> >>
> >>
> >>     I think this new syntax idea potentially provides real benefit. I
> >>     like it a lot. One the motivating pain points of templates is that
> >>     if you separate declaration from definition, you have to deal with
> >>     very verbose template syntax. For example:
> >>
> >>
> >>     template<classCh,classTr>
> >>     class String{
> >>     public:
> >>         void some_method();
> >>         void another_method();
> >>     };
> >>
> >>
> >>     template<classCh,classTr>
> >>     void String<Ch,Tr>::some_method(){
> >>         // ...
> >>     }
> >>
> >>     template<classCh,classTr>
> >>     void String<Ch,Tr>::another_method(){
> >>         // ...
> >>     }
> >>
> >>
> >>     If this could instead be written like the following code, then it
> >>     would be simpler to read, write and maintain:
> >>
> >>     template<classCh,classTr>
> >>     class String{
> >>     public:
> >>         void some_method();
> >>     };
> >>
> >>
> >>     template<classCh,classTr>
> >>     namespace class String{
> >>
> >>     void some_method(){
> >>         // ...
> >>     }
> >>
> >>
> >>     void another_method(){
> >>         // ...
> >>     }
> >>     }
> >>
> >>     In my opinion this syntax or something similar to it, is:
> >>
> >>     1. easier to read, we get to drop the "noise" of the repeated
> >>     template parameters, but it is still explicit enough to know what
> it
> >>     means
> >>
> >>     2. easier to write, for single functions, there is a slight
> increase
> >>     in code, but for a large group of functions, it can drastically
> >>     reduce the amount of code while not sacrificing clarity.
> >>
> >>     3. easier to maintain, if a template parameter changes, we would
> >>     need to change it far fewer places (two places instead of once per
> >>     non-inline method)
> >>
> >>     Like I said, I would very much welcome this as as option as long as
> >>     the previous syntax doesn't get removed :-).
> >
> > Yes!  I welcome this syntax simplication also.
> >
> > However, what about static members?  For example:
> OOPS.  Sorry for typos:
> >
> >      template<classCh,classTr>
> >      class String{
> >      public:
> >          String(classCh ch);//new
> >          void some_method();
> Should include:
>            void another_method();
> >
> >          template<classCh Ch>
> >          static strch;//new
> Should be:
>            static String strch;//new
> >      };
> >
> >
> >      template<classCh,classTr>
> >      namespace class String{
> >
> >          String(classCh ch){
> >          // ...
> >          }
> >
> >          void some_method(){
> >          // ...
> >          }
> >
> >          void another_method(){
> >          // ...
> >          }
> >
> >          template<classCh Ch>
> >          static strch(Ch);
> Should be:
>            static String strch(Ch);
> >      };
> >
> > Would this be allowed under this proposal?
> >
> > -regards,
> > Larry
> >
> >
>
>
>

--

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

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

<div dir=3D"ltr">My suggestion is for something like:<div><br></div><div cl=
ass=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wra=
p: break-word; background-color: rgb(250, 250, 250);"><code class=3D"pretty=
print"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"=
styled-by-prettify">template</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #606;" class=3D"styled-by-prettify">Ch</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Tr</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">namespace</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">class<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">String</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> member</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">()</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></s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></div=
></code></div><div><br><br></div><div>to be exactly equivalent to:<br></div=
><div><br></div><div><div class=3D"prettyprint" style=3D"border: 1px solid =
rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, =
250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </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;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Ch</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">class</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #606;" class=3D"styled-by-prettify">Tr</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">String</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">Ch</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">Tr</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&gt;::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">member</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">{}</span></div></code></div><div><br></div></div>=
<div>So for the example of a static members, constructors, etc, this would =
continue to be equivalent, for example:</div><div><br></div><div><br></div>=
<div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 18=
7); word-wrap: break-word; background-color: rgb(250, 250, 250);"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #800=
;" class=3D"styled-by-prettify">// typical class declaration</span><span st=
yle=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"c=
olor: #000;" class=3D"styled-by-prettify"> </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"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Ch</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #606;" class=3D"styled-by-prettify">Tr</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> <br></span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"sty=
led-by-prettify">String</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <br>=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">public</sp=
an><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: #606;" class=3D"styled-by-prettify">String</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #606;" class=3D"styled-by-prettify">Ch</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> ch</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>=C2=A0</span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> some_method</span><span style=3D"color: #660;" class=3D"styled-=
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-pre=
ttify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> another_method</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">();</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">s=
tatic</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #606;" class=3D"styled-by-prettify">String</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> strch</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #606;" class=3D"styled-by-prettify">Ch</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> ch</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> <br><br><br><br><br></span><span style=3D"color: #800;" class=3D"st=
yled-by-prettify">// non-inline definition using proposed syntax</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">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"> </span><span style=3D"color: #606;" cl=
ass=3D"styled-by-prettify">Ch</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">Tr</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> <br></span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">namespace</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"s=
tyled-by-prettify">String</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #800;" class=3D"styled-by-prettify">/* I&#39;m o=
k with any keyword besides &quot;namespace&quot; */</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br><br><br></span><span style=3D"=
color: #606;" class=3D"styled-by-prettify">String</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #606;"=
 class=3D"styled-by-prettify">Ch</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> ch</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </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: #800;" class=3D"styled-by-prettify">// ... =
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> <br><br><br></span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> some_method</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"co=
lor: #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: #800;" clas=
s=3D"styled-by-prettify">// ... </span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> <br><br><br></span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> another_method</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> <br>=C2=A0</sp=
an><span style=3D"color: #800;" class=3D"styled-by-prettify">// ... </span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> <br><br><br></span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">String</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> strch</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #606;"=
 class=3D"styled-by-prettify">Ch</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>=C2=A0</span><span style=3D"color: #800;" class=3D"styled-by-prettify">// =
....</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br><br><br></span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code=
></div><div><br></div><div><br></div><div>which would be the same as writin=
g this code:</div><div><br></div><div class=3D"prettyprint" style=3D"border=
: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-color: rg=
b(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint=
"><span style=3D"color: #008;" class=3D"styled-by-prettify">template</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=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"> </span><span style=3D"color: #606;" =
class=3D"styled-by-prettify">Ch</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #606;" class=3D"styled-by-prettify">Tr</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #606;" class=3D"styled-by-prettify">String</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">Ch</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pr=
ettify">Tr</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&gt;::</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Stri=
ng</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #606;" class=3D"styled-by-prettify">Ch</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> ch</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> <br>=C2=A0</span><span style=3D"color: #800;" class=3D"sty=
led-by-prettify">// ... </span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
<br><br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">template</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Ch</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">class</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pre=
ttify">Tr</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">String</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color:=
 #606;" class=3D"styled-by-prettify">Ch</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by=
-prettify">Tr</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&gt;::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">s=
ome_method</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> <br>=C2=A0</span><span st=
yle=3D"color: #800;" class=3D"styled-by-prettify">// ... </span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> <br><br><br></span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">template</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">class</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pretti=
fy">Ch</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">class</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #606;" class=3D"styled-by-prettify">Tr</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pretti=
fy">String</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&lt;</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Ch</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #606;" class=3D"styled-by-prettify">Tr</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&gt;::</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">another_method</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> <br>=C2=A0</span><span style=3D"color: #800;" class=3D"styled-by-=
prettify">// ... </span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <br><br=
><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">templ=
ate</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </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 styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #606;" class=3D"styled-by-prettify">Ch</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">class</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify"=
>Tr</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">String</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Ch</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D=
"styled-by-prettify">Tr</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">St=
ring</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</=
span><span style=3D"color: #606;" class=3D"styled-by-prettify">Ch</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">Tr</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&gt;::</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">strch</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">Ch</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #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: #800;" class=3D"styled-by-prettify">// ...</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">}</span></div></code></div><div><=
br></div></div><div><br></div><div><br>On Wednesday, November 18, 2015 at 4=
:18:06 AM UTC-5, Larry Evans wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">On 11/18/2015 03:05 AM, Larry Evans wrote:
<br>&gt; On 11/17/2015 10:11 PM, Russell Greene wrote:
<br>&gt;&gt; I agree. This is a really good syntax, I was confused with the=
 proposal
<br>&gt;&gt; before.
<br>&gt;&gt;
<br>&gt;&gt; I would really like to see this as I am creating a large libra=
ry that
<br>&gt;&gt; has one very large template class, and currently I have the fu=
nctions in
<br>&gt;&gt; the class declaration, which is sacrificing clarity.
<br>&gt;&gt;
<br>&gt;&gt; I don&#39;t really like the use of namespace in the syntax tho=
ugh. It makes
<br>&gt;&gt; it seem like it actually has to do with namespaces, which
<br>&gt;&gt; it doesn&#39;t.
<br>&gt;=20
<br>&gt; I think someone proposed use of public instead of namespace.
<br>&gt; Would you prefer that?
<br>&gt;=20
<br>&gt; I think people are just trying to avoid another keyword and
<br>&gt; sacrificing a *little* readablity for that purpose.
<br>&gt;=20
<br>&gt;&gt;
<br>&gt;&gt; -Russell
<br>&gt;&gt;
<br>&gt;&gt; On Tue, Nov 17, 2015 at 5:10 PM Evan Teran &lt;<a href=3D"java=
script:" target=3D"_blank" gdf-obfuscated-mailto=3D"y4PcZ0eTBAAJ" rel=3D"no=
follow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" oncl=
ick=3D"this.href=3D&#39;javascript:&#39;;return true;">evan....@gmail.com</=
a>
<br>&gt;&gt; &lt;mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"y4PcZ0eTBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&=
#39;;return true;">evan....@gmail.com</a>&gt;&gt; wrote:
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 Example:
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 class MyClass
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 public:
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MyClass(int =3D 0);
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int val() const;
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 void set_val(int);
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 private:
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int m_val;
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 };
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // place &quot;private&quot=
; includes here
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 namespace class MyClass
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MyClass(int) { ... }
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int val() const { ..=
.. }
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 void set_val(int) { =
.... }
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 I think this new syntax idea potentially provide=
s real benefit. I
<br>&gt;&gt; =C2=A0 =C2=A0 like it a lot. One the motivating pain points of=
 templates is that
<br>&gt;&gt; =C2=A0 =C2=A0 if you separate declaration from definition, you=
 have to deal with
<br>&gt;&gt; =C2=A0 =C2=A0 very verbose template syntax. For example:
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 template&lt;classCh,classTr&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 class String{
<br>&gt;&gt; =C2=A0 =C2=A0 public:
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 void some_method();
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 void another_method();
<br>&gt;&gt; =C2=A0 =C2=A0 };
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 template&lt;classCh,classTr&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 void String&lt;Ch,Tr&gt;::some_method(){
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ...
<br>&gt;&gt; =C2=A0 =C2=A0 }
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 template&lt;classCh,classTr&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 void String&lt;Ch,Tr&gt;::another_method(<wbr>){
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ...
<br>&gt;&gt; =C2=A0 =C2=A0 }
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 If this could instead be written like the follow=
ing code, then it
<br>&gt;&gt; =C2=A0 =C2=A0 would be simpler to read, write and maintain:
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 template&lt;classCh,classTr&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 class String{
<br>&gt;&gt; =C2=A0 =C2=A0 public:
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 void some_method();
<br>&gt;&gt; =C2=A0 =C2=A0 };
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 template&lt;classCh,classTr&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 namespace class String{
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 void some_method(){
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ...
<br>&gt;&gt; =C2=A0 =C2=A0 }
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 void another_method(){
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ...
<br>&gt;&gt; =C2=A0 =C2=A0 }
<br>&gt;&gt; =C2=A0 =C2=A0 }
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 In my opinion this syntax or something similar t=
o it, is:
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 1. easier to read, we get to drop the &quot;nois=
e&quot; of the repeated
<br>&gt;&gt; =C2=A0 =C2=A0 template parameters, but it is still explicit en=
ough to know what it
<br>&gt;&gt; =C2=A0 =C2=A0 means
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 2. easier to write, for single functions, there =
is a slight increase
<br>&gt;&gt; =C2=A0 =C2=A0 in code, but for a large group of functions, it =
can drastically
<br>&gt;&gt; =C2=A0 =C2=A0 reduce the amount of code while not sacrificing =
clarity.
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 3. easier to maintain, if a template parameter c=
hanges, we would
<br>&gt;&gt; =C2=A0 =C2=A0 need to change it far fewer places (two places i=
nstead of once per
<br>&gt;&gt; =C2=A0 =C2=A0 non-inline method)
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 Like I said, I would very much welcome this as a=
s option as long as
<br>&gt;&gt; =C2=A0 =C2=A0 the previous syntax doesn&#39;t get removed :-).
<br>&gt;=20
<br>&gt; Yes! =C2=A0I welcome this syntax simplication also.
<br>&gt;=20
<br>&gt; However, what about static members? =C2=A0For example:
<br>OOPS. =C2=A0Sorry for typos:
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 =C2=A0template&lt;classCh,classTr&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0class String{
<br>&gt; =C2=A0 =C2=A0 =C2=A0public:
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0String(classCh ch);//new
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0void some_method();
<br>Should include:
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0void another_method();
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0template&lt;classCh Ch&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0static strch;//new
<br>Should be:
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0static String strch;//new
<br>&gt; =C2=A0 =C2=A0 =C2=A0};
<br>&gt;=20
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 =C2=A0template&lt;classCh,classTr&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0namespace class String{
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0String(classCh ch){
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// ...
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0void some_method(){
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// ...
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0void another_method(){
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// ...
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0template&lt;classCh Ch&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0static strch(Ch);
<br>Should be:
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0static String strch(Ch);
<br>&gt; =C2=A0 =C2=A0 =C2=A0};
<br>&gt;=20
<br>&gt; Would this be allowed under this proposal?
<br>&gt;=20
<br>&gt; -regards,
<br>&gt; Larry
<br>&gt;=20
<br>&gt;=20
<br>
<br>
<br></blockquote></div></div>

<p></p>

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

------=_Part_4628_1006614742.1447850890972--
------=_Part_4627_1606485395.1447850890970--

.


Author: Evan Teran <evan.teran@gmail.com>
Date: Wed, 18 Nov 2015 04:58:52 -0800 (PST)
Raw View
------=_Part_4357_1844698204.1447851533008
Content-Type: multipart/alternative;
 boundary="----=_Part_4358_557436964.1447851533010"

------=_Part_4358_557436964.1447851533010
Content-Type: text/plain; charset=UTF-8


Also, to be clear, members which have separate template parameters from the
class are also covered cleanly:

template <class T>
class MyClass {
public:
    template <class U>
    void member(U u);
};


// current syntax (yuck)


template <class T> // did i get the ordering right, I always forget!
template <class U>
void MyClass<T>::member(U u) {
    // ...
}


// proposed syntax, no room for mistakes, much clearer
template <class T>
namespace class MyClass {


template <class U>
void member(U u) {
    // ..
}


}



On Wednesday, November 18, 2015 at 7:48:11 AM UTC-5, Evan Teran wrote:
>
> My suggestion is for something like:
>
> template <class Ch, class Tr>
> namespace class String {
> void member() {}
> }
>
>
> to be exactly equivalent to:
>
> template <class Ch, class Tr>
> void String<Ch, Tr>::member() {}
>
> So for the example of a static members, constructors, etc, this would
> continue to be equivalent, for example:
>
>
> // typical class declaration
> template <class Ch, class Tr>
> class String {
> public:
>  String(Ch ch);
>  void some_method();
>  void another_method();
>  static String strch(Ch ch);
> };
>
>
>
>
> // non-inline definition using proposed syntax
> template<class Ch, class Tr>
> namespace class String { /* I'm ok with any keyword besides "namespace" */
>
>
> String(Ch ch) {
>  // ...
> }
>
>
> void some_method() {
>  // ...
> }
>
>
> void another_method() {
>  // ...
> }
>
>
> String strch(Ch) {
>  // ...
> }
>
>
> }
>
>
> which would be the same as writing this code:
>
> template <class Ch, class Tr>
> String<Ch, Tr>::String(Ch ch) {
>  // ...
> }
>
>
> template <class Ch, class Tr>
> void String<Ch, Tr>::some_method() {
>  // ...
> }
>
>
> template <class Ch, class Tr>
> void String<Ch, Tr>::another_method() {
>  // ...
> }
>
>
> template <class Ch, class Tr>
> String<Ch, Tr> String<Ch, Tr>::strch(Ch) {
>  // ...
> }
>
>
>
> On Wednesday, November 18, 2015 at 4:18:06 AM UTC-5, Larry Evans wrote:
>>
>> On 11/18/2015 03:05 AM, Larry Evans wrote:
>> > On 11/17/2015 10:11 PM, Russell Greene wrote:
>> >> I agree. This is a really good syntax, I was confused with the
>> proposal
>> >> before.
>> >>
>> >> I would really like to see this as I am creating a large library that
>> >> has one very large template class, and currently I have the functions
>> in
>> >> the class declaration, which is sacrificing clarity.
>> >>
>> >> I don't really like the use of namespace in the syntax though. It
>> makes
>> >> it seem like it actually has to do with namespaces, which
>> >> it doesn't.
>> >
>> > I think someone proposed use of public instead of namespace.
>> > Would you prefer that?
>> >
>> > I think people are just trying to avoid another keyword and
>> > sacrificing a *little* readablity for that purpose.
>> >
>> >>
>> >> -Russell
>> >>
>> >> On Tue, Nov 17, 2015 at 5:10 PM Evan Teran <evan....@gmail.com
>> >> <mailto:evan....@gmail.com>> wrote:
>> >>
>> >>
>> >>         Example:
>> >>
>> >>           class MyClass
>> >>           {
>> >>           public:
>> >>             MyClass(int = 0);
>> >>             int val() const;
>> >>             void set_val(int);
>> >>
>> >>           private:
>> >>             int m_val;
>> >>           };
>> >>
>> >>           // place "private" includes here
>> >>
>> >>           namespace class MyClass
>> >>           {
>> >>             MyClass(int) { ... }
>> >>             int val() const { ... }
>> >>             void set_val(int) { ... }
>> >>           }
>> >>
>> >>
>> >>
>> >>     I think this new syntax idea potentially provides real benefit. I
>> >>     like it a lot. One the motivating pain points of templates is that
>> >>     if you separate declaration from definition, you have to deal with
>> >>     very verbose template syntax. For example:
>> >>
>> >>
>> >>     template<classCh,classTr>
>> >>     class String{
>> >>     public:
>> >>         void some_method();
>> >>         void another_method();
>> >>     };
>> >>
>> >>
>> >>     template<classCh,classTr>
>> >>     void String<Ch,Tr>::some_method(){
>> >>         // ...
>> >>     }
>> >>
>> >>     template<classCh,classTr>
>> >>     void String<Ch,Tr>::another_method(){
>> >>         // ...
>> >>     }
>> >>
>> >>
>> >>     If this could instead be written like the following code, then it
>> >>     would be simpler to read, write and maintain:
>> >>
>> >>     template<classCh,classTr>
>> >>     class String{
>> >>     public:
>> >>         void some_method();
>> >>     };
>> >>
>> >>
>> >>     template<classCh,classTr>
>> >>     namespace class String{
>> >>
>> >>     void some_method(){
>> >>         // ...
>> >>     }
>> >>
>> >>
>> >>     void another_method(){
>> >>         // ...
>> >>     }
>> >>     }
>> >>
>> >>     In my opinion this syntax or something similar to it, is:
>> >>
>> >>     1. easier to read, we get to drop the "noise" of the repeated
>> >>     template parameters, but it is still explicit enough to know what
>> it
>> >>     means
>> >>
>> >>     2. easier to write, for single functions, there is a slight
>> increase
>> >>     in code, but for a large group of functions, it can drastically
>> >>     reduce the amount of code while not sacrificing clarity.
>> >>
>> >>     3. easier to maintain, if a template parameter changes, we would
>> >>     need to change it far fewer places (two places instead of once per
>> >>     non-inline method)
>> >>
>> >>     Like I said, I would very much welcome this as as option as long
>> as
>> >>     the previous syntax doesn't get removed :-).
>> >
>> > Yes!  I welcome this syntax simplication also.
>> >
>> > However, what about static members?  For example:
>> OOPS.  Sorry for typos:
>> >
>> >      template<classCh,classTr>
>> >      class String{
>> >      public:
>> >          String(classCh ch);//new
>> >          void some_method();
>> Should include:
>>            void another_method();
>> >
>> >          template<classCh Ch>
>> >          static strch;//new
>> Should be:
>>            static String strch;//new
>> >      };
>> >
>> >
>> >      template<classCh,classTr>
>> >      namespace class String{
>> >
>> >          String(classCh ch){
>> >          // ...
>> >          }
>> >
>> >          void some_method(){
>> >          // ...
>> >          }
>> >
>> >          void another_method(){
>> >          // ...
>> >          }
>> >
>> >          template<classCh Ch>
>> >          static strch(Ch);
>> Should be:
>>            static String strch(Ch);
>> >      };
>> >
>> > Would this be allowed under this proposal?
>> >
>> > -regards,
>> > Larry
>> >
>> >
>>
>>
>>

--

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

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

<div dir=3D"ltr"><div><br></div>Also, to be clear, members which have separ=
ate template parameters from the class are also covered cleanly:<div><br></=
div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187=
); word-wrap: break-word; background-color: rgb(250, 250, 250);"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">template</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </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-p=
rettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #606;" class=3D"styled-by-prettify">MyClass</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></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">public</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 =C2=A0 </span><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=
">class</span><span style=3D"color: #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;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0=
 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> member</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">U u</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br><br><br></span><span style=3D"color: #800;" class=3D=
"styled-by-prettify">// current syntax (yuck)</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br><br><br></span><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">template</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=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"style=
d-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// did i=
 get the ordering right, I always forget!</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">template</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">class</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> U</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #606;" class=3D"styled-by-prettify">MyClass</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&gt;::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">member</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">U u</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </spa=
n><span style=3D"color: #800;" class=3D"styled-by-prettify">// ...</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br><br><br></span><span style=3D"=
color: #800;" class=3D"styled-by-prettify">// proposed syntax, no room for =
mistakes, much clearer</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">template</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </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 s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">namespace</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"sty=
led-by-prettify">MyClass</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
<br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">te=
mplate</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">class</span><span s=
tyle=3D"color: #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;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> member</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">U u</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 <=
/span><span style=3D"color: #800;" class=3D"styled-by-prettify">// ..</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br><br><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code></div><=
div><br><br><br>On Wednesday, November 18, 2015 at 7:48:11 AM UTC-5, Evan T=
eran wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">My=
 suggestion is for something like:<div><br></div><div style=3D"border:1px s=
olid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250=
)"><code><div><span style=3D"color:#008">template</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#660">&lt;</span><span style=3D"color:=
#008">class</span><span style=3D"color:#000"> </span><span style=3D"color:#=
606">Ch</span><span style=3D"color:#660">,</span><span style=3D"color:#000"=
> </span><span style=3D"color:#008">class</span><span style=3D"color:#000">=
 </span><span style=3D"color:#606">Tr</span><span style=3D"color:#660">&gt;=
</span><span style=3D"color:#000"><br></span><span style=3D"color:#008">nam=
espace</span><span style=3D"color:#000"> </span><span style=3D"color:#008">=
class</span><span style=3D"color:#000"> </span><span style=3D"color:#606">S=
tring</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{=
</span><span style=3D"color:#000"><br></span><span style=3D"color:#008">voi=
d</span><span style=3D"color:#000"> member</span><span style=3D"color:#660"=
>()</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{}<=
/span><span style=3D"color:#000"><br></span><span style=3D"color:#660">}</s=
pan></div></code></div><div><br><br></div><div>to be exactly equivalent to:=
<br></div><div><br></div><div><div style=3D"border:1px solid rgb(187,187,18=
7);word-wrap:break-word;background-color:rgb(250,250,250)"><code><div><span=
 style=3D"color:#008">template</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#660">&lt;</span><span style=3D"color:#008">class</span><=
span style=3D"color:#000"> </span><span style=3D"color:#606">Ch</span><span=
 style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#008">class</span><span style=3D"color:#000"> </span><span style=
=3D"color:#606">Tr</span><span style=3D"color:#660">&gt;</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#008">void</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#606">String</span><span styl=
e=3D"color:#660">&lt;</span><span style=3D"color:#606">Ch</span><span style=
=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#606">Tr</span><span style=3D"color:#660">&gt;::</span><span style=3D"=
color:#000">member</span><span style=3D"color:#660">()</span><span style=3D=
"color:#000"> </span><span style=3D"color:#660">{}</span></div></code></div=
><div><br></div></div><div>So for the example of a static members, construc=
tors, etc, this would continue to be equivalent, for example:</div><div><br=
></div><div><br></div><div><div style=3D"border:1px solid rgb(187,187,187);=
word-wrap:break-word;background-color:rgb(250,250,250)"><code><div><span st=
yle=3D"color:#800">// typical class declaration</span><span style=3D"color:=
#000"><br></span><span style=3D"color:#008">template</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#660">&lt;</span><span style=3D"col=
or:#008">class</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#606">Ch</span><span style=3D"color:#660">,</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#008">class</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#606">Tr</span><span style=3D"color:#660">&=
gt;</span><span style=3D"color:#000"> <br></span><span style=3D"color:#008"=
>class</span><span style=3D"color:#000"> </span><span style=3D"color:#606">=
String</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
{</span><span style=3D"color:#000"> <br></span><span style=3D"color:#008">p=
ublic</span><span style=3D"color:#660">:</span><span style=3D"color:#000"> =
<br>=C2=A0</span><span style=3D"color:#606">String</span><span style=3D"col=
or:#660">(</span><span style=3D"color:#606">Ch</span><span style=3D"color:#=
000"> ch</span><span style=3D"color:#660">);</span><span style=3D"color:#00=
0"><br>=C2=A0</span><span style=3D"color:#008">void</span><span style=3D"co=
lor:#000"> some_method</span><span style=3D"color:#660">();</span><span sty=
le=3D"color:#000"> <br>=C2=A0</span><span style=3D"color:#008">void</span><=
span style=3D"color:#000"> another_method</span><span style=3D"color:#660">=
();</span><span style=3D"color:#000"><br>=C2=A0</span><span style=3D"color:=
#008">static</span><span style=3D"color:#000"> </span><span style=3D"color:=
#606">String</span><span style=3D"color:#000"> strch</span><span style=3D"c=
olor:#660">(</span><span style=3D"color:#606">Ch</span><span style=3D"color=
:#000"> ch</span><span style=3D"color:#660">);</span><span style=3D"color:#=
000"><br></span><span style=3D"color:#660">};</span><span style=3D"color:#0=
00"> <br><br><br><br><br></span><span style=3D"color:#800">// non-inline de=
finition using proposed syntax</span><span style=3D"color:#000"><br></span>=
<span style=3D"color:#008">template</span><span style=3D"color:#660">&lt;</=
span><span style=3D"color:#008">class</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#606">Ch</span><span style=3D"color:#660">,</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#008">class</span><=
span style=3D"color:#000"> </span><span style=3D"color:#606">Tr</span><span=
 style=3D"color:#660">&gt;</span><span style=3D"color:#000"> <br></span><sp=
an style=3D"color:#008">namespace</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#008">class</span><span style=3D"color:#000"> </span><=
span style=3D"color:#606">String</span><span style=3D"color:#000"> </span><=
span style=3D"color:#660">{</span><span style=3D"color:#000"> </span><span =
style=3D"color:#800">/* I&#39;m ok with any keyword besides &quot;namespace=
&quot; */</span><span style=3D"color:#000"><br><br><br></span><span style=
=3D"color:#606">String</span><span style=3D"color:#660">(</span><span style=
=3D"color:#606">Ch</span><span style=3D"color:#000"> ch</span><span style=
=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">{</span><span style=3D"color:#000"> <br>=C2=A0</span><span style=
=3D"color:#800">// ... </span><span style=3D"color:#000"><br></span><span s=
tyle=3D"color:#660">}</span><span style=3D"color:#000"> <br><br><br></span>=
<span style=3D"color:#008">void</span><span style=3D"color:#000"> some_meth=
od</span><span style=3D"color:#660">()</span><span style=3D"color:#000"> </=
span><span style=3D"color:#660">{</span><span style=3D"color:#000"> <br>=C2=
=A0</span><span style=3D"color:#800">// ... </span><span style=3D"color:#00=
0"><br></span><span style=3D"color:#660">}</span><span style=3D"color:#000"=
> <br><br><br></span><span style=3D"color:#008">void</span><span style=3D"c=
olor:#000"> another_method</span><span style=3D"color:#660">()</span><span =
style=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=
=3D"color:#000"> <br>=C2=A0</span><span style=3D"color:#800">// ... </span>=
<span style=3D"color:#000"><br></span><span style=3D"color:#660">}</span><s=
pan style=3D"color:#000"> <br><br><br></span><span style=3D"color:#606">Str=
ing</span><span style=3D"color:#000"> strch</span><span style=3D"color:#660=
">(</span><span style=3D"color:#606">Ch</span><span style=3D"color:#660">)<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">{</span=
><span style=3D"color:#000"><br>=C2=A0</span><span style=3D"color:#800">// =
....</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">=
}</span><span style=3D"color:#000"><br><br><br></span><span style=3D"color:=
#660">}</span></div></code></div><div><br></div><div><br></div><div>which w=
ould be the same as writing this code:</div><div><br></div><div style=3D"bo=
rder:1px solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(2=
50,250,250)"><code><div><span style=3D"color:#008">template</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#660">&lt;</span><span style=
=3D"color:#008">class</span><span style=3D"color:#000"> </span><span style=
=3D"color:#606">Ch</span><span style=3D"color:#660">,</span><span style=3D"=
color:#000"> </span><span style=3D"color:#008">class</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#606">Tr</span><span style=3D"color=
:#660">&gt;</span><span style=3D"color:#000"><br></span><span style=3D"colo=
r:#606">String</span><span style=3D"color:#660">&lt;</span><span style=3D"c=
olor:#606">Ch</span><span style=3D"color:#660">,</span><span style=3D"color=
:#000"> </span><span style=3D"color:#606">Tr</span><span style=3D"color:#66=
0">&gt;::</span><span style=3D"color:#606">String</span><span style=3D"colo=
r:#660">(</span><span style=3D"color:#606">Ch</span><span style=3D"color:#0=
00"> ch</span><span style=3D"color:#660">)</span><span style=3D"color:#000"=
> </span><span style=3D"color:#660">{</span><span style=3D"color:#000"> <br=
>=C2=A0</span><span style=3D"color:#800">// ... </span><span style=3D"color=
:#000"><br></span><span style=3D"color:#660">}</span><span style=3D"color:#=
000"> <br><br><br></span><span style=3D"color:#008">template</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#660">&lt;</span><span styl=
e=3D"color:#008">class</span><span style=3D"color:#000"> </span><span style=
=3D"color:#606">Ch</span><span style=3D"color:#660">,</span><span style=3D"=
color:#000"> </span><span style=3D"color:#008">class</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#606">Tr</span><span style=3D"color=
:#660">&gt;</span><span style=3D"color:#000"><br></span><span style=3D"colo=
r:#008">void</span><span style=3D"color:#000"> </span><span style=3D"color:=
#606">String</span><span style=3D"color:#660">&lt;</span><span style=3D"col=
or:#606">Ch</span><span style=3D"color:#660">,</span><span style=3D"color:#=
000"> </span><span style=3D"color:#606">Tr</span><span style=3D"color:#660"=
>&gt;::</span><span style=3D"color:#000">some_method</span><span style=3D"c=
olor:#660">()</span><span style=3D"color:#000"> </span><span style=3D"color=
:#660">{</span><span style=3D"color:#000"> <br>=C2=A0</span><span style=3D"=
color:#800">// ... </span><span style=3D"color:#000"><br></span><span style=
=3D"color:#660">}</span><span style=3D"color:#000"> <br><br><br></span><spa=
n style=3D"color:#008">template</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#660">&lt;</span><span style=3D"color:#008">class</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#606">Ch</span><spa=
n style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#008">class</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#606">Tr</span><span style=3D"color:#660">&gt;</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#008">void</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#606">String</span><span styl=
e=3D"color:#660">&lt;</span><span style=3D"color:#606">Ch</span><span style=
=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#606">Tr</span><span style=3D"color:#660">&gt;::</span><span style=3D"=
color:#000">another_method</span><span style=3D"color:#660">()</span><span =
style=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=
=3D"color:#000"> <br>=C2=A0</span><span style=3D"color:#800">// ... </span>=
<span style=3D"color:#000"><br></span><span style=3D"color:#660">}</span><s=
pan style=3D"color:#000"> <br><br><br></span><span style=3D"color:#008">tem=
plate</span><span style=3D"color:#000"> </span><span style=3D"color:#660">&=
lt;</span><span style=3D"color:#008">class</span><span style=3D"color:#000"=
> </span><span style=3D"color:#606">Ch</span><span style=3D"color:#660">,</=
span><span style=3D"color:#000"> </span><span style=3D"color:#008">class</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#606">Tr</span>=
<span style=3D"color:#660">&gt;</span><span style=3D"color:#000"><br></span=
><span style=3D"color:#606">String</span><span style=3D"color:#660">&lt;</s=
pan><span style=3D"color:#606">Ch</span><span style=3D"color:#660">,</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#606">Tr</span><spa=
n style=3D"color:#660">&gt;</span><span style=3D"color:#000"> </span><span =
style=3D"color:#606">String</span><span style=3D"color:#660">&lt;</span><sp=
an style=3D"color:#606">Ch</span><span style=3D"color:#660">,</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#606">Tr</span><span style=
=3D"color:#660">&gt;::</span><span style=3D"color:#000">strch</span><span s=
tyle=3D"color:#660">(</span><span style=3D"color:#606">Ch</span><span style=
=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">{</span><span style=3D"color:#000"><br>=C2=A0</span><span style=
=3D"color:#800">// ...</span><span style=3D"color:#000"><br></span><span st=
yle=3D"color:#660">}</span></div></code></div><div><br></div></div><div><br=
></div><div><br>On Wednesday, November 18, 2015 at 4:18:06 AM UTC-5, Larry =
Evans wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/18/2015 03:05 AM,=
 Larry Evans wrote:
<br>&gt; On 11/17/2015 10:11 PM, Russell Greene wrote:
<br>&gt;&gt; I agree. This is a really good syntax, I was confused with the=
 proposal
<br>&gt;&gt; before.
<br>&gt;&gt;
<br>&gt;&gt; I would really like to see this as I am creating a large libra=
ry that
<br>&gt;&gt; has one very large template class, and currently I have the fu=
nctions in
<br>&gt;&gt; the class declaration, which is sacrificing clarity.
<br>&gt;&gt;
<br>&gt;&gt; I don&#39;t really like the use of namespace in the syntax tho=
ugh. It makes
<br>&gt;&gt; it seem like it actually has to do with namespaces, which
<br>&gt;&gt; it doesn&#39;t.
<br>&gt;=20
<br>&gt; I think someone proposed use of public instead of namespace.
<br>&gt; Would you prefer that?
<br>&gt;=20
<br>&gt; I think people are just trying to avoid another keyword and
<br>&gt; sacrificing a *little* readablity for that purpose.
<br>&gt;=20
<br>&gt;&gt;
<br>&gt;&gt; -Russell
<br>&gt;&gt;
<br>&gt;&gt; On Tue, Nov 17, 2015 at 5:10 PM Evan Teran &lt;<a rel=3D"nofol=
low">evan....@gmail.com</a>
<br>&gt;&gt; &lt;mailto:<a rel=3D"nofollow">evan....@gmail.com</a>&gt;&gt; =
wrote:
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 Example:
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 class MyClass
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 public:
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MyClass(int =3D 0);
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int val() const;
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 void set_val(int);
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 private:
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int m_val;
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 };
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // place &quot;private&quot=
; includes here
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 namespace class MyClass
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MyClass(int) { ... }
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int val() const { ..=
.. }
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 void set_val(int) { =
.... }
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 I think this new syntax idea potentially provide=
s real benefit. I
<br>&gt;&gt; =C2=A0 =C2=A0 like it a lot. One the motivating pain points of=
 templates is that
<br>&gt;&gt; =C2=A0 =C2=A0 if you separate declaration from definition, you=
 have to deal with
<br>&gt;&gt; =C2=A0 =C2=A0 very verbose template syntax. For example:
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 template&lt;classCh,classTr&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 class String{
<br>&gt;&gt; =C2=A0 =C2=A0 public:
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 void some_method();
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 void another_method();
<br>&gt;&gt; =C2=A0 =C2=A0 };
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 template&lt;classCh,classTr&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 void String&lt;Ch,Tr&gt;::some_method(){
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ...
<br>&gt;&gt; =C2=A0 =C2=A0 }
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 template&lt;classCh,classTr&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 void String&lt;Ch,Tr&gt;::another_method(<wbr>){
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ...
<br>&gt;&gt; =C2=A0 =C2=A0 }
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 If this could instead be written like the follow=
ing code, then it
<br>&gt;&gt; =C2=A0 =C2=A0 would be simpler to read, write and maintain:
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 template&lt;classCh,classTr&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 class String{
<br>&gt;&gt; =C2=A0 =C2=A0 public:
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 void some_method();
<br>&gt;&gt; =C2=A0 =C2=A0 };
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 template&lt;classCh,classTr&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 namespace class String{
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 void some_method(){
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ...
<br>&gt;&gt; =C2=A0 =C2=A0 }
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 void another_method(){
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ...
<br>&gt;&gt; =C2=A0 =C2=A0 }
<br>&gt;&gt; =C2=A0 =C2=A0 }
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 In my opinion this syntax or something similar t=
o it, is:
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 1. easier to read, we get to drop the &quot;nois=
e&quot; of the repeated
<br>&gt;&gt; =C2=A0 =C2=A0 template parameters, but it is still explicit en=
ough to know what it
<br>&gt;&gt; =C2=A0 =C2=A0 means
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 2. easier to write, for single functions, there =
is a slight increase
<br>&gt;&gt; =C2=A0 =C2=A0 in code, but for a large group of functions, it =
can drastically
<br>&gt;&gt; =C2=A0 =C2=A0 reduce the amount of code while not sacrificing =
clarity.
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 3. easier to maintain, if a template parameter c=
hanges, we would
<br>&gt;&gt; =C2=A0 =C2=A0 need to change it far fewer places (two places i=
nstead of once per
<br>&gt;&gt; =C2=A0 =C2=A0 non-inline method)
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 Like I said, I would very much welcome this as a=
s option as long as
<br>&gt;&gt; =C2=A0 =C2=A0 the previous syntax doesn&#39;t get removed :-).
<br>&gt;=20
<br>&gt; Yes! =C2=A0I welcome this syntax simplication also.
<br>&gt;=20
<br>&gt; However, what about static members? =C2=A0For example:
<br>OOPS. =C2=A0Sorry for typos:
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 =C2=A0template&lt;classCh,classTr&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0class String{
<br>&gt; =C2=A0 =C2=A0 =C2=A0public:
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0String(classCh ch);//new
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0void some_method();
<br>Should include:
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0void another_method();
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0template&lt;classCh Ch&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0static strch;//new
<br>Should be:
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0static String strch;//new
<br>&gt; =C2=A0 =C2=A0 =C2=A0};
<br>&gt;=20
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 =C2=A0template&lt;classCh,classTr&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0namespace class String{
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0String(classCh ch){
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// ...
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0void some_method(){
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// ...
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0void another_method(){
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// ...
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0template&lt;classCh Ch&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0static strch(Ch);
<br>Should be:
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0static String strch(Ch);
<br>&gt; =C2=A0 =C2=A0 =C2=A0};
<br>&gt;=20
<br>&gt; Would this be allowed under this proposal?
<br>&gt;=20
<br>&gt; -regards,
<br>&gt; Larry
<br>&gt;=20
<br>&gt;=20
<br>
<br>
<br></blockquote></div></div></blockquote></div></div>

<p></p>

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

------=_Part_4358_557436964.1447851533010--
------=_Part_4357_1844698204.1447851533008--

.


Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 18 Nov 2015 10:26:55 -0500
Raw View
On 2015-11-17 19:10, Evan Teran wrote:
> Like I said, I would very much welcome this as as option as long as the
> previous syntax doesn't get removed :-).

Of course not :-). Besides compatibility, we allow this:

  namespace Foo { int bar(); }
  int Foo::bar() { ... }

It would be strange indeed to allow that but suddenly forbid explicitly
prefixed class methods :-).

On 2015-11-17 23:11, Russell Greene wrote:
> I agree. This is a really good syntax, I was confused with the proposal
> before.

Ah. Sorry for the confusion.

> I don't really like the use of namespace in the syntax though.

Sure. Syntax is open for discussion; I agree the "namespace class" is
potentially dubious (partly why I originally wrote "<block scope>"
rather than suggesting an actual syntax).

--
Matthew

--

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

.


Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 18 Nov 2015 10:30:59 -0500
Raw View
On 2015-11-18 04:17, Larry Evans wrote:
> However, what about static members?  For example:
>
>      template<classCh,classTr>
>      class String{
>      public:
>          String(classCh ch);//new
>          void some_method();
>          void another_method();
>
>          static String strch;//new
>      };
>
>
>      template<classCh,classTr>
>      namespace class String{
>
>          String(classCh ch){
>          // ...
>          }
>
>          void some_method(){
>          // ...
>          }
>
>          void another_method(){
>          // ...
>          }
>
>          static String strch(Ch);
>      };
>
> Would this be allowed under this proposal?

No, but only because your definition of strch wouldn't be legal with the
class name included.

This:

  template <...> namespace class String
  {
  void some_method() { ... }
  String<...> strch = ...; // see note
  }

....is exactly the same as:

  template <...> void String<...>::some_method() { ... }
  template <...> String<...> String<...>::strch { ... }

That is, the effect of 'namespace template' is simply to transform all
declarations / definitions therein as if they were prefixed with the
[template args and] class name. Anything you can do with an explicit
prefix, you can do in a class namespace, likewise the converse and
inverse. Your above example is thus not permitted because "static" would
not be permitted in:

  template <...>
  static String<...> String<...>::strch = ...;

....and because you omitted the template arguments when naming the type.
The latter is a more interesting question; should any mention of the
type name implicitly have the template parameters of the scope? That
would be convenient, but we don't permit it currently. For simplicity,
I'm inclined to say "no", but a follow-up proposal could add that. (We
would still want to allow giving the template parameters in case they
would be different.)

--
Matthew

--

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

.


Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 19 Nov 2015 10:39:22 -0500
Raw View
On 2015-11-18 11:38, John Yates wrote:
> On Wed, Nov 18, 2015 at 10:26 AM, Matthew Woehlke wrote:
>
>> Sure. Syntax is open for discussion; I agree the "namespace class" is
>> potentially dubious (partly why I originally wrote "<block scope>"
>> rather than suggesting an actual syntax).
>
> I think syntax of the form
>
> <access> [ template <...> ] class <identifier> { ... };
>
> is unambiguous.

Assuming you mean that as a syntax for my proposal, I don't like it. It
violates DRY (making you repeat the access specification), and requires
a separate scope block for each access level.

FWIW, I disagree that a class is not a namespace. I mean, obviously it's
not exactly a "namespace" (C++ keyword), but it is a name scope (i.e.
"name space" in colloquial English). Hence, I would read "namespace
class A" as:

- "namespace": I am about to provide declarations and/or definitions
that live in a particular name scope. To know what scope, I will keep
reading.

- "class": Ah... the name scope is a class, not a traditional
"namespace". (I also know that it will contain only definitions.) I
don't know what scope, yet... keep reading.

- "A": Ah... I will provide definitions that are in the scope of the
class named "A".

Again, some other keyword *might* be better (although to be honest I'm
having a hard time coming up with one... I don't like "with" or "scope"
all that much better).

--
Matthew

--

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

.


Author: Evan Teran <evan.teran@gmail.com>
Date: Thu, 19 Nov 2015 08:20:51 -0800 (PST)
Raw View
------=_Part_1169_539195151.1447950051827
Content-Type: multipart/alternative;
 boundary="----=_Part_1170_1526531844.1447950051827"

------=_Part_1170_1526531844.1447950051827
Content-Type: text/plain; charset=UTF-8


I agree with Matthew here about access specifier, I don't think it is
useful (or simpler) to have a separate scope for each access type. As
Matthew said, it's not a c++ namespace, but it is a namespace in
the colloquial English sense, so it's not like it is complete nonsense.

Perhaps this would be a good place to re-use the now defunct export keyword
or similar? (I would have actually favored "extern" more since the
definition of of the functions are "external". But yea, generically
something like this is what I would prefer.

[ template <...> ] <keyword> class <identifier> { ... }

I like template first, since that is consistent with other areas of the
language. Also note, that I removed the semicolon at the end. This isn't
declaring a class, it is defining methods of an already defined class.
Similar to how namespace doesn't require the semicolon. That being said,
the particular keyword we use to identify the construct is more of a minor
concern, I would just want it to make "sense" since the goal is to increase
readability. However, some things are like storage classes can be more or
less immediately dismissed since they are already valid code:

static class A {} a;
extern class A{} a;
etc..


On Thursday, November 19, 2015 at 10:39:39 AM UTC-5, Matthew Woehlke wrote:
>
> On 2015-11-18 11:38, John Yates wrote:
> > On Wed, Nov 18, 2015 at 10:26 AM, Matthew Woehlke wrote:
> >
> >> Sure. Syntax is open for discussion; I agree the "namespace class" is
> >> potentially dubious (partly why I originally wrote "<block scope>"
> >> rather than suggesting an actual syntax).
> >
> > I think syntax of the form
> >
> > <access> [ template <...> ] class <identifier> { ... };
> >
> > is unambiguous.
>
> Assuming you mean that as a syntax for my proposal, I don't like it. It
> violates DRY (making you repeat the access specification), and requires
> a separate scope block for each access level.
>
> FWIW, I disagree that a class is not a namespace. I mean, obviously it's
> not exactly a "namespace" (C++ keyword), but it is a name scope (i.e.
> "name space" in colloquial English). Hence, I would read "namespace
> class A" as:
>
> - "namespace": I am about to provide declarations and/or definitions
> that live in a particular name scope. To know what scope, I will keep
> reading.
>
> - "class": Ah... the name scope is a class, not a traditional
> "namespace". (I also know that it will contain only definitions.) I
> don't know what scope, yet... keep reading.
>
> - "A": Ah... I will provide definitions that are in the scope of the
> class named "A".
>
> Again, some other keyword *might* be better (although to be honest I'm
> having a hard time coming up with one... I don't like "with" or "scope"
> all that much better).
>
> --
> Matthew
>
>

--

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

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

<div dir=3D"ltr"><div><br></div>I agree with Matthew here about access spec=
ifier, I don&#39;t think it is useful (or simpler) to have a separate scope=
 for each access type. As Matthew said, it&#39;s not a c++ namespace, but i=
t is a namespace in the=C2=A0colloquial English sense, so it&#39;s not like=
 it is complete nonsense.<div><br></div><div>Perhaps this would be a good p=
lace to re-use the now defunct export keyword or similar? (I would have act=
ually favored &quot;extern&quot; more since=C2=A0the definition of of the f=
unctions are &quot;external&quot;. But yea, generically something like this=
 is what I would prefer.<div><br></div><div>[ template &lt;...&gt; ] &lt;ke=
yword&gt; class &lt;identifier&gt; { ... }</div><div><br></div><div>I like =
template first, since that is consistent with other areas of the language. =
Also note, that I removed the semicolon at the end. This isn&#39;t declarin=
g a class, it is defining methods of an already defined class. Similar to h=
ow namespace doesn&#39;t require the semicolon. That being said, the partic=
ular keyword we use to identify the construct is more of a minor concern, I=
 would just want it to make &quot;sense&quot; since the goal is to increase=
 readability. However, some things are like storage classes can be more or =
less immediately dismissed since they are already valid code:</div><div><br=
></div><div>static class A {} a;</div><div>extern class A{} a;</div><div>et=
c..</div><div><div><br><br>On Thursday, November 19, 2015 at 10:39:39 AM UT=
C-5, Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On =
2015-11-18 11:38, John Yates wrote:
<br>&gt; On Wed, Nov 18, 2015 at 10:26 AM, Matthew Woehlke wrote:
<br>&gt;=20
<br>&gt;&gt; Sure. Syntax is open for discussion; I agree the &quot;namespa=
ce class&quot; is
<br>&gt;&gt; potentially dubious (partly why I originally wrote &quot;&lt;b=
lock scope&gt;&quot;
<br>&gt;&gt; rather than suggesting an actual syntax).
<br>&gt;=20
<br>&gt; I think syntax of the form
<br>&gt;=20
<br>&gt; &lt;access&gt; [ template &lt;...&gt; ] class &lt;identifier&gt; {=
 ... };
<br>&gt;=20
<br>&gt; is unambiguous.
<br>
<br>Assuming you mean that as a syntax for my proposal, I don&#39;t like it=
.. It
<br>violates DRY (making you repeat the access specification), and requires
<br>a separate scope block for each access level.
<br>
<br>FWIW, I disagree that a class is not a namespace. I mean, obviously it&=
#39;s
<br>not exactly a &quot;namespace&quot; (C++ keyword), but it is a name sco=
pe (i.e.
<br>&quot;name space&quot; in colloquial English). Hence, I would read &quo=
t;namespace
<br>class A&quot; as:
<br>
<br>- &quot;namespace&quot;: I am about to provide declarations and/or defi=
nitions
<br>that live in a particular name scope. To know what scope, I will keep
<br>reading.
<br>
<br>- &quot;class&quot;: Ah... the name scope is a class, not a traditional
<br>&quot;namespace&quot;. (I also know that it will contain only definitio=
ns.) I
<br>don&#39;t know what scope, yet... keep reading.
<br>
<br>- &quot;A&quot;: Ah... I will provide definitions that are in the scope=
 of the
<br>class named &quot;A&quot;.
<br>
<br>Again, some other keyword *might* be better (although to be honest I&#3=
9;m
<br>having a hard time coming up with one... I don&#39;t like &quot;with&qu=
ot; or &quot;scope&quot;
<br>all that much better).
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></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 />

------=_Part_1170_1526531844.1447950051827--
------=_Part_1169_539195151.1447950051827--

.


Author: Evan Teran <evan.teran@gmail.com>
Date: Thu, 19 Nov 2015 08:23:32 -0800 (PST)
Raw View
------=_Part_1184_1953010689.1447950212676
Content-Type: multipart/alternative;
 boundary="----=_Part_1185_1230234198.1447950212676"

------=_Part_1185_1230234198.1447950212676
Content-Type: text/plain; charset=UTF-8


Another option would be to introduce a context sensitive keyword which
strikes me as a lot more viable if we were to add a new one. For
example (scope being the example):


template <...> class : scope <identifier> {}

Since currently a colon can't follow the class keyword here, it's a way to
inject any identifier we wish without breaking existing code. Thoughts?



On Thursday, November 19, 2015 at 11:20:51 AM UTC-5, Evan Teran wrote:
>
>
> I agree with Matthew here about access specifier, I don't think it is
> useful (or simpler) to have a separate scope for each access type. As
> Matthew said, it's not a c++ namespace, but it is a namespace in
> the colloquial English sense, so it's not like it is complete nonsense.
>
> Perhaps this would be a good place to re-use the now defunct export
> keyword or similar? (I would have actually favored "extern" more since the
> definition of of the functions are "external". But yea, generically
> something like this is what I would prefer.
>
> [ template <...> ] <keyword> class <identifier> { ... }
>
> I like template first, since that is consistent with other areas of the
> language. Also note, that I removed the semicolon at the end. This isn't
> declaring a class, it is defining methods of an already defined class.
> Similar to how namespace doesn't require the semicolon. That being said,
> the particular keyword we use to identify the construct is more of a minor
> concern, I would just want it to make "sense" since the goal is to increase
> readability. However, some things are like storage classes can be more or
> less immediately dismissed since they are already valid code:
>
> static class A {} a;
> extern class A{} a;
> etc..
>
>
> On Thursday, November 19, 2015 at 10:39:39 AM UTC-5, Matthew Woehlke wrote:
>>
>> On 2015-11-18 11:38, John Yates wrote:
>> > On Wed, Nov 18, 2015 at 10:26 AM, Matthew Woehlke wrote:
>> >
>> >> Sure. Syntax is open for discussion; I agree the "namespace class" is
>> >> potentially dubious (partly why I originally wrote "<block scope>"
>> >> rather than suggesting an actual syntax).
>> >
>> > I think syntax of the form
>> >
>> > <access> [ template <...> ] class <identifier> { ... };
>> >
>> > is unambiguous.
>>
>> Assuming you mean that as a syntax for my proposal, I don't like it. It
>> violates DRY (making you repeat the access specification), and requires
>> a separate scope block for each access level.
>>
>> FWIW, I disagree that a class is not a namespace. I mean, obviously it's
>> not exactly a "namespace" (C++ keyword), but it is a name scope (i.e.
>> "name space" in colloquial English). Hence, I would read "namespace
>> class A" as:
>>
>> - "namespace": I am about to provide declarations and/or definitions
>> that live in a particular name scope. To know what scope, I will keep
>> reading.
>>
>> - "class": Ah... the name scope is a class, not a traditional
>> "namespace". (I also know that it will contain only definitions.) I
>> don't know what scope, yet... keep reading.
>>
>> - "A": Ah... I will provide definitions that are in the scope of the
>> class named "A".
>>
>> Again, some other keyword *might* be better (although to be honest I'm
>> having a hard time coming up with one... I don't like "with" or "scope"
>> all that much better).
>>
>> --
>> Matthew
>>
>>

--

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

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

<div dir=3D"ltr"><div><br></div>Another option would be to introduce a cont=
ext sensitive keyword which strikes me as a lot more viable if we were to a=
dd a new one. For example=C2=A0(scope being the example):<div><br></div><di=
v><br></div><div>template &lt;...&gt; class : scope &lt;identifier&gt; {}</=
div><div><br></div><div>Since currently a colon can&#39;t follow the class =
keyword here, it&#39;s a way to inject any identifier we wish without break=
ing existing code. Thoughts?</div><div><br></div><div><br></div><div><br>On=
 Thursday, November 19, 2015 at 11:20:51 AM UTC-5, Evan Teran wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div>I agr=
ee with Matthew here about access specifier, I don&#39;t think it is useful=
 (or simpler) to have a separate scope for each access type. As Matthew sai=
d, it&#39;s not a c++ namespace, but it is a namespace in the=C2=A0colloqui=
al English sense, so it&#39;s not like it is complete nonsense.<div><br></d=
iv><div>Perhaps this would be a good place to re-use the now defunct export=
 keyword or similar? (I would have actually favored &quot;extern&quot; more=
 since=C2=A0the definition of of the functions are &quot;external&quot;. Bu=
t yea, generically something like this is what I would prefer.<div><br></di=
v><div>[ template &lt;...&gt; ] &lt;keyword&gt; class &lt;identifier&gt; { =
.... }</div><div><br></div><div>I like template first, since that is consist=
ent with other areas of the language. Also note, that I removed the semicol=
on at the end. This isn&#39;t declaring a class, it is defining methods of =
an already defined class. Similar to how namespace doesn&#39;t require the =
semicolon. That being said, the particular keyword we use to identify the c=
onstruct is more of a minor concern, I would just want it to make &quot;sen=
se&quot; since the goal is to increase readability. However, some things ar=
e like storage classes can be more or less immediately dismissed since they=
 are already valid code:</div><div><br></div><div>static class A {} a;</div=
><div>extern class A{} a;</div><div>etc..</div><div><div><br><br>On Thursda=
y, November 19, 2015 at 10:39:39 AM UTC-5, Matthew Woehlke wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex">On 2015-11-18 11:38, John Yates wrote:
<br>&gt; On Wed, Nov 18, 2015 at 10:26 AM, Matthew Woehlke wrote:
<br>&gt;=20
<br>&gt;&gt; Sure. Syntax is open for discussion; I agree the &quot;namespa=
ce class&quot; is
<br>&gt;&gt; potentially dubious (partly why I originally wrote &quot;&lt;b=
lock scope&gt;&quot;
<br>&gt;&gt; rather than suggesting an actual syntax).
<br>&gt;=20
<br>&gt; I think syntax of the form
<br>&gt;=20
<br>&gt; &lt;access&gt; [ template &lt;...&gt; ] class &lt;identifier&gt; {=
 ... };
<br>&gt;=20
<br>&gt; is unambiguous.
<br>
<br>Assuming you mean that as a syntax for my proposal, I don&#39;t like it=
.. It
<br>violates DRY (making you repeat the access specification), and requires
<br>a separate scope block for each access level.
<br>
<br>FWIW, I disagree that a class is not a namespace. I mean, obviously it&=
#39;s
<br>not exactly a &quot;namespace&quot; (C++ keyword), but it is a name sco=
pe (i.e.
<br>&quot;name space&quot; in colloquial English). Hence, I would read &quo=
t;namespace
<br>class A&quot; as:
<br>
<br>- &quot;namespace&quot;: I am about to provide declarations and/or defi=
nitions
<br>that live in a particular name scope. To know what scope, I will keep
<br>reading.
<br>
<br>- &quot;class&quot;: Ah... the name scope is a class, not a traditional
<br>&quot;namespace&quot;. (I also know that it will contain only definitio=
ns.) I
<br>don&#39;t know what scope, yet... keep reading.
<br>
<br>- &quot;A&quot;: Ah... I will provide definitions that are in the scope=
 of the
<br>class named &quot;A&quot;.
<br>
<br>Again, some other keyword *might* be better (although to be honest I&#3=
9;m
<br>having a hard time coming up with one... I don&#39;t like &quot;with&qu=
ot; or &quot;scope&quot;
<br>all that much better).
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></div></div></div></div></blockquote></div></div>

<p></p>

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

------=_Part_1185_1230234198.1447950212676--
------=_Part_1184_1953010689.1447950212676--

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 19 Nov 2015 08:43:33 -0800 (PST)
Raw View
------=_Part_314_1494761811.1447951413802
Content-Type: multipart/alternative;
 boundary="----=_Part_315_643542231.1447951413803"

------=_Part_315_643542231.1447951413803
Content-Type: text/plain; charset=UTF-8



On Thursday, November 19, 2015 at 11:20:51 AM UTC-5, Evan Teran wrote:
>
>
> I agree with Matthew here about access specifier, I don't think it is
> useful (or simpler) to have a separate scope for each access type. As
> Matthew said, it's not a c++ namespace, but it is a namespace in
> the colloquial English sense, so it's not like it is complete nonsense.
>

So it's a `class namespace` rather than a "global" `namespace`. Maybe that
should be handled syntactically:

template<blah>
class namespace >TypeName<
{
};


> Perhaps this would be a good place to re-use the now defunct export
> keyword or similar? (I would have actually favored "extern" more since the
> definition of of the functions are "external". But yea, generically
> something like this is what I would prefer.
>

No, modules has dibs on `export`. And this feature, nice though it may be,
is less important than modules ;)

--

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

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

<div dir=3D"ltr"><br><br>On Thursday, November 19, 2015 at 11:20:51 AM UTC-=
5, Evan Teran wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><br></div>I agree with Matthew here about access specifier, I=
 don&#39;t think it is useful (or simpler) to have a separate scope for eac=
h access type. As Matthew said, it&#39;s not a c++ namespace, but it is a n=
amespace in the=C2=A0colloquial English sense, so it&#39;s not like it is c=
omplete nonsense.</div></blockquote><div><br>So it&#39;s a `class namespace=
` rather than a &quot;global&quot; `namespace`. Maybe that should be handle=
d syntactically:<br><br>template&lt;blah&gt;<br>class namespace &gt;TypeNam=
e&lt;<br>{<br>};<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div dir=3D"ltr"><div></div><div>Perhaps this would be a good place to re=
-use the now defunct export keyword or similar? (I would have actually favo=
red &quot;extern&quot; more since=C2=A0the definition of of the functions a=
re &quot;external&quot;. But yea, generically something like this is what I=
 would prefer.</div></div></blockquote><div><br>No, modules has dibs on `ex=
port`. And this feature, nice though it may be, is less important than modu=
les ;)<br></div></div>

<p></p>

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

------=_Part_315_643542231.1447951413803--
------=_Part_314_1494761811.1447951413802--

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 19 Nov 2015 08:47:28 -0800 (PST)
Raw View
------=_Part_962_645284691.1447951648499
Content-Type: multipart/alternative;
 boundary="----=_Part_963_2015018730.1447951648499"

------=_Part_963_2015018730.1447951648499
Content-Type: text/plain; charset=UTF-8



On Thursday, November 19, 2015 at 11:23:32 AM UTC-5, Evan Teran wrote:
>
>
> Another option would be to introduce a context sensitive keyword which
> strikes me as a lot more viable if we were to add a new one. For
> example (scope being the example):
>
>
> template <...> class : scope <identifier> {}
>

That is declaring an anonymous template class who's base class is `scope`.
Which is perfectly legal to do today <http://ideone.com/5iOIYN>.

--

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

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

<div dir=3D"ltr"><br><br>On Thursday, November 19, 2015 at 11:23:32 AM UTC-=
5, Evan Teran wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><br></div>Another option would be to introduce a context sens=
itive keyword which strikes me as a lot more viable if we were to add a new=
 one. For example=C2=A0(scope being the example):<div><br></div><div><br></=
div><div>template &lt;...&gt; class : scope &lt;identifier&gt; {}</div></di=
v></blockquote><div><br>That is declaring an anonymous template class who&#=
39;s base class is `scope`. Which is <a href=3D"http://ideone.com/5iOIYN">p=
erfectly legal to do today</a>.<br></div></div>

<p></p>

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

------=_Part_963_2015018730.1447951648499--
------=_Part_962_645284691.1447951648499--

.


Author: Evan Teran <evan.teran@gmail.com>
Date: Thu, 19 Nov 2015 08:58:22 -0800 (PST)
Raw View
------=_Part_1282_802392044.1447952302480
Content-Type: multipart/alternative;
 boundary="----=_Part_1283_125089405.1447952302480"

------=_Part_1283_125089405.1447952302480
Content-Type: text/plain; charset=UTF-8

Damn, you are correct :-(. My bad, Never mind that suggestion.

On Thursday, November 19, 2015 at 11:47:28 AM UTC-5, Nicol Bolas wrote:
>
>
>
> On Thursday, November 19, 2015 at 11:23:32 AM UTC-5, Evan Teran wrote:
>>
>>
>> Another option would be to introduce a context sensitive keyword which
>> strikes me as a lot more viable if we were to add a new one. For
>> example (scope being the example):
>>
>>
>> template <...> class : scope <identifier> {}
>>
>
> That is declaring an anonymous template class who's base class is `scope`.
> Which is perfectly legal to do today <http://ideone.com/5iOIYN>.
>

--

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

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

<div dir=3D"ltr">Damn, you are correct :-(. My bad, Never mind that suggest=
ion.<br><br>On Thursday, November 19, 2015 at 11:47:28 AM UTC-5, Nicol Bola=
s wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><=
br>On Thursday, November 19, 2015 at 11:23:32 AM UTC-5, Evan Teran wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div>Anoth=
er option would be to introduce a context sensitive keyword which strikes m=
e as a lot more viable if we were to add a new one. For example=C2=A0(scope=
 being the example):<div><br></div><div><br></div><div>template &lt;...&gt;=
 class : scope &lt;identifier&gt; {}</div></div></blockquote><div><br>That =
is declaring an anonymous template class who&#39;s base class is `scope`. W=
hich is <a href=3D"http://ideone.com/5iOIYN" target=3D"_blank" rel=3D"nofol=
low" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%=
2F%2Fideone.com%2F5iOIYN\46sa\75D\46sntz\0751\46usg\75AFQjCNGRmeaiSNkMqZuv-=
PzMPGURrP9Vlg&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\75http%3A%2F%2Fideone.com%2F5iOIYN\46sa\75D\46sntz\0751\46usg=
\75AFQjCNGRmeaiSNkMqZuv-PzMPGURrP9Vlg&#39;;return true;">perfectly legal to=
 do today</a>.<br></div></div></blockquote></div>

<p></p>

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

------=_Part_1283_125089405.1447952302480--
------=_Part_1282_802392044.1447952302480--

.