This is a multi-part message in MIME format.
--------------060201070801010600030401
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I've written up a draft proposal for a "class namespace" feature based
on the recent thread=C2=B9. In short, it introduces the new syntax:

  template <...> // optional
  namespace class Foo
  {
    Foo(...) { ... }
    void foo(...) { ... }
  }

....which is equivalent to:

  template <...> Foo<...>::Foo(...) { ... }
  template <...> void Foo<...>::foo(...) { ... }

Basically, it allows one to "hoist" the class name (along with template
specifications) out of a collection of out-of-line class member
definitions and into a block scope. The class name (and template bits)
are then implicitly applied to all definitions within said scope.

I'm attaching the current version for you lazy people that like to see
it in-line :-). You can also find the up to date version (with pretty
HTML formatting) at
https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-class-namespace/PXXXX%2=
0Class%20Namespace.rst.

Comments appreciated, especially pointing out anything I've missed.

(=C2=B9
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/e0_ceXFQ=
X-A)

--=20
Matthew

--=20

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

--------------060201070801010600030401
Content-Type: text/prs.fallenstein.rst;
 name="PXXXX Class Namespace.rst"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="PXXXX Class Namespace.rst"

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
  Class Namespace
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
~~~~~~~~~~~~~~~~~~~
 November 19, 2015
~~~~~~~~~~~~~~~~~~~

This proposal provides a new language feature, "class namespace", as a sh=
ortcut for providing a series of definitions belonging to a class scope, =
similar to the manner in which a traditional namespace can provide a seri=
es of definitions belonging to a namespace scope.


Rationale
=3D=3D=3D=3D=3D=3D=3D=3D=3D

`Don't Repeat Yourself <https://en.wikipedia.org/wiki/Don't_repeat_yourse=
lf>`_ (DRY) is a well known principle of software design. However, there =
are certain instances when providing definitions of class members that ca=
n fall prey to repetition, to the detriment of readability and maintainab=
ility.

We will present, as a particularly egregious example, a complicated templ=
ate class::

  template <typename CharType, typename Traits, typename Allocator>
  class MyString { ... };

There are strong reasons why method definitions should not be inline. For=
 starters, they inhibit readability; it is difficult to quickly parse the=
 interface |--| especially the public interface |--| as declarations and =
definitions are necessarily interleaved. Additionally, they are *inline*,=
 which results in all manner of compile time and cross-version compatibil=
ity issues. Even for template classes, it is sometimes preferred to keep =
definitions in a separate TU (e.g. extern templates with only specific, e=
xported explicit instantiations).

The problem that arises is the necessity to repeat a long prefix for all =
definitions provided outside of the class definition. For example::

  template <typename CharType, typename Traits, typename Allocator>
  MyString<CharType, Traits, Allocator>::MyString
  { ... }

This is a real, extant problem. Presumably as a result of this overhead, =
some authors will use only inline definitions of methods, which can make =
it difficult to separate implementation details |--| which are often unne=
cessary noise for a user trying to understand a class |--| from a class's=
 interface. Other authors may resort to separating return types, template=
 parameters, class names, and method names, placing each on separate line=
s, resulting in method headers that are four lines long even before the a=
rgument list is considered. In the latter case, the need to repeat the cl=
ass prefix is frustrating and, in the author's opinion, unnecessary.

(See https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/e=
0_ceXFQX-A for additional discussion.)


Proposal
=3D=3D=3D=3D=3D=3D=3D=3D

This proposal is to eliminate the redundancy by introducing a new "class =
scope" syntax, as follows::

  template <...> // optional; only used for template classes
  namespace class Name
  {
    // definitions of class members
  }

The effect of this scope is to treat each member definition (variable or =
method) as if it were prefixed by the class template specification and na=
me. Specifically, these two codes would be exactly equivalent::

  // Declarations
  class A { ... };

  template <typename T> class B { ... };

  // Existing syntax
  A::A(...) { ... }
  void A::foo(...) { ... }
  int A::value =3D ...;

  template <typename T> B<T>::B(...) { ... }
  template <typename T> B<T>& B<T>::operator=3D(B<T> const& other) { ... =
}
  template <typename T> void B<T>::bar(...) { ... }

  // Proposed syntax
  namespace class A {
    A(...) { ... }
    void foo() { ... }
    int value =3D ...;
  }

  template <typename T>
  namespace class B<T> {
    B(...) { ... }
    B<T>& operator=3D(B<T> const& other) { ... }
    void bar(...) { ... }
  }

Additionally, ``namespace struct`` and ``namespace class`` shall be equiv=
alent and interchangeable.


Discussion
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The proposed syntax for introducing the scope is open for debate. Alterna=
tive suggestions include:

#. ``class namespace <name>``
#. ``namespace <classname>``
#. Introduction of a new keyword.

The author considers #1 to be equally as good as the suggested syntax. #2=
 is nearly as good, although it risks confusion, as the reader must know =
a priori if the named scope is a class. The #2 syntax would only introduc=
e a class name scope if the identifier following the ``namespace`` keywor=
d is an already declared class-type. #3 has the advantage of maximum poss=
ible clarity, but introducing new keywords without breaking existing code=
 is always tricky. Additionally, the author was unable to come up with an=
y ideas for new keywords that seemed a significant improvement over the o=
ther suggestions.


Possible Additions
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

A potential addition to the proposal in the case of template classes woul=
d be to assume the same template parameters when the class name appears w=
ithout a template argument list. For example::

  template <typename T>
  namespace class B<T> {
    B& operator=3D(B const& other) { ... }
  }

Using only the above rules, this would be equivalent to::

  template <typename T> B& B<T>::operator=3D(B const& other) { ... } // e=
rror

=2E..which is illegal because the template type ``B`` is used without an =
argument list. This is currently an issue because the use of ``B`` specif=
ying the context of the member function follows the use of ``B`` as a ret=
urn type. Since the typical use is to use the same arguments as the membe=
r context, and since the member context has been declared as the enclosin=
g scope, it becomes much more practical to treat a use of the class name =
without a template argument list as having the same template arguments as=
 the enclosing scope. (Cases where this is not correct would be able to p=
rovide a template argument list as usual.)

However, the use of trailing and inferred return types already mitigates =
this significantly::

  template <typename T> auto B<T>::operator=3D(B const& other) -> B& {  }=
 // okay in C++11 or later

The author feels that a decision whether or not to include this definitio=
n should be based mainly on a "principle of least surprise" given code su=
ch as the first example in this section.


Acknowledgments
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The original suggestion that spawned this proposal comes from John Yates.=
 Other contemporary participants include Larry Evans, Russell Greene, Eva=
n Teran and Andrew Tomazos. (The author also acknowledges prior discussio=
n of a very similar feature: 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.)

=2E. |--| unicode:: U+02014 .. em dash

--------------060201070801010600030401--


.

What about template specialization? Can I have a general template
class definition, and then use different specialized class namespaces
for it?

--

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

.

Am 19.11.2015 um 20:42 schrieb Matthew Woehlke:
> I've written up a draft proposal for a "class namespace" feature based
> on the recent thread=C2=B9. In short, it introduces the new syntax:
>
>    template <...> // optional
>    namespace class Foo
>    {
>      Foo(...) { ... }
>      void foo(...) { ... }
>    }
>
> ...which is equivalent to:
>
>    template <...> Foo<...>::Foo(...) { ... }
>    template <...> void Foo<...>::foo(...) { ... }
>
> Basically, it allows one to "hoist" the class name (along with template
> specifications) out of a collection of out-of-line class member
> definitions and into a block scope. The class name (and template bits)
> are then implicitly applied to all definitions within said scope.
>
> I'm attaching the current version for you lazy people that like to see
> it in-line :-). You can also find the up to date version (with pretty
> HTML formatting) at
> https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-class-namespace/PXXXX=
%20Class%20Namespace.rst.
>
> Comments appreciated, especially pointing out anything I've missed.
>
> (=C2=B9
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/e0_ceX=
FQX-A)
>
(1) Considering the syntax: we have contextual keywords now.

template<...> // optional
class Foo implementation
{
   ...
}

Just in case people are opposed to "namespace" (or any other existing=20
keyword that doesn't "quite fit").

(2) Why the necessity to repeat the template arguments in
template<class T>
namespace class B<T> { }
?

The leading template declaration should be unambiguous and IMHO the=20
syntax should be as analogous to a normal class definition as possible,=20
including the use for (partial) template specializations

template<class T>
namespace class B { void bar() { } } // implement template<class T> void=20
B<T>::bar()

template<>
namespace class B<int> { void bar() { } } // implement void B<int>::bar()

The latter requires a preceding definiton of template<> class B<int> to=20
be well-formed.

--=20

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

.

On 2015-11-19 15:07, Bjorn Reese wrote:
> What about template specialization? Can I have a general template
> class definition, and then use different specialized class namespaces
> for it?

Do you mean like this?

  template <> namespace class specialized<int, 5>
  {
    ...
  }

....?

Yes, of course you can. The "rule" is that this:

  [<template_args>] namespace class <name> {
    [<type>] <member_name><...>
  }

....is equivalent to this:

  [<template_args>] [<type>] <name>::<member_name><...>

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

.

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

I really like it. One question I would have is how this works with template
specializations.

I would propose it just looks like the current class syntax, just with the
template parameters after the class.

On Thu, Nov 19, 2015, 12:43 PM Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> I've written up a draft proposal for a "class namespace" feature based
> on the recent thread=C2=B9. In short, it introduces the new syntax:
>
>   template <...> // optional
>   namespace class Foo
>   {
>     Foo(...) { ... }
>     void foo(...) { ... }
>   }
>
> ...which is equivalent to:
>
>   template <...> Foo<...>::Foo(...) { ... }
>   template <...> void Foo<...>::foo(...) { ... }
>
> Basically, it allows one to "hoist" the class name (along with template
> specifications) out of a collection of out-of-line class member
> definitions and into a block scope. The class name (and template bits)
> are then implicitly applied to all definitions within said scope.
>
> I'm attaching the current version for you lazy people that like to see
> it in-line :-). You can also find the up to date version (with pretty
> HTML formatting) at
>
> https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-class-namespace/PXXXX=
%20Class%20Namespace.rst
> .
>
> Comments appreciated, especially pointing out anything I've missed.
>
> (=C2=B9
>
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/e0_ceX=
FQX-A
> )
>
> --
> 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/.
>

--=20

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

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

<p dir=3D"ltr">I really like it. One question I would have is how this work=
s with template specializations. </p>
<p dir=3D"ltr">I would propose it just looks like the current class syntax,=
 just with the template parameters after the class. </p>

<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Nov 19, 2015, 12:43=
 PM=C2=A0Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke.floss@gmail.com" ta=
rget=3D"_blank">mwoehlke.floss@gmail.com</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">I&#39;ve written up a draft proposal for a &quot;class=
 namespace&quot; feature based<br>
on the recent thread=C2=B9. In short, it introduces the new syntax:<br>
<br>
=C2=A0 template &lt;...&gt; // optional<br>
=C2=A0 namespace class Foo<br>
=C2=A0 {<br>
=C2=A0 =C2=A0 Foo(...) { ... }<br>
=C2=A0 =C2=A0 void foo(...) { ... }<br>
=C2=A0 }<br>
<br>
....which is equivalent to:<br>
<br>
=C2=A0 template &lt;...&gt; Foo&lt;...&gt;::Foo(...) { ... }<br>
=C2=A0 template &lt;...&gt; void Foo&lt;...&gt;::foo(...) { ... }<br>
<br>
Basically, it allows one to &quot;hoist&quot; the class name (along with te=
mplate<br>
specifications) out of a collection of out-of-line class member<br>
definitions and into a block scope. The class name (and template bits)<br>
are then implicitly applied to all definitions within said scope.<br>
<br>
I&#39;m attaching the current version for you lazy people that like to see<=
br>
it in-line :-). You can also find the up to date version (with pretty<br>
HTML formatting) at<br>
<a href=3D"https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-class-namesp=
ace/PXXXX%20Class%20Namespace.rst" rel=3D"noreferrer" target=3D"_blank">htt=
ps://github.com/mwoehlke/cpp-proposals/blob/Pxxx-class-namespace/PXXXX%20Cl=
ass%20Namespace.rst</a>.<br>
<br>
Comments appreciated, especially pointing out anything I&#39;ve missed.<br>
<br>
(=C2=B9<br>
<a href=3D"https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposa=
ls/e0_ceXFQX-A" rel=3D"noreferrer" target=3D"_blank">https://groups.google.=
com/a/isocpp.org/forum/#!topic/std-proposals/e0_ceXFQX-A</a>)<br>
<br>
--<br>
Matthew<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</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 />

--001a1136b17a319db60524eac094--

.

------=_Part_611_39784607.1447965805113
Content-Type: multipart/alternative;
 boundary="----=_Part_612_53394795.1447965805113"

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



On Thursday, November 19, 2015 at 3:18:45 PM UTC-5, Miro Knejp wrote:
>
> Am 19.11.2015 um 20:42 schrieb Matthew Woehlke:=20
> > I've written up a draft proposal for a "class namespace" feature based=
=20
> > on the recent thread=C2=B9. In short, it introduces the new syntax:=20
> >=20
> >    template <...> // optional=20
> >    namespace class Foo=20
> >    {=20
> >      Foo(...) { ... }=20
> >      void foo(...) { ... }=20
> >    }=20
> >=20
> > ...which is equivalent to:=20
> >=20
> >    template <...> Foo<...>::Foo(...) { ... }=20
> >    template <...> void Foo<...>::foo(...) { ... }=20
> >=20
> > Basically, it allows one to "hoist" the class name (along with template=
=20
> > specifications) out of a collection of out-of-line class member=20
> > definitions and into a block scope. The class name (and template bits)=
=20
> > are then implicitly applied to all definitions within said scope.=20
> >=20
> > I'm attaching the current version for you lazy people that like to see=
=20
> > it in-line :-). You can also find the up to date version (with pretty=
=20
> > HTML formatting) at=20
> >=20
> https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-class-namespace/PXXXX=
%20Class%20Namespace.rst.=20
>
> >=20
> > Comments appreciated, especially pointing out anything I've missed.=20
> >=20
> > (=C2=B9=20
> >=20
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/e0_ceX=
FQX-A)=20
>
> >=20
> (1) Considering the syntax: we have contextual keywords now.=20
>
> template<...> // optional=20
> class Foo implementation=20
> {=20
>    ...=20
> }
>

OK, so what does this mean:

class implementation
{
};

Is `implementation` here an identifier or the contextual keyword?

Also, what about the final semicolon? The nice thing about `class=20
namespace` is that, since it has `namespace` there, you can argue that you=
=20
don't need a semicolon. But since this looks exactly like a class=20
definition, people will be expecting the semicolon.
=20

>
> Just in case people are opposed to "namespace" (or any other existing=20
> keyword that doesn't "quite fit").=20
>
> (2) Why the necessity to repeat the template arguments in=20
> template<class T>=20
> namespace class B<T> { }=20
> ?=20
>

So that you can have template specialization syntax:

template<typename T>
class B
{
};

template<>
class B<X>
{
};

template<typename T>
namespace class B<T>
{
}

template<>
namespace class B<X>
{
}

The leading template declaration should be unambiguous and IMHO the=20
> syntax should be as analogous to a normal class definition as possible,=
=20
> including the use for (partial) template specializations
>

No, it should not be analogous to a class definition. "Normal class=20
definitions" can add members; these declarations cannot. "Normal class=20
definitions" can declare access classes; these declarations cannot.

This is not a normal class definition, and attempting to make it look like=
=20
it is is not a good idea.=20

--=20

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

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

<br><br>On Thursday, November 19, 2015 at 3:18:45 PM UTC-5, Miro Knejp wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">Am 19.11.2015 um 20:42 schri=
eb Matthew Woehlke:
<br>&gt; I&#39;ve written up a draft proposal for a &quot;class namespace&q=
uot; feature based
<br>&gt; on the recent thread=C2=B9. In short, it introduces the new syntax=
:
<br>&gt;
<br>&gt; =C2=A0 =C2=A0template &lt;...&gt; // optional
<br>&gt; =C2=A0 =C2=A0namespace class Foo
<br>&gt; =C2=A0 =C2=A0{
<br>&gt; =C2=A0 =C2=A0 =C2=A0Foo(...) { ... }
<br>&gt; =C2=A0 =C2=A0 =C2=A0void foo(...) { ... }
<br>&gt; =C2=A0 =C2=A0}
<br>&gt;
<br>&gt; ...which is equivalent to:
<br>&gt;
<br>&gt; =C2=A0 =C2=A0template &lt;...&gt; Foo&lt;...&gt;::Foo(...) { ... }
<br>&gt; =C2=A0 =C2=A0template &lt;...&gt; void Foo&lt;...&gt;::foo(...) { =
.... }
<br>&gt;
<br>&gt; Basically, it allows one to &quot;hoist&quot; the class name (alon=
g with template
<br>&gt; specifications) out of a collection of out-of-line class member
<br>&gt; definitions and into a block scope. The class name (and template b=
its)
<br>&gt; are then implicitly applied to all definitions within said scope.
<br>&gt;
<br>&gt; I&#39;m attaching the current version for you lazy people that lik=
e to see
<br>&gt; it in-line :-). You can also find the up to date version (with pre=
tty
<br>&gt; HTML formatting) at
<br>&gt; <a href=3D"https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-cla=
ss-namespace/PXXXX%20Class%20Namespace.rst" target=3D"_blank" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\75https%3A=
%2F%2Fgithub.com%2Fmwoehlke%2Fcpp-proposals%2Fblob%2FPxxx-class-namespace%2=
FPXXXX%2520Class%2520Namespace.rst\46sa\75D\46sntz\0751\46usg\75AFQjCNHzOoB=
JLGk6b57aGwxkyagkmkDjEg&#39;;return true;" onclick=3D"this.href=3D&#39;http=
s://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fmwoehlke%2Fcpp-propos=
als%2Fblob%2FPxxx-class-namespace%2FPXXXX%2520Class%2520Namespace.rst\46sa\=
75D\46sntz\0751\46usg\75AFQjCNHzOoBJLGk6b57aGwxkyagkmkDjEg&#39;;return true=
;">https://github.com/mwoehlke/<wbr>cpp-proposals/blob/Pxxx-class-<wbr>name=
space/PXXXX%20Class%<wbr>20Namespace.rst</a>.
<br>&gt;
<br>&gt; Comments appreciated, especially pointing out anything I&#39;ve mi=
ssed.
<br>&gt;
<br>&gt; (=C2=B9
<br>&gt; <a href=3D"https://groups.google.com/a/isocpp.org/forum/#!topic/st=
d-proposals/e0_ceXFQX-A" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;https://groups.google.com/a/isocpp.org/forum/#!topic/std-p=
roposals/e0_ceXFQX-A&#39;;return true;" onclick=3D"this.href=3D&#39;https:/=
/groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/e0_ceXFQX-A&#39=
;;return true;">https://groups.google.com/a/<wbr>isocpp.org/forum/#!topic/s=
td-<wbr>proposals/e0_ceXFQX-A</a>)
<br>&gt;
<br>(1) Considering the syntax: we have contextual keywords now.
<br>
<br>template&lt;...&gt; // optional
<br>class Foo implementation
<br>{
<br>=C2=A0 =C2=A0...
<br>}<br></blockquote><div><br>OK, so what does this mean:<br><br>class imp=
lementation<br>{<br>};<br><br>Is `implementation` here an identifier or the=
 contextual keyword?<br><br>Also, what about the final semicolon? The nice =
thing about `class namespace` is that, since it has `namespace` there, you =
can argue that you don&#39;t need a semicolon. But since this looks exactly=
 like a class definition, people will be expecting the semicolon.<br>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Just in case people are opposed to &quot;namespace&quot; (or any other =
existing=20
<br>keyword that doesn&#39;t &quot;quite fit&quot;).
<br>
<br>(2) Why the necessity to repeat the template arguments in
<br>template&lt;class T&gt;
<br>namespace class B&lt;T&gt; { }
<br>?
<br></blockquote><div><br>So that you can have template specialization synt=
ax:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 2=
50, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wid=
th: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">t=
emplate</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt=
;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">typename<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><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: #008;" class=3D"styled-by-prettify">class</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> B<br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cla=
ss=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-b=
y-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">template</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&lt;&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> B</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">X</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: #=
660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cla=
ss=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-b=
y-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">template</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">typename</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">namespace</span><spa=
n 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"c=
olor: #000;" class=3D"styled-by-prettify"> B</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></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><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">template</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&lt;&gt;</span><span =
style=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"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"> B</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">X</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><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></c=
ode></div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
The leading template declaration should be unambiguous and IMHO the=20
<br>syntax should be as analogous to a normal class definition as possible,=
=20
<br>including the use for (partial) template specializations<br></blockquot=
e><div><br>No, it should not be analogous to a class definition. &quot;Norm=
al class definitions&quot; can add members; these declarations cannot. &quo=
t;Normal class definitions&quot; can declare access classes; these declarat=
ions cannot.<br><br>This is not a normal class definition, and attempting t=
o make it look like it is is not a good idea. </div><br>

<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_612_53394795.1447965805113--
------=_Part_611_39784607.1447965805113--

.

On 2015-11-19 15:19, Miro Knejp wrote:
> (1) Considering the syntax: we have contextual keywords now.
>
> template<...> // optional
> class Foo implementation
> {
>   ...
> }
>
> Just in case people are opposed to "namespace" (or any other existing
> keyword that doesn't "quite fit").

That could work. Thanks; added to the 'alternative syntaxes' list.

> (2) Why the necessity to repeat the template arguments in
> template<class T>
> namespace class B<T> { }
> ?

Why do you have to repeat them in C++98? I guess you can have this:

  template <typename T> Foo::foo(...) { ... }
  // Is that Foo<T>::foo or Foo::foo<T>?

....but it seems like the compiler would already know that (recall that
Foo::foo(...) must have been declared already since it is a class
member). So I wonder if there is some reason I am missing why this could
be an issue. However, I added it to the Possible Additions section.

> The leading template declaration should be unambiguous and IMHO the
> syntax should be as analogous to a normal class definition as possible,
> including the use for (partial) template specializations
>
> template<class T>
> namespace class B { void bar() { } } // implement template<class T> void
> B<T>::bar()
>
> template<>
> namespace class B<int> { void bar() { } } // implement void B<int>::bar()
>
> The latter requires a preceding definiton of template<> class B<int> to
> be well-formed.

Why? I can partially specialize a member without partially specializing
the whole class. Why would class name scope suddenly add that requirement?

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

.

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

I think that it shouldn't look like a regular class definition for the
reasons above.

It could become really misleading to the programmers that have to learn
about this stuff.

Then again, the namespace class idea isn't exactly intuitive either, but at
least it doesn't feel like you can declare stuff.

PS sorry for emailing the template specialization question after it had
already asked. I wrote it then sent it later.

On Thu, Nov 19, 2015, 1:56 PM Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2015-11-19 15:19, Miro Knejp wrote:
> > (1) Considering the syntax: we have contextual keywords now.
> >
> > template<...> // optional
> > class Foo implementation
> > {
> >   ...
> > }
> >
> > Just in case people are opposed to "namespace" (or any other existing
> > keyword that doesn't "quite fit").
>
> That could work. Thanks; added to the 'alternative syntaxes' list.
>
> > (2) Why the necessity to repeat the template arguments in
> > template<class T>
> > namespace class B<T> { }
> > ?
>
> Why do you have to repeat them in C++98? I guess you can have this:
>
>   template <typename T> Foo::foo(...) { ... }
>   // Is that Foo<T>::foo or Foo::foo<T>?
>
> ...but it seems like the compiler would already know that (recall that
> Foo::foo(...) must have been declared already since it is a class
> member). So I wonder if there is some reason I am missing why this could
> be an issue. However, I added it to the Possible Additions section.
>
> > The leading template declaration should be unambiguous and IMHO the
> > syntax should be as analogous to a normal class definition as possible,
> > including the use for (partial) template specializations
> >
> > template<class T>
> > namespace class B { void bar() { } } // implement template<class T> void
> > B<T>::bar()
> >
> > template<>
> > namespace class B<int> { void bar() { } } // implement void B<int>::bar()
> >
> > The latter requires a preceding definiton of template<> class B<int> to
> > be well-formed.
>
> Why? I can partially specialize a member without partially specializing
> the whole class. Why would class name scope suddenly add that requirement?
>
> --
> 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/.
>

--

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

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

<p dir=3D"ltr">I think that it shouldn&#39;t look like a regular class defi=
nition for the reasons above. </p>
<p dir=3D"ltr">It could become really misleading to the programmers that ha=
ve to learn about this stuff. </p>
<p dir=3D"ltr">Then again, the namespace class idea isn&#39;t exactly intui=
tive either, but at least it doesn&#39;t feel like you can declare stuff. <=
/p>
<p dir=3D"ltr">PS sorry for emailing the template specialization question a=
fter it had already asked. I wrote it then sent it later. </p>
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Nov 19, 2015, 1:56 =
PM=C2=A0Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke.floss@gmail.com">mwo=
ehlke.floss@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">On 2015-11-19 15:19, Miro Knejp wrote:<br>
&gt; (1) Considering the syntax: we have contextual keywords now.<br>
&gt;<br>
&gt; template&lt;...&gt; // optional<br>
&gt; class Foo implementation<br>
&gt; {<br>
&gt;=C2=A0 =C2=A0...<br>
&gt; }<br>
&gt;<br>
&gt; Just in case people are opposed to &quot;namespace&quot; (or any other=
 existing<br>
&gt; keyword that doesn&#39;t &quot;quite fit&quot;).<br>
<br>
That could work. Thanks; added to the &#39;alternative syntaxes&#39; list.<=
br>
<br>
&gt; (2) Why the necessity to repeat the template arguments in<br>
&gt; template&lt;class T&gt;<br>
&gt; namespace class B&lt;T&gt; { }<br>
&gt; ?<br>
<br>
Why do you have to repeat them in C++98? I guess you can have this:<br>
<br>
=C2=A0 template &lt;typename T&gt; Foo::foo(...) { ... }<br>
=C2=A0 // Is that Foo&lt;T&gt;::foo or Foo::foo&lt;T&gt;?<br>
<br>
....but it seems like the compiler would already know that (recall that<br>
Foo::foo(...) must have been declared already since it is a class<br>
member). So I wonder if there is some reason I am missing why this could<br=
>
be an issue. However, I added it to the Possible Additions section.<br>
<br>
&gt; The leading template declaration should be unambiguous and IMHO the<br=
>
&gt; syntax should be as analogous to a normal class definition as possible=
,<br>
&gt; including the use for (partial) template specializations<br>
&gt;<br>
&gt; template&lt;class T&gt;<br>
&gt; namespace class B { void bar() { } } // implement template&lt;class T&=
gt; void<br>
&gt; B&lt;T&gt;::bar()<br>
&gt;<br>
&gt; template&lt;&gt;<br>
&gt; namespace class B&lt;int&gt; { void bar() { } } // implement void B&lt=
;int&gt;::bar()<br>
&gt;<br>
&gt; The latter requires a preceding definiton of template&lt;&gt; class B&=
lt;int&gt; to<br>
&gt; be well-formed.<br>
<br>
Why? I can partially specialize a member without partially specializing<br>
the whole class. Why would class name scope suddenly add that requirement?<=
br>
<br>
--<br>
Matthew<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</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 />

--001a11369cb6b461d70524eb10dc--

.

On 2015-11-19 15:43, Nicol Bolas wrote:
> OK, so what does this mean:
>
> class implementation
> {
> };
>
> Is `implementation` here an identifier or the contextual keyword?

Identifier. The context of the contextual keyword is "following the
class name".

Note:

  class final {}; // class named "final"
  class A final {}; // class "A" which cannot be subclassed

....so there's precedent already.

> On Thursday, November 19, 2015 at 3:18:45 PM UTC-5, Miro Knejp wrote:
>> (2) Why the necessity to repeat the template arguments in
>> template<class T>
>> namespace class B<T> { }
>> ?
>
> So that you can have template specialization syntax:
>
> template<typename T>
> class B
> {
> };
>
> template<>
> class B<X>
> {
> };
>
> template<typename T>
> namespace class B<T>
> {
> }
>
> template<>
> namespace class B<X>
> {
> }

....but this can be *optional*. The compiler knows that template
arguments are supposed to be present. If they aren't, is there a problem
defaulting to the "obvious" arguments?

>> The leading template declaration should be unambiguous and IMHO the
>> syntax should be as analogous to a normal class definition as possible,
>> including the use for (partial) template specializations
>
> No, it should not be analogous to a class definition. "Normal class
> definitions" can add members; these declarations cannot. "Normal class
> definitions" can declare access classes; these declarations cannot.

Right. It should act more like a namespace (except that, again, you
can't add things).

> This is not a normal class definition, and attempting to make it look like
> it is is not a good idea.

Agreed. (And on that note, I'll point out that access specifiers in here
are not permitted.)

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

.

This is a multi-part message in MIME format.
--------------060709060406070200090806
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Am 19.11.2015 um 21:43 schrieb Nicol Bolas:
>
>
> On Thursday, November 19, 2015 at 3:18:45 PM UTC-5, Miro Knejp wrote:
>
>     Am 19.11.2015 um 20:42 schrieb Matthew Woehlke:
>     > I've written up a draft proposal for a "class namespace" feature
>     based
>     > on the recent thread=C2=B9. In short, it introduces the new syntax:
>     >
>     >    template <...> // optional
>     >    namespace class Foo
>     >    {
>     >      Foo(...) { ... }
>     >      void foo(...) { ... }
>     >    }
>     >
>     > ...which is equivalent to:
>     >
>     >    template <...> Foo<...>::Foo(...) { ... }
>     >    template <...> void Foo<...>::foo(...) { ... }
>     >
>     > Basically, it allows one to "hoist" the class name (along with
>     template
>     > specifications) out of a collection of out-of-line class member
>     > definitions and into a block scope. The class name (and template
>     bits)
>     > are then implicitly applied to all definitions within said scope.
>     >
>     > I'm attaching the current version for you lazy people that like
>     to see
>     > it in-line :-). You can also find the up to date version (with
>     pretty
>     > HTML formatting) at
>     >
>     https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-class-namespace/P=
XXXX%20Class%20Namespace.rst
>     <https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-class-namespace/=
PXXXX%20Class%20Namespace.rst>.
>
>     >
>     > Comments appreciated, especially pointing out anything I've missed.
>     >
>     > (=C2=B9
>     >
>     https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/e0=
_ceXFQX-A
>     <https://groups.google.com/a/isocpp.org/forum/#%21topic/std-proposals=
/e0_ceXFQX-A>)
>
>     >
>     (1) Considering the syntax: we have contextual keywords now.
>
>     template<...> // optional
>     class Foo implementation
>     {
>        ...
>     }
>
>
> OK, so what does this mean:
>
> class implementation
> {
> };
>
> Is `implementation` here an identifier or the contextual keyword?
OK, so what does this mean:

class final
{
};

Is "final" here an identifier or the contextual keyword?

Same rules apply. Before you start yelling "anonymous class": how=20
exactly would you re-open the scope of an anonymous class without=20
resolving to decltype?
>
> Also, what about the final semicolon? The nice thing about `class=20
> namespace` is that, since it has `namespace` there, you can argue that=20
> you don't need a semicolon. But since this looks exactly like a class=20
> definition, people will be expecting the semicolon.
Make it optional or wait for feedback from more than 2 people. I didn't=20
say I dislike "namespace" I just reminded of a second approach in case=20
the keyword re-use falls on deaf ears and should be mentioned in the=20
proposal's discussion as a viable alternative.
>
>
>     Just in case people are opposed to "namespace" (or any other existing
>     keyword that doesn't "quite fit").
>
>     (2) Why the necessity to repeat the template arguments in
>     template<class T>
>     namespace class B<T> { }
>     ?
>
>
> So that you can have template specialization syntax:
Did you just not bother reading he rest of my reply?
> |
> template<typenameT>
> classB
> {
> };
>
> template<>
> classB<X>
> {
> };
>
> template<typenameT>
> namespaceclassB<T>
> {
> }
>
> template<>
> namespaceclassB<X>
> {
> }
> |
>
>     The leading template declaration should be unambiguous and IMHO the
>     syntax should be as analogous to a normal class definition as
>     possible,
>     including the use for (partial) template specializations
>
>
> No, it should not be analogous to a class definition. "Normal class=20
> definitions" can add members; these declarations cannot. "Normal class=20
> definitions" can declare access classes; these declarations cannot.
>
> This is not a normal class definition, and attempting to make it look=20
> like it is is not a good idea.
Why? By making the introductory template definition as close as possible=20
to the actual definiton people don't have to learn a completely new=20
grammar "Do I have to put the template parameter here or not? Why do I=20
have to here but not there? Oh C++ is so inconsistent and stupid". The=20
additional keyword already tells them it's something different.

template<class T> class B { };
template<class T> namespace class B { }

template<> class B<X> { };
template<> namespace class B<X> { }

template<class T, class U> class C { };
template<class T, class U> namespace class C { }

template<class T> class C<T, X> { };
template<class T> namespace class C<T, X> { }

It's consistent so people can use the grammar they already know and=20
understand instead of inventing new rules which unnecessarily complicate=20
the proposal and user experience.

--=20

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

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    Am 19.11.2015 um 21:43 schrieb Nicol Bolas:<br>
    <blockquote
      cite=3D"mid:b8c6743e-953b-4c42-b27d-ae831e5dc51c@isocpp.org"
      type=3D"cite"><br>
      <br>
      On Thursday, November 19, 2015 at 3:18:45 PM UTC-5, Miro Knejp
      wrote:
      <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Am
        19.11.2015 um 20:42 schrieb Matthew Woehlke:
        <br>
        &gt; I've written up a draft proposal for a "class namespace"
        feature based
        <br>
        &gt; on the recent thread=C2=B9. In short, it introduces the new
        syntax:
        <br>
        &gt;
        <br>
        &gt; =C2=A0 =C2=A0template &lt;...&gt; // optional
        <br>
        &gt; =C2=A0 =C2=A0namespace class Foo
        <br>
        &gt; =C2=A0 =C2=A0{
        <br>
        &gt; =C2=A0 =C2=A0 =C2=A0Foo(...) { ... }
        <br>
        &gt; =C2=A0 =C2=A0 =C2=A0void foo(...) { ... }
        <br>
        &gt; =C2=A0 =C2=A0}
        <br>
        &gt;
        <br>
        &gt; ...which is equivalent to:
        <br>
        &gt;
        <br>
        &gt; =C2=A0 =C2=A0template &lt;...&gt; Foo&lt;...&gt;::Foo(...) { .=
... }
        <br>
        &gt; =C2=A0 =C2=A0template &lt;...&gt; void Foo&lt;...&gt;::foo(...=
) { ...
        }
        <br>
        &gt;
        <br>
        &gt; Basically, it allows one to "hoist" the class name (along
        with template
        <br>
        &gt; specifications) out of a collection of out-of-line class
        member
        <br>
        &gt; definitions and into a block scope. The class name (and
        template bits)
        <br>
        &gt; are then implicitly applied to all definitions within said
        scope.
        <br>
        &gt;
        <br>
        &gt; I'm attaching the current version for you lazy people that
        like to see
        <br>
        &gt; it in-line :-). You can also find the up to date version
        (with pretty
        <br>
        &gt; HTML formatting) at
        <br>
        &gt; <a moz-do-not-send=3D"true"
href=3D"https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-class-namespace=
/PXXXX%20Class%20Namespace.rst"
          target=3D"_blank" rel=3D"nofollow"
          onmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%=
3A%2F%2Fgithub.com%2Fmwoehlke%2Fcpp-proposals%2Fblob%2FPxxx-class-namespace=
%2FPXXXX%2520Class%2520Namespace.rst\46sa\75D\46sntz\0751\46usg\75AFQjCNHzO=
oBJLGk6b57aGwxkyagkmkDjEg';return
          true;"
          onclick=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2=
F%2Fgithub.com%2Fmwoehlke%2Fcpp-proposals%2Fblob%2FPxxx-class-namespace%2FP=
XXXX%2520Class%2520Namespace.rst\46sa\75D\46sntz\0751\46usg\75AFQjCNHzOoBJL=
Gk6b57aGwxkyagkmkDjEg';return
          true;">https://github.com/mwoehlke/<wbr>cpp-proposals/blob/Pxxx-c=
lass-<wbr>namespace/PXXXX%20Class%<wbr>20Namespace.rst</a>.
        <br>
        &gt;
        <br>
        &gt; Comments appreciated, especially pointing out anything I've
        missed.
        <br>
        &gt;
        <br>
        &gt; (=C2=B9
        <br>
        &gt; <a moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/forum/#%21topic/std-proposal=
s/e0_ceXFQX-A"
          target=3D"_blank" rel=3D"nofollow"
          onmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.or=
g/forum/#!topic/std-proposals/e0_ceXFQX-A';return
          true;"
          onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/fo=
rum/#!topic/std-proposals/e0_ceXFQX-A';return
          true;">https://groups.google.com/a/<wbr>isocpp.org/forum/#!topic/=
std-<wbr>proposals/e0_ceXFQX-A</a>)
        <br>
        &gt;
        <br>
        (1) Considering the syntax: we have contextual keywords now.
        <br>
        <br>
        template&lt;...&gt; // optional
        <br>
        class Foo implementation
        <br>
        {
        <br>
        =C2=A0 =C2=A0...
        <br>
        }<br>
      </blockquote>
      <div><br>
        OK, so what does this mean:<br>
        <br>
        class implementation<br>
        {<br>
        };<br>
        <br>
        Is `implementation` here an identifier or the contextual
        keyword?<br>
      </div>
    </blockquote>
    OK, so what does this mean:<br>
    <br>
    class final<br>
    {<br>
    };<br>
    <br>
    Is "final" here an identifier or the contextual keyword?<br>
    <br>
    Same rules apply. Before you start yelling "anonymous class": how
    exactly would you re-open the scope of an anonymous class without
    resolving to decltype?
    <blockquote
      cite=3D"mid:b8c6743e-953b-4c42-b27d-ae831e5dc51c@isocpp.org"
      type=3D"cite">
      <div><br>
        Also, what about the final semicolon? The nice thing about
        `class namespace` is that, since it has `namespace` there, you
        can argue that you don't need a semicolon. But since this looks
        exactly like a class definition, people will be expecting the
        semicolon.<br>
      </div>
    </blockquote>
    Make it optional or wait for feedback from more than 2 people. I
    didn't say I dislike "namespace" I just reminded of a second
    approach in case the keyword re-use falls on deaf ears and should be
    mentioned in the proposal's discussion as a viable alternative.<br>
    <blockquote
      cite=3D"mid:b8c6743e-953b-4c42-b27d-ae831e5dc51c@isocpp.org"
      type=3D"cite">
      <div>=C2=A0</div>
      <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
        <br>
        Just in case people are opposed to "namespace" (or any other
        existing <br>
        keyword that doesn't "quite fit").
        <br>
        <br>
        (2) Why the necessity to repeat the template arguments in
        <br>
        template&lt;class T&gt;
        <br>
        namespace class B&lt;T&gt; { }
        <br>
        ?
        <br>
      </blockquote>
      <div><br>
        So that you can have template specialization syntax:<br>
      </div>
    </blockquote>
    Did you just not bother reading he rest of my reply?<br>
    <blockquote
      cite=3D"mid:b8c6743e-953b-4c42-b27d-ae831e5dc51c@isocpp.org"
      type=3D"cite">
      <div>
        <div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,
          250); border-color: rgb(187, 187, 187); border-style: solid;
          border-width: 1px; word-wrap: break-word;"><code
            class=3D"prettyprint">
            <div class=3D"subprettyprint"><span style=3D"color: #008;"
                class=3D"styled-by-prettify">template</span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</s=
pan><span
                style=3D"color: #008;" class=3D"styled-by-prettify">typenam=
e</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> T</spa=
n><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><span style=3D"color: #008;"
                class=3D"styled-by-prettify">class</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> B<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><span style=3D"color:
                #000;" class=3D"styled-by-prettify"><br>
                <br>
              </span><span style=3D"color: #008;"
                class=3D"styled-by-prettify">template</span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">&lt;&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"> B</spa=
n><span
                style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</s=
pan><span
                style=3D"color: #000;" class=3D"styled-by-prettify">X</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><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><span style=3D"color:
                #000;" class=3D"styled-by-prettify"><br>
                <br>
              </span><span style=3D"color: #008;"
                class=3D"styled-by-prettify">template</span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</s=
pan><span
                style=3D"color: #008;" class=3D"styled-by-prettify">typenam=
e</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> T</spa=
n><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><span style=3D"color: #008;"
                class=3D"styled-by-prettify">namespace</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"> B</spa=
n><span
                style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</s=
pan><span
                style=3D"color: #000;" class=3D"styled-by-prettify">T</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><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><span style=3D"color:
                #000;" class=3D"styled-by-prettify"><br>
                <br>
              </span><span style=3D"color: #008;"
                class=3D"styled-by-prettify">template</span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">&lt;&gt=
;</span><span
                style=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"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"> B</spa=
n><span
                style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</s=
pan><span
                style=3D"color: #000;" class=3D"styled-by-prettify">X</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><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>
        <br>
      </div>
      <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
        The leading template declaration should be unambiguous and IMHO
        the <br>
        syntax should be as analogous to a normal class definition as
        possible, <br>
        including the use for (partial) template specializations<br>
      </blockquote>
      <div><br>
        No, it should not be analogous to a class definition. "Normal
        class definitions" can add members; these declarations cannot.
        "Normal class definitions" can declare access classes; these
        declarations cannot.<br>
        <br>
        This is not a normal class definition, and attempting to make it
        look like it is is not a good idea. </div>
    </blockquote>
    Why? By making the introductory template definition as close as
    possible to the actual definiton people don't have to learn a
    completely new grammar "Do I have to put the template parameter here
    or not? Why do I have to here but not there? Oh C++ is so
    inconsistent and stupid". The additional keyword already tells them
    it's something different.<br>
    <br>
    template&lt;class T&gt; class B { };<br>
    template&lt;class T&gt; namespace class B { }<br>
    <br>
    template&lt;&gt; class B&lt;X&gt; { };<br>
    template&lt;&gt; namespace class B&lt;X&gt; { }<br>
    <br>
    template&lt;class T, class U&gt; class C { };<br>
    template&lt;class T, class U&gt; namespace class C { }<br>
    <br>
    template&lt;class T&gt; class C&lt;T, X&gt; { };<br>
    template&lt;class T&gt; namespace class C&lt;T, X&gt; { }<br>
    <br>
    It's consistent so people can use the grammar they already know and
    understand instead of inventing new rules which unnecessarily
    complicate the proposal and user experience.<br>
    <br>
  </body>
</html>

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

--------------060709060406070200090806--

.

On 2015-11-19 16:10, Miro Knejp wrote:
> class final
> {
> };

(Heh... beat you to it :-), though not by enough you would have seen my
reply before sending yours.)

> Is "final" here an identifier or the contextual keyword?
>
> Same rules apply. Before you start yelling "anonymous class": how
> exactly would you re-open the scope of an anonymous class without
> resolving to decltype?

Weeeeelll....

  class { void none(); } x;
  void decltype(x)::none() {}

....so:

  class decltype(x) implementation
  {
    void none() { ... }
  }

....which, yeah, uses decltype. The first example is legal, though, so
the second one would also be legal per the proposal. And, yeah, don't
see a problem with the contextual keyword syntax for doing it since as
you note you have to name the class *somehow*.

> Am 19.11.2015 um 21:43 schrieb Nicol Bolas:
>> Also, what about the final semicolon? The nice thing about `class
>> namespace` is that, since it has `namespace` there, you can argue that
>> you don't need a semicolon. But since this looks exactly like a class
>> definition, people will be expecting the semicolon.
>
> Make it optional or wait for feedback from more than 2 people.

IMHO, it should be optional. Consider:

  namespace { ... }; // legal today

(So, basically, if we don't require it, it's implicitly optional because
a stray ';' at global scope is already permitted.)

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

.

Am 19.11.2015 um 21:56 schrieb Matthew Woehlke:
> On 2015-11-19 15:19, Miro Knejp wrote:
>> (1) Considering the syntax: we have contextual keywords now.
>>
>> template<...> // optional
>> class Foo implementation
>> {
>>    ...
>> }
>>
>> Just in case people are opposed to "namespace" (or any other existing
>> keyword that doesn't "quite fit").
> That could work. Thanks; added to the 'alternative syntaxes' list.
Another minor nitpick. From a pure "English language" point of view
"class namespace" is more accurate than "namespace class" (since you're
opening the name space of a class, not a class that is a namespace).
Both are currently ill-formed so I guess it's just a matter of preference.
>
>> (2) Why the necessity to repeat the template arguments in
>> template<class T>
>> namespace class B<T> { }
>> ?
> Why do you have to repeat them in C++98? I guess you can have this:
>
>    template <typename T> Foo::foo(...) { ... }
>    // Is that Foo<T>::foo or Foo::foo<T>?
>
> ...but it seems like the compiler would already know that (recall that
> Foo::foo(...) must have been declared already since it is a class
> member). So I wonder if there is some reason I am missing why this could
> be an issue. However, I added it to the Possible Additions section.
Disambiguation between Foo::foo<T>() and Foo<T>::foo(). Granted the
compiler should know the difference but the repetition provides more
context for lookup. I suspect it's for historical reasons since the
concepts proposal allows getting rid of "template" completely in many
circumstances.
>
>> The leading template declaration should be unambiguous and IMHO the
>> syntax should be as analogous to a normal class definition as possible,
>> including the use for (partial) template specializations
>>
>> template<class T>
>> namespace class B { void bar() { } } // implement template<class T> void
>> B<T>::bar()
>>
>> template<>
>> namespace class B<int> { void bar() { } } // implement void B<int>::bar()
>>
>> The latter requires a preceding definiton of template<> class B<int> to
>> be well-formed.
> Why? I can partially specialize a member without partially specializing
> the whole class. Why would class name scope suddenly add that requirement?
>
Ok, you're right. I can sepcialize B<int>::bar() without defining B<int>
so I guess that would be equally allowed. I think it's important to keep
in mind that as currently presented the proposal is only convenience
syntax that doesn't change existing semantics.

--

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

.

On 2015-11-19 16:32, Miro Knejp wrote:
> Am 19.11.2015 um 21:56 schrieb Matthew Woehlke:
>> On 2015-11-19 15:19, Miro Knejp wrote:
> Another minor nitpick. From a pure "English language" point of view
> "class namespace" is more accurate than "namespace class" (since you're
> opening the name space of a class, not a class that is a namespace).
> Both are currently ill-formed so I guess it's just a matter of preference=
..

See my previous reply=C2=B9 to the original thread where I explained why I'=
m
okay using "namespace" in the first place. To whit, I consider
"namespace" the verb, "<name of class>" the noun, and "class" an
adjective. IOW, "open blue door" vs. "blue open door".

However I'm not strongly wedded to either. The intent is to leave it to
in-person discussion to make this determination.

(=C2=B9 http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/227=
34)

> I think it's important to keep
> in mind that as currently presented the proposal is only convenience
> syntax that doesn't change existing semantics.

Exactly :-). (If you check the updated version, I added a
"Specification" section that spells it out as an equivalence transform.)

--=20
Matthew

--=20

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

.

------=_Part_2094_969210849.1448023358195
Content-Type: multipart/alternative;
 boundary="----=_Part_2095_1729090829.1448023358195"

------=_Part_2095_1729090829.1448023358195
Content-Type: text/plain; charset=UTF-8

Couple of suggestions:

Please consider the use of inner types, too (like the enum E in the below
example).  Also, you mention using the bare type B (instead of B<T>) in
declarations as a possible addition, but I believe this should be a
required feature.   In my opinion, the rules should be such that a
"namespace class" definition would look and act the same as an inline
definition, with all the name-lookup and other relevant rules applied the
same way.  That is, the following example should work:

// in-line definition:
template <typename T>
struct B {
enum E { E1, E2 };

B& operator=(const B& other) {
return *this;
}
void foo(E e) {
}
};

equivalent definition using "namespace class":

// interface
template <typename T>
struct B {
enum E { E1, E2 };
B& operator=(const B& other);

void foo(E e);
};

// implementation
template <typename T>
namespace struct B {
B& operator=(const B& other) {
return *this;
}
void foo(E e) {
}
};



I understand that specifying the exact semantics this way is a bit more
work, and (maybe) it's harder to implement, too, but I believe this way we
can achieve much better uniformity with the current practice of inline
definition.

regards,
mitch





--

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

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

<div dir=3D"ltr">Couple of suggestions:<div><br></div><div>Please consider =
the use of inner types, too (like the enum E in the below example). =C2=A0A=
lso, you mention using the bare type B (instead of B&lt;T&gt;) in declarati=
ons as a possible addition, but I believe this should be a required feature=
.. =C2=A0 In my opinion, the rules should be such that a &quot;namespace cla=
ss&quot; definition would look and act the same as an inline definition, wi=
th all the name-lookup and other relevant rules applied the same way. =C2=
=A0That is, the following example should work:</div><div><br></div><div><di=
v 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"pr=
ettyprint"><div class=3D"subprettyprint"><div class=3D"subprettyprint">// i=
n-line definition:<br>template &lt;typename T&gt;</div><div class=3D"subpre=
ttyprint">struct B {</div><div class=3D"subprettyprint"><span class=3D"Appl=
e-tab-span" style=3D"white-space:pre"> </span>enum E { E1, E2 };<br><br></d=
iv><div class=3D"subprettyprint"><span class=3D"Apple-tab-span" style=3D"wh=
ite-space:pre"> </span>B&amp; operator=3D(const B&amp; other) {</div><div c=
lass=3D"subprettyprint"><span class=3D"Apple-tab-span" style=3D"white-space=
:pre">  </span>return *this;</div><div class=3D"subprettyprint"><span class=
=3D"Apple-tab-span" style=3D"white-space:pre"> </span>}</div><div class=3D"=
subprettyprint"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> <=
/span></div><div class=3D"subprettyprint"><span class=3D"Apple-tab-span" st=
yle=3D"white-space:pre"> </span>void foo(E e) {</div><div class=3D"subprett=
yprint"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>}<=
/div><div class=3D"subprettyprint">};</div></div></code></div><div><br></di=
v>equivalent definition using &quot;namespace class&quot;:</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"><div class=3D"subprett=
yprint">// interface<br>template &lt;typename T&gt;</div><div class=3D"subp=
rettyprint">struct B {</div><div class=3D"subprettyprint"><span class=3D"Ap=
ple-tab-span" style=3D"white-space:pre"> </span>enum E { E1, E2 };</div><di=
v class=3D"subprettyprint"><span class=3D"Apple-tab-span" style=3D"white-sp=
ace:pre"> </span>B&amp; operator=3D(const B&amp; other);</div><div class=3D=
"subprettyprint"><span class=3D"Apple-tab-span" style=3D"font-family: Arial=
, Helvetica, sans-serif; white-space: pre;"> </span><br></div><div class=3D=
"subprettyprint"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> =
</span>void foo(E e);</div><div class=3D"subprettyprint"><span style=3D"fon=
t-family: Arial, Helvetica, sans-serif;">};</span><br></div><div><br>// imp=
lementation<br><div>template &lt;typename T&gt;</div><div>namespace struct =
B {<span class=3D"Apple-tab-span" style=3D"font-family: Arial, Helvetica, s=
ans-serif; white-space: pre;"> </span></div><div><span class=3D"Apple-tab-s=
pan" style=3D"white-space:pre"> </span>B&amp; operator=3D(const B&amp; othe=
r) {</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">  <=
/span>return *this;</div><div><span class=3D"Apple-tab-span" style=3D"white=
-space:pre"> </span>}</div><div><span class=3D"Apple-tab-span" style=3D"whi=
te-space:pre"> </span></div><div><span class=3D"Apple-tab-span" style=3D"wh=
ite-space:pre"> </span>void foo(E e) {</div><div><span class=3D"Apple-tab-s=
pan" style=3D"white-space:pre"> </span>}</div><div>};</div><div><br></div><=
br></div></div></code></div><br>I understand that specifying the exact sema=
ntics this way is a bit more work, and (maybe) it&#39;s harder to implement=
, too, but I believe this way we can achieve much better uniformity with th=
e current practice of inline definition.</div><div><br></div><div>regards,<=
/div><div>mitch</div><div><br></div><div><br><br></div><div><br></div><div>=
<br></div></div>

<p></p>

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

------=_Part_2095_1729090829.1448023358195--
------=_Part_2094_969210849.1448023358195--

.

On 2015-11-20 07:42, P=C3=A9ter wrote:
> Couple of suggestions:

What's your actual, full name? Your e-mail headers say "P=C3=A9ter" and you=
r
sign-off says "mitch". I'd like to credit you in the proposal (unless
you'd rather I don't), and am wondering how you would like to be credited..=
..

> Please consider the use of inner types, too (like the enum E in the below=
=20
> example).  Also, you mention using the bare type B (instead of B<T>) in=
=20
> declarations as a possible addition, but I believe this should be a=20
> required feature.   In my opinion, the rules should be such that a=20
> "namespace class" definition would look and act the same as an inline=20
> definition, with all the name-lookup and other relevant rules applied the=
=20
> same way.

I think I see what you are saying. Note that the example you gave
(elided) would work anyway (w.r.t. 'E' anyway), because it appears as a
parameter to the function. It would matter if 'E' was the return type,
because you would ordinarily (i.e. today) have to qualify it there as
B::E. IIUC, you want to be able to write just 'E', correct?

--=20
Matthew

--=20

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

.

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

Hello,

   My full name is P=C3=A9ter Radics.  Thanks for the credits :)

I didn't check your original rules fully regarding the inner types so I
didn't realize it'd work already (sorry :), I just noticed that you didn't
mention inner / nested types and wanted to make a note about that, but
indeed, my example would've been better with foo() taking E and also
returning E, just to make it clear that it should work without extra
qualification there, too.

To sum it up: I'd like "class namespace" to work exactly like inline
definitions, that is, if you yank all the inline definitions from an
existing class and paste them in a "class namespace", it should Just Work
(TM). (keeping forward declarations in the class declaration of course).

One other note: I prefer "class namespace A" over "namespace class A", but
that's really minor, I'd be happy with either.

Another more important note: you mentioned that this facility is not
designed to add new (private) functions / types / etc, which is
understandable, and probably the best approach to get this going, but I
think we should somehow keep the door open for future proposals to extend
this feature with "real private" methods and "real private" types: it would
be really nice to allow introducing new types (internal to the class
implementation) and even new private methods (again, internal to the class
implementation) into this class namespace.

Oh, and you didn't mention that this class namespace can be re-opened
multiple times or not.  I think it'd be worth mentioning that it would work
like real namespaces regarding reopening: think about one class namespace
in the header for inline definitions, and another class namespace
("reopening") in the cpp file containing out-of-line definitions.  Hope
this makes sense :)

Thanks for picking this up, hope you can get it accepted!

regards,
mitch

On Fri, Nov 20, 2015 at 3:46 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2015-11-20 07:42, P=C3=A9ter wrote:
> > Couple of suggestions:
>
> What's your actual, full name? Your e-mail headers say "P=C3=A9ter" and y=
our
> sign-off says "mitch". I'd like to credit you in the proposal (unless
> you'd rather I don't), and am wondering how you would like to be
> credited...
>
> > Please consider the use of inner types, too (like the enum E in the bel=
ow
> > example).  Also, you mention using the bare type B (instead of B<T>) in
> > declarations as a possible addition, but I believe this should be a
> > required feature.   In my opinion, the rules should be such that a
> > "namespace class" definition would look and act the same as an inline
> > definition, with all the name-lookup and other relevant rules applied t=
he
> > same way.
>
> I think I see what you are saying. Note that the example you gave
> (elided) would work anyway (w.r.t. 'E' anyway), because it appears as a
> parameter to the function. It would matter if 'E' was the return type,
> because you would ordinarily (i.e. today) have to qualify it there as
> B::E. IIUC, you want to be able to write just 'E', correct?
>
> --
> Matthew
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/MPFsRM9qQm0/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

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

<div dir=3D"ltr">Hello,<div><br></div><div>=C2=A0 =C2=A0My full name is P=
=C3=A9ter Radics.=C2=A0 Thanks for the credits :)</div><div><br></div><div>=
I didn&#39;t check your original rules fully regarding the inner types so I=
 didn&#39;t realize it&#39;d work already (sorry :), I just noticed that yo=
u didn&#39;t mention inner / nested types and wanted to make a note about t=
hat, but indeed, my example would&#39;ve been better with foo() taking E an=
d also returning E, just to make it clear that it should work without extra=
 qualification there, too.</div><div><br></div><div>To sum it up: I&#39;d l=
ike &quot;class namespace&quot; to work exactly like inline definitions, th=
at is, if you yank all the inline definitions from an existing class and pa=
ste them in a &quot;class namespace&quot;, it should Just Work (TM). (keepi=
ng forward declarations in the class declaration of course).</div><div><br>=
</div><div>One other note: I prefer &quot;class namespace A&quot; over &quo=
t;namespace class A&quot;, but that&#39;s really minor, I&#39;d be happy wi=
th either.</div><div><br></div><div>Another more important note: you mentio=
ned that this facility is not designed to add new (private) functions / typ=
es / etc, which is understandable, and probably the best approach to get th=
is going, but I think we should somehow keep the door open for future propo=
sals to extend this feature with &quot;real private&quot; methods and &quot=
;real private&quot; types: it would be really nice to allow introducing new=
 types (internal to the class implementation) and even new private methods =
(again, internal to the class implementation) into this class namespace.</d=
iv><div><br></div><div>Oh, and you didn&#39;t mention that this class names=
pace can be re-opened multiple times or not.=C2=A0 I think it&#39;d be wort=
h mentioning that it would work like real namespaces regarding reopening: t=
hink about one class namespace in the header for inline definitions, and an=
other class namespace (&quot;reopening&quot;) in the cpp file containing ou=
t-of-line definitions.=C2=A0 Hope this makes sense :)</div><div><br></div><=
div>Thanks for picking this up, hope you can get it accepted!</div><div><br=
></div><div>regards,</div><div>mitch</div></div><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Fri, Nov 20, 2015 at 3:46 PM, Matthew Woe=
hlke <span dir=3D"ltr">&lt;<a href=3D"mailto:mwoehlke.floss@gmail.com" targ=
et=3D"_blank">mwoehlke.floss@gmail.com</a>&gt;</span> wrote:<br><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">On 2015-11-20 07:42, P=C3=A9ter wrote:<br>
&gt; Couple of suggestions:<br>
<br>
What&#39;s your actual, full name? Your e-mail headers say &quot;P=C3=A9ter=
&quot; and your<br>
sign-off says &quot;mitch&quot;. I&#39;d like to credit you in the proposal=
 (unless<br>
you&#39;d rather I don&#39;t), and am wondering how you would like to be cr=
edited...<br>
<span class=3D""><br>
&gt; Please consider the use of inner types, too (like the enum E in the be=
low<br>
&gt; example).=C2=A0 Also, you mention using the bare type B (instead of B&=
lt;T&gt;) in<br>
&gt; declarations as a possible addition, but I believe this should be a<br=
>
&gt; required feature.=C2=A0 =C2=A0In my opinion, the rules should be such =
that a<br>
&gt; &quot;namespace class&quot; definition would look and act the same as =
an inline<br>
&gt; definition, with all the name-lookup and other relevant rules applied =
the<br>
&gt; same way.<br>
<br>
</span>I think I see what you are saying. Note that the example you gave<br=
>
(elided) would work anyway (w.r.t. &#39;E&#39; anyway), because it appears =
as a<br>
parameter to the function. It would matter if &#39;E&#39; was the return ty=
pe,<br>
because you would ordinarily (i.e. today) have to qualify it there as<br>
B::E. IIUC, you want to be able to write just &#39;E&#39;, correct?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Matthew<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/MPFsRM9qQm0/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/MPFsRM9qQm0/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--047d7b2e4d34910f350524fa3252--

.

On 2015-11-20 10:04, P=C3=A9ter Radics wrote:
> Hello,
>=20
>    My full name is P=C3=A9ter Radics.  Thanks for the credits :)
>=20
> I didn't check your original rules fully regarding the inner types so I
> didn't realize it'd work already (sorry :), I just noticed that you didn'=
t
> mention inner / nested types and wanted to make a note about that, but
> indeed, my example would've been better with foo() taking E and also
> returning E, just to make it clear that it should work without extra
> qualification there, too.

No worries; I figured out what you intended, and I agree that we really
ought to do name look-up that way. I've updated the proposal
accordingly. Thanks for pointing this out!

> Another more important note: you mentioned that this facility is not
> designed to add new (private) functions / types / etc, which is
> understandable, and probably the best approach to get this going, but I
> think we should somehow keep the door open for future proposals to extend
> this feature with "real private" methods and "real private" types: it wou=
ld
> be really nice to allow introducing new types (internal to the class
> implementation) and even new private methods (again, internal to the clas=
s
> implementation) into this class namespace.

Agreed on all points. I don't think anything needs to be said to that
effect; if we decide to allow that in the future (though, to be honest
my impression is that there is a lot of resistance to such changes) it
would just be adding new features.

It's off topic, but I'll note that one probable non-starter for such
features is that it breaks encapsulation. Yeah, it's sort of a catch-22.
On the one hand, the whole *point* is to not mention the private bits in
the header. On the other, if you don't, how do you prevent just anyone
from adding new privates? I suspect that PIMPL works better for this...

> Oh, and you didn't mention that this class namespace can be re-opened
> multiple times or not.

Of course it can. It's just syntax sugar for outscoping a prefix on all
the contained members. There's nothing "exclusive" about that. Just like
you would be able to mix old-style fully prefixed definitions with
definitions in a class name scope.

I added an explanatory note to the proposal text. Thanks again!

--=20
Matthew

--=20

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

.

------=_Part_230_77795495.1448036792730
Content-Type: multipart/alternative;
 boundary="----=_Part_231_1771403486.1448036792730"

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


I just wanted to say that this proposal is looking great. Thanks for taking=
=20
the time to turn the discussion into something more formal. I am really=20
hopeful that this feature gets taken seriously since I think that it is=20
very useful addition. One thing that may be worth mentioning in the=20
proposal is that similar syntax is already in the language, so this would=
=20
actually make things more consistent in some ways. Given a header with:

// Foo.h
namespace Foo {
void method();
}


We have the option of defining Foo::method() a few ways:

namespace Foo {
void method() {
    // ...
}
}


// or=20


or Foo::method() {
    // ...
}

The fact that you can't do similar for classes and structs is actually a=20
point of inconsistency.

On Thursday, November 19, 2015 at 2:43:29 PM UTC-5, Matthew Woehlke wrote:
>
> I've written up a draft proposal for a "class namespace" feature based=20
> on the recent thread=C2=B9. In short, it introduces the new syntax:=20
>
>   template <...> // optional=20
>   namespace class Foo=20
>   {=20
>     Foo(...) { ... }=20
>     void foo(...) { ... }=20
>   }=20
>
> ...which is equivalent to:=20
>
>   template <...> Foo<...>::Foo(...) { ... }=20
>   template <...> void Foo<...>::foo(...) { ... }=20
>
> Basically, it allows one to "hoist" the class name (along with template=
=20
> specifications) out of a collection of out-of-line class member=20
> definitions and into a block scope. The class name (and template bits)=20
> are then implicitly applied to all definitions within said scope.=20
>
> I'm attaching the current version for you lazy people that like to see=20
> it in-line :-). You can also find the up to date version (with pretty=20
> HTML formatting) at=20
>
> https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-class-namespace/PXXXX=
%20Class%20Namespace.rst.=20
>
>
> Comments appreciated, especially pointing out anything I've missed.=20
>
> (=C2=B9=20
>
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/e0_ceX=
FQX-A)=20
>
>
> --=20
> Matthew=20
>

--=20

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

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

<div dir=3D"ltr"><div><br></div>I just wanted to say that this proposal is =
looking great. Thanks for taking the time to turn the discussion into somet=
hing more formal. I am really hopeful that this feature gets taken seriousl=
y since I think that it is very useful addition. One thing that may be wort=
h mentioning in the proposal is that similar syntax is already in the langu=
age, so this would actually make things more consistent in some ways. Given=
 a header with:<div><br></div><div class=3D"prettyprint" style=3D"border: 1=
px solid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(2=
50, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><=
span style=3D"color: #800;" class=3D"styled-by-prettify">// Foo.h</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">namespace</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #606;" class=3D"styled-by-prettify">Foo</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"style=
d-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> method</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></div><div><br></div><div>We have the option of defi=
ning Foo::method() a few ways:</div><div><br></div><div class=3D"prettyprin=
t" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; ba=
ckground-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">namespace</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Foo</sp=
an><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">void</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> method</span><span style=3D"color: #660;" c=
lass=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 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-pret=
tify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br><br><br></span><span=
 style=3D"color: #800;" class=3D"styled-by-prettify">// or </span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br><br><br></span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">or</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">Foo</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">method</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </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></s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></div=
></code></div><div><br>The fact that you can&#39;t do similar for classes a=
nd structs is actually a point of inconsistency.<br><br>On Thursday, Novemb=
er 19, 2015 at 2:43:29 PM UTC-5, Matthew Woehlke wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;">I&#39;ve written up a draft proposal for a &quot;c=
lass namespace&quot; feature based
<br>on the recent thread=C2=B9. In short, it introduces the new syntax:
<br>
<br>=C2=A0 template &lt;...&gt; // optional
<br>=C2=A0 namespace class Foo
<br>=C2=A0 {
<br>=C2=A0 =C2=A0 Foo(...) { ... }
<br>=C2=A0 =C2=A0 void foo(...) { ... }
<br>=C2=A0 }
<br>
<br>...which is equivalent to:
<br>
<br>=C2=A0 template &lt;...&gt; Foo&lt;...&gt;::Foo(...) { ... }
<br>=C2=A0 template &lt;...&gt; void Foo&lt;...&gt;::foo(...) { ... }
<br>
<br>Basically, it allows one to &quot;hoist&quot; the class name (along wit=
h template
<br>specifications) out of a collection of out-of-line class member
<br>definitions and into a block scope. The class name (and template bits)
<br>are then implicitly applied to all definitions within said scope.
<br>
<br>I&#39;m attaching the current version for you lazy people that like to =
see
<br>it in-line :-). You can also find the up to date version (with pretty
<br>HTML formatting) at
<br><a href=3D"https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-class-na=
mespace/PXXXX%20Class%20Namespace.rst" target=3D"_blank" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2=
Fgithub.com%2Fmwoehlke%2Fcpp-proposals%2Fblob%2FPxxx-class-namespace%2FPXXX=
X%2520Class%2520Namespace.rst\46sa\75D\46sntz\0751\46usg\75AFQjCNHzOoBJLGk6=
b57aGwxkyagkmkDjEg&#39;;return true;" onclick=3D"this.href=3D&#39;https://w=
ww.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fmwoehlke%2Fcpp-proposals%2=
Fblob%2FPxxx-class-namespace%2FPXXXX%2520Class%2520Namespace.rst\46sa\75D\4=
6sntz\0751\46usg\75AFQjCNHzOoBJLGk6b57aGwxkyagkmkDjEg&#39;;return true;">ht=
tps://github.com/mwoehlke/<wbr>cpp-proposals/blob/Pxxx-class-<wbr>namespace=
/PXXXX%20Class%<wbr>20Namespace.rst</a>.
<br>
<br>Comments appreciated, especially pointing out anything I&#39;ve missed.
<br>
<br>(=C2=B9
<br><a href=3D"https://groups.google.com/a/isocpp.org/forum/#!topic/std-pro=
posals/e0_ceXFQX-A" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.=
href=3D&#39;https://groups.google.com/a/isocpp.org/forum/#!topic/std-propos=
als/e0_ceXFQX-A&#39;;return true;" onclick=3D"this.href=3D&#39;https://grou=
ps.google.com/a/isocpp.org/forum/#!topic/std-proposals/e0_ceXFQX-A&#39;;ret=
urn true;">https://groups.google.com/a/<wbr>isocpp.org/forum/#!topic/std-<w=
br>proposals/e0_ceXFQX-A</a>)
<br>
<br>--=20
<br>Matthew
<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_231_1771403486.1448036792730--
------=_Part_230_77795495.1448036792730--

.

------=_Part_2866_1042302663.1448066993674
Content-Type: multipart/alternative;
 boundary="----=_Part_2867_1567957814.1448066993674"

------=_Part_2867_1567957814.1448066993674
Content-Type: text/plain; charset=UTF-8

I like this idea a lot, but I'm sceptical to the reuse of the word
namespace. There is also another proposal that uses the same syntax with a
different meaning, which indicates that it may be non-intuitive. I like
that proposal too, which is using namespace as another protection level
besides private, protected and public; with the obvious meaning. AFAIK the
idea was not to require a namespace: on namespace level for declaring top
level classes to be visible only inside the namespace, but instead do it
"Java style" with namespace class X syntax just like this proposal.

In fact I think that is a more appropriate use of this syntax.

Ideally we would have a very readable syntax like this:

[template<...>] class A namespace {
};

This reads better I think: We're now entering the class A namespace, right?
While this opens up for the cumbersome "namespace class A namespace { ... }
to define the methods of a class A with namespace visibility it is at least
still logical, and the combination will be quite rare.

--------

I also want to comment on the idea of allowing additional methods inside
such an implementation clause. I think it is doable, and a good thing,
given the right rules: Only methods declared in the "real" class head have
access to private members, or maybe even better: Such extra methods must be
private so that they can be used only by the "real" methods of the class
(directly or indirectly). Their visibility would have to be limited to the
SAME implementation clause as we would otherwise run into trouble with what
happens with two such clauses in different TUs requiring magic (aka
modules) to transfer the information between the clauses.

This said, it would of course not be possible to add virtual methods or
non-static data members, i.e. anything that affects the memory layout of
the objects (by this rule local class declarations would be allowed).

I know there have been proposals in this direction before, and I think this
is the right time to cater for those needs without creating yet another
feature.

A possible killer drawback is however that we get into the "override"
problem: If we change the signature of a method in the class head the
implementation silently turns into a extra method. On the other hand this
is only silent until link time when it becomes painfully obvious that there
is a mismatch...

--

---
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_2867_1567957814.1448066993674
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I like this idea a lot, but I&#39;m sceptical to the reuse=
 of the word namespace. There is also another proposal that uses the same s=
yntax with a different meaning, which indicates that it may be non-intuitiv=
e. I like that proposal too, which is using namespace as another protection=
 level besides private, protected and public; with the obvious meaning. AFA=
IK the idea was not to require a namespace: on namespace level for declarin=
g top level classes to be visible only inside the namespace, but instead do=
 it &quot;Java style&quot; with namespace class X syntax just like this pro=
posal.<div><br></div><div>In fact I think that is a more appropriate use of=
 this syntax.</div><div><br></div><div>Ideally we would have a very readabl=
e syntax like this:</div><div><br></div><div>[template&lt;...&gt;] class A =
namespace {</div><div>};</div><div><br></div><div>This reads better I think=
: We&#39;re now entering the class A namespace, right? While this opens up =
for the cumbersome &quot;namespace class A namespace { ... } to define the =
methods of a class A with namespace visibility it is at least still logical=
, and the combination will be quite rare.</div><div><br></div><div>--------=
</div><div><br></div><div>I also want to comment on the idea of allowing ad=
ditional methods inside such an implementation clause. I think it is doable=
, and a good thing, given the right rules: Only methods declared in the &qu=
ot;real&quot; class head have access to private members, or maybe even bett=
er: Such extra methods must be private so that they can be used only by the=
 &quot;real&quot; methods of the class (directly or indirectly). Their visi=
bility would have to be limited to the SAME implementation clause as we wou=
ld otherwise run into trouble with what happens with two such clauses in di=
fferent TUs requiring magic (aka modules) to transfer the information betwe=
en the clauses.</div><div><br></div><div>This said, it would of course not =
be possible to add virtual methods or non-static data members, i.e. anythin=
g that affects the memory layout of the objects (by this rule local class d=
eclarations would be allowed).</div><div><br></div><div>I know there have b=
een proposals in this direction before, and I think this is the right time =
to cater for those needs without creating yet another feature.</div><div><b=
r></div><div>A possible killer drawback is however that we get into the &qu=
ot;override&quot; problem: If we change the signature of a method in the cl=
ass head the implementation silently turns into a extra method. On the othe=
r hand this is only silent until link time when it becomes painfully obviou=
s that there is a mismatch...</div><div><br></div></div>

<p></p>

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

------=_Part_2867_1567957814.1448066993674--
------=_Part_2866_1042302663.1448066993674--

.

------=_Part_2939_250910973.1448071289782
Content-Type: multipart/alternative;
 boundary="----=_Part_2940_1110913566.1448071289782"

------=_Part_2940_1110913566.1448071289782
Content-Type: text/plain; charset=UTF-8

On Friday, November 20, 2015 at 7:49:54 PM UTC-5, Bengt Gustafsson wrote:
>
> I like this idea a lot, but I'm sceptical to the reuse of the word
> namespace. There is also another proposal that uses the same syntax with a
> different meaning, which indicates that it may be non-intuitive. I like
> that proposal too, which is using namespace as another protection level
> besides private, protected and public; with the obvious meaning.
>

As far as I'm concerned, syntax should be apportioned on two bases: merit
and first-come-first-serve. The merits of this proposal may be syntactic
sugar, but basically nobody liked the "namespace protection level" idea
except the person who suggested it.

And for first-come-first-serve, this is actually a proposal. Not yet
submitted to the committee, but it's actually got paper behind it. Whereas
the "namespace protection level" was nothing more than an idea someone had.
And not a particularly well-considered idea either.

So this proposal is both more generally useful and more well-thought out
than that idea. It's got dibs on the syntax.


> I also want to comment on the idea of allowing additional methods inside
> such an implementation clause. I think it is doable, and a good thing,
> given the right rules: Only methods declared in the "real" class head have
> access to private members, or maybe even better: Such extra methods must be
> private so that they can be used only by the "real" methods of the class
> (directly or indirectly). Their visibility would have to be limited to the
> SAME implementation clause as we would otherwise run into trouble with what
> happens with two such clauses in different TUs requiring magic (aka
> modules) to transfer the information between the clauses.
>

Scope creep is bad. This feature is about making syntax better, not about
allowing people to inject methods into classes.

What's more, the committee has already
<https://isocpp.org/blog/2015/11/kona-standards-meeting-trip-report> made a
determination
<https://botondballo.wordpress.com/2015/11/09/trip-report-c-standards-meeting-in-kona-october-2015/>
<https://botondballo.wordpress.com/2015/11/09/trip-report-c-standards-meeting-in-kona-october-2015/>
on a similar proposal <http://wg21.link/P0079> called "extension methods".
And that determination was "no." Indeed, "extension methods" was apparently
unwanted even by those who wanted to see automatic deduction of `f(x)` from
`x.f()`.

Adding your idea to the proposal would lead either to its failure entirely
or to the committee requesting that the offending parts be removed. Either
way, it's a waste of time.


> This said, it would of course not be possible to add virtual methods or
> non-static data members, i.e. anything that affects the memory layout of
> the objects (by this rule local class declarations would be allowed).
>
> I know there have been proposals in this direction before, and I think
> this is the right time to cater for those needs without creating yet
> another feature.
>

Piggybacking your pet feature onto someone else's proposal is not a good
way to get either one adopted. Especially since the committee has already
said no.

--

---
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_2940_1110913566.1448071289782
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, November 20, 2015 at 7:49:54 PM UTC-5, Bengt Gu=
stafsson 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=
">I like this idea a lot, but I&#39;m sceptical to the reuse of the word na=
mespace. There is also another proposal that uses the same syntax with a di=
fferent meaning, which indicates that it may be non-intuitive. I like that =
proposal too, which is using namespace as another protection level besides =
private, protected and public; with the obvious meaning.</div></blockquote>=
<div><br>As far as I&#39;m concerned, syntax should be apportioned on two b=
ases: merit and first-come-first-serve. The merits of this proposal may be =
syntactic sugar, but basically nobody liked the &quot;namespace protection =
level&quot; idea except the person who suggested it.<br><br>And for first-c=
ome-first-serve, this is actually a proposal. Not yet submitted to the comm=
ittee, but it&#39;s actually got paper behind it. Whereas the &quot;namespa=
ce protection level&quot; was nothing more than an idea someone had. And no=
t a particularly well-considered idea either.<br><br>So this proposal is bo=
th more generally useful and more well-thought out than that idea. It&#39;s=
 got dibs on the syntax.<br>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div></div><div>I also want to comment on the id=
ea of allowing additional methods inside such an implementation clause. I t=
hink it is doable, and a good thing, given the right rules: Only methods de=
clared in the &quot;real&quot; class head have access to private members, o=
r maybe even better: Such extra methods must be private so that they can be=
 used only by the &quot;real&quot; methods of the class (directly or indire=
ctly). Their visibility would have to be limited to the SAME implementation=
 clause as we would otherwise run into trouble with what happens with two s=
uch clauses in different TUs requiring magic (aka modules) to transfer the =
information between the clauses.</div></div></blockquote><div><br>Scope cre=
ep is bad. This feature is about making syntax better, not about allowing p=
eople to inject methods into classes.<br><br>What&#39;s more, the committee=
 has <a href=3D"https://isocpp.org/blog/2015/11/kona-standards-meeting-trip=
-report">already</a> made=C2=A0<a href=3D"https://botondballo.wordpress.com=
/2015/11/09/trip-report-c-standards-meeting-in-kona-october-2015/">a determ=
ination</a><a href=3D"https://botondballo.wordpress.com/2015/11/09/trip-rep=
ort-c-standards-meeting-in-kona-october-2015/"></a> on <a href=3D"http://wg=
21.link/P0079">a similar proposal</a> called &quot;extension methods&quot;.=
 And that determination was &quot;no.&quot; Indeed, &quot;extension methods=
&quot; was apparently unwanted even by those who wanted to see automatic de=
duction of `f(x)` from `x.f()`.<br><br>Adding your idea to the proposal wou=
ld lead either to its failure entirely or to the committee requesting that =
the offending parts be removed. Either way, it&#39;s a waste of time.<br>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div></div><div>This said, it would of course not be possible to add virtual=
 methods or non-static data members, i.e. anything that affects the memory =
layout of the objects (by this rule local class declarations would be allow=
ed).</div><div><br></div><div>I know there have been proposals in this dire=
ction before, and I think this is the right time to cater for those needs w=
ithout creating yet another feature.</div></div></blockquote><div><br>Piggy=
backing your pet feature onto someone else&#39;s proposal is not a good way=
 to get either one adopted. Especially since the committee has already said=
 no.</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_2940_1110913566.1448071289782--
------=_Part_2939_250910973.1448071289782--

.

On 2015-11-20 21:01, Nicol Bolas wrote:
> And for first-come-first-serve, this is actually a proposal. Not yet
> submitted to the committee, but it's actually got paper behind it.

It's also (I literally just discovered) apparently an exact duplicate of
N1420. Which appears to have fizzled (i.e. wasn't actually rejected, but
just fell off the radar for whatever reasons).

That being the case, this will need some revision/updates before I want
to submit it to take that into account. Maybe we can have better luck
this time around. (Or should I just pick up N1420 instead?)

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

.

On 2015-11-20 19:49, Bengt Gustafsson wrote:
> I like this idea a lot, but I'm sceptical to the reuse of the word=20
> namespace. There is also another proposal that uses the same syntax with =
a=20
> different meaning, which indicates that it may be non-intuitive.

You are talking about the namespace access protection proposal? Leaving
aside that that got very little support, how did that reuse the syntax?
My understanding was that that added:

  class Foo
  {
  public:
    ...
  private:
    ...
  namespace: // new
    ...
  }

I don't see how that overlaps.

> Ideally we would have a very readable syntax like this:
>=20
> [template<...>] class A namespace {
> };

That, to me, is backwards. When opening a regular namespace, the syntax
order is <verb=C2=B9 (keyword)> <noun (identifier)>. Why would we want to u=
se
the completely different order <adjective> <noun> <verb>?

(=C2=B9 I'm calling "namespace" a verb, here, because its the token that
indicates what action is occurring.)

> This reads better I think: We're now entering the class A namespace, righ=
t?=20

I'd buy that argument if we also wrote "std namespace { ... }". But we
don't.

> I also want to comment on the idea of allowing additional methods inside=
=20
> such an implementation clause. I think it is doable, and a good thing,=20
> given the right rules [...]

I am not going to add this to the proposal. My understanding is that
this sort of thing is highly controversial and tanked a previous
proposal. I see no reason why the proposal as is should be risked just
to try to rush a feature that could=C2=B2 as easily be added later.

(=C2=B2 In the technical sense. In the practical sense it seems already tha=
t
actually doing so has the proverbial snowball's chance.)

See also Nicol's comments.

> A possible killer drawback is however that we get into the "override"=20
> problem: If we change the signature of a method in the class head the=20
> implementation silently turns into a extra method.

Pedantic: that's an over*load*, not an over*ride*.

--=20
Matthew

--=20

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

.

------=_Part_346_547288047.1448296072263
Content-Type: multipart/alternative;
 boundary="----=_Part_347_1598963451.1448296072263"

------=_Part_347_1598963451.1448296072263
Content-Type: text/plain; charset=UTF-8



On Monday, November 23, 2015 at 10:29:44 AM UTC-5, Matthew Woehlke wrote:
>
> On 2015-11-20 21:01, Nicol Bolas wrote:
> > And for first-come-first-serve, this is actually a proposal. Not yet
> > submitted to the committee, but it's actually got paper behind it.
>
> It's also (I literally just discovered) apparently an exact duplicate of
> N1420. Which appears to have fizzled (i.e. wasn't actually rejected, but
> just fell off the radar for whatever reasons).
>
> That being the case, this will need some revision/updates before I want
> to submit it to take that into account. Maybe we can have better luck
> this time around. (Or should I just pick up N1420 instead?)
>

You could probably consider yours a revision of N1420. Either way, you
should probably give acknowledgements and also try to hunt down what people
thought of the proposal, so that you can be ready to answer any questions
that might have been raised.

--

---
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_347_1598963451.1448296072263
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, November 23, 2015 at 10:29:44 AM UTC-5,=
 Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015=
-11-20 21:01, Nicol Bolas wrote:
<br>&gt; And for first-come-first-serve, this is actually a proposal. Not y=
et=20
<br>&gt; submitted to the committee, but it&#39;s actually got paper behind=
 it.
<br>
<br>It&#39;s also (I literally just discovered) apparently an exact duplica=
te of
<br>N1420. Which appears to have fizzled (i.e. wasn&#39;t actually rejected=
, but
<br>just fell off the radar for whatever reasons).
<br>
<br>That being the case, this will need some revision/updates before I want
<br>to submit it to take that into account. Maybe we can have better luck
<br>this time around. (Or should I just pick up N1420 instead?)<br></blockq=
uote><div><br>You could probably consider yours a revision of N1420. Either=
 way, you should probably give acknowledgements and also try to hunt down w=
hat people thought of the proposal, so that you can be ready to answer any =
questions that might have been raised. <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_347_1598963451.1448296072263--
------=_Part_346_547288047.1448296072263--

.

------=_Part_1320_1280193044.1448404794080
Content-Type: multipart/alternative;
 boundary="----=_Part_1321_591936878.1448404794080"

------=_Part_1321_591936878.1448404794080
Content-Type: text/plain; charset=UTF-8

Maybe I was over-reading the suggestion about a namespace protection level.
To me it was obvious that the most common use case would be to protect some
of the classes from outside access, as is today commonly done using the
detail sub-namespace. So I assumed that this would be possible:

namespace my_namespace {
  namespace class Foo {  // A namespace local helper class.
  public:
    ...
  private:
    ...
  namespace: // new
    ...
  };
}

Anyhow, maybe this purpose would be better served by allowing private: and
public: on the namespace level. This of course offers more protection than
the current detail:: system but I will not say more about it as it is off
topic here.

When it comes to the order of the keywords I would be hard pressed to view
namespace as a verb anytime. With class A namespace { you get the important
information first, it is a class we're talking about, and then later that
we are reopening it. That said, of course I'd rather have it the other way
around than not at all.

--

---
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_1321_591936878.1448404794080
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Maybe I was over-reading the suggestion about a namespace =
protection level. To me it was obvious that the most common use case would =
be to protect some of the classes from outside access, as is today commonly=
 done using the detail sub-namespace. So I assumed that this would be possi=
ble:<div><br></div><div>namespace my_namespace {<br>=C2=A0 namespace class =
Foo=C2=A0{=C2=A0 // A namespace local helper class.<br>=C2=A0 public:=C2=A0=
<br>=C2=A0 =C2=A0 ...=C2=A0<br>=C2=A0 private:=C2=A0<br>=C2=A0 =C2=A0 ...=
=C2=A0<br>=C2=A0 namespace: // new=C2=A0<br>=C2=A0 =C2=A0 ...=C2=A0<br>=C2=
=A0 };</div><div>}</div><div><br></div><div>Anyhow, maybe this purpose woul=
d be better served by allowing private: and public: on the namespace level.=
 This of course offers more protection than the current detail:: system but=
 I will not say more about it as it is off topic here.</div><div><br></div>=
<div>When it comes to the order of the keywords I would be hard pressed to =
view namespace as a verb anytime. With class A namespace { you get the impo=
rtant information first, it is a class we&#39;re talking about, and then la=
ter that we are reopening it. That said, of course I&#39;d rather have it t=
he other way around than not at all.</div><div><br></div></div>

<p></p>

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

------=_Part_1321_591936878.1448404794080--
------=_Part_1320_1280193044.1448404794080--

.

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

On Sat, Nov 21, 2015 at 3:01 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> As far as I'm concerned, syntax should be apportioned on two bases: merit
> and first-come-first-serve.
>

Ummm.  Yes, proposals are evaluated based on their merits.  The merits in
the opinion of people who show up to meetings and vote, after a
presentation and discussion (and some of those present will have actually
read the paper carefully from the mailing).

I have no idea what the "first-come-first-serve" part is you are talking
about.  If there are competing/conflicting proposals, which one came first
has no bearing on how people vote as far as I can tell.  It's not even
clear why it would or should.

The merits of this proposal may be syntactic sugar, but basically nobody
> liked the "namespace protection level" idea except the person who suggested
> it.
>

You can't tell that from a std-proposals thread.  The general sentiment on
std-proposals doesn't really correlate well with how proposals go at
meetings.  This list is useful for finding out some specific points of
interest about initial proposal ideas through to preliminary drafts - but
you certainly shouldn't try to extrapolate how the meeting votes will go
based on totaling positive-tone vs negative-tone responses on this list.  I
won't speculate why it doesn't work, except to say that it just doesn't.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Nov 21, 2015 at 3:01 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>As far as I&#39;m con=
cerned, syntax should be apportioned on two bases: merit and first-come-fir=
st-serve.</div></div></blockquote><div><br></div><div>Ummm.=C2=A0 Yes, prop=
osals are evaluated based on their merits.=C2=A0 The merits in the opinion =
of people who show up to meetings and vote, after a presentation and discus=
sion (and some of those present will have actually read the paper carefully=
 from the mailing).</div><div><br></div><div>I have no idea what the &quot;=
first-come-first-serve&quot; part is you are talking about.=C2=A0 If there =
are competing/conflicting proposals, which one came first has no bearing on=
 how people vote as far as I can tell.=C2=A0 It&#39;s not even clear why it=
 would or should.</div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(=
204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><di=
v>The merits of this proposal may be syntactic sugar, but basically nobody =
liked the &quot;namespace protection level&quot; idea except the person who=
 suggested it.<br></div></div></blockquote><div>=C2=A0</div><div>You can&#3=
9;t tell that from a std-proposals thread.=C2=A0 The general sentiment on s=
td-proposals doesn&#39;t really correlate well with how proposals go at mee=
tings.=C2=A0 This list is useful for finding out some specific points of in=
terest about initial proposal ideas through to preliminary drafts - but you=
 certainly shouldn&#39;t try to extrapolate how the meeting votes will go b=
ased on totaling positive-tone vs negative-tone responses on this list.=C2=
=A0 I won&#39;t speculate why it doesn&#39;t work, except to say that it ju=
st doesn&#39;t.</div><div><br></div><div><br></div></div></div></div>

<p></p>

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

--001a1148e62a9fedc305255888a0--

.

On 2015-11-24 17:39, Bengt Gustafsson wrote:
> Maybe I was over-reading the suggestion about a namespace protection level.
> To me it was obvious that the most common use case would be to protect some
> of the classes from outside access, as is today commonly done using the
> detail sub-namespace. So I assumed that this would be possible:
>
> namespace my_namespace {
>   namespace class Foo {  // A namespace local helper class.

What do you think the use of "namespace" here means? (It's not currently
allowed; why would namespace access protection allow it, and what would
it mean?)

>   public:
>     ...
>   private:
>     ...
>   namespace: // new
>     ...
>   };
> }
>
> Anyhow, maybe this purpose would be better served by allowing private: and
> public: on the namespace level. This of course offers more protection than
> the current detail:: system but I will not say more about it as it is off
> topic here.

I'm not aware of any proposal like this, even for namespace as the
access level. (What, for example, would private mean, anyway? Private to
what?)

I'm also not convinced it's necessary; if no class members have access
beyond namespace, you get pretty much the same effect.

> When it comes to the order of the keywords I would be hard pressed to view
> namespace as a verb anytime.

What do you consider it in the case e.g. "namespace std"? I read that as
"namespace" -> verb, I am opening a namespace, "std" -> noun, the
namespace I am opening. Just like "class" in a class definition is a
verb ("I am defining a class").

> With class A namespace { you get the important
> information first, it is a class we're talking about, and then later that
> we are reopening it. That said, of course I'd rather have it the other way
> around than not at all.

Again, why then do we write "namespace std" instead of "std namespace"?

I too would rather have "class <name> namespace" than nothing :-), but
that order feels unnatural to me.

--
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_3704_1519187193.1448463946472
Content-Type: multipart/alternative;
 boundary="----=_Part_3705_674750460.1448463946472"

------=_Part_3705_674750460.1448463946472
Content-Type: text/plain; charset=UTF-8

On Wednesday, November 25, 2015 at 9:59:18 AM UTC-5, Matthew Woehlke wrote:
>
> On 2015-11-24 17:39, Bengt Gustafsson wrote:
> > Maybe I was over-reading the suggestion about a namespace protection
> level.
> > To me it was obvious that the most common use case would be to protect
> some
> > of the classes from outside access, as is today commonly done using the
> > detail sub-namespace. So I assumed that this would be possible:
> >
> > namespace my_namespace {
> >   namespace class Foo {  // A namespace local helper class.
>
> What do you think the use of "namespace" here means? (It's not currently
> allowed; why would namespace access protection allow it, and what would
> it mean?)
>
> >   public:
> >     ...
> >   private:
> >     ...
> >   namespace: // new
> >     ...
> >   };
> > }
> >
> > Anyhow, maybe this purpose would be better served by allowing private:
> and
> > public: on the namespace level. This of course offers more protection
> than
> > the current detail:: system but I will not say more about it as it is
> off
> > topic here.
>
> I'm not aware of any proposal like this, even for namespace as the
> access level. (What, for example, would private mean, anyway? Private to
> what?)
>

Just FYI: what he's referring to is an idea that was batted around here a
few weeks ago
<https://groups.google.com/a/isocpp.org/d/msg/std-proposals/-1WXq57b-Sg/SZCFOsfTFAAJ>
..

>

--

---
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_3705_674750460.1448463946472
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, November 25, 2015 at 9:59:18 AM UTC-5, Matthew Woehlke wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">On 2015-11-24 17:39, Bengt Gus=
tafsson wrote:
<br>&gt; Maybe I was over-reading the suggestion about a namespace protecti=
on level.=20
<br>&gt; To me it was obvious that the most common use case would be to pro=
tect some=20
<br>&gt; of the classes from outside access, as is today commonly done usin=
g the=20
<br>&gt; detail sub-namespace. So I assumed that this would be possible:
<br>&gt;=20
<br>&gt; namespace my_namespace {
<br>&gt; =C2=A0 namespace class Foo { =C2=A0// A namespace local helper cla=
ss.
<br>
<br>What do you think the use of &quot;namespace&quot; here means? (It&#39;=
s not currently
<br>allowed; why would namespace access protection allow it, and what would
<br>it mean?)
<br>
<br>&gt; =C2=A0 public:=20
<br>&gt; =C2=A0 =C2=A0 ...=20
<br>&gt; =C2=A0 private:=20
<br>&gt; =C2=A0 =C2=A0 ...=20
<br>&gt; =C2=A0 namespace: // new=20
<br>&gt; =C2=A0 =C2=A0 ...=20
<br>&gt; =C2=A0 };
<br>&gt; }
<br>&gt;=20
<br>&gt; Anyhow, maybe this purpose would be better served by allowing priv=
ate: and=20
<br>&gt; public: on the namespace level. This of course offers more protect=
ion than=20
<br>&gt; the current detail:: system but I will not say more about it as it=
 is off=20
<br>&gt; topic here.
<br>
<br>I&#39;m not aware of any proposal like this, even for namespace as the
<br>access level. (What, for example, would private mean, anyway? Private t=
o
<br>what?)
<br></blockquote><div><br>Just FYI: what he&#39;s referring to is an <a hre=
f=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/-1WXq57b-Sg=
/SZCFOsfTFAAJ">idea that was batted around here a few weeks ago</a>.<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">
</blockquote>

<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_3705_674750460.1448463946472--
------=_Part_3704_1519187193.1448463946472--

.

------=_Part_637_1820321914.1448464240190
Content-Type: multipart/alternative;
 boundary="----=_Part_638_939141424.1448464240191"

------=_Part_638_939141424.1448464240191
Content-Type: text/plain; charset=UTF-8

On Wednesday, November 25, 2015 at 2:37:45 AM UTC-5, Andrew Tomazos wrote:
>
> On Sat, Nov 21, 2015 at 3:01 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> As far as I'm concerned, syntax should be apportioned on two bases: merit
>> and first-come-first-serve.
>>
>
> Ummm.  Yes, proposals are evaluated based on their merits.  The merits in
> the opinion of people who show up to meetings and vote, after a
> presentation and discussion (and some of those present will have actually
> read the paper carefully from the mailing).
>
> I have no idea what the "first-come-first-serve" part is you are talking
> about.  If there are competing/conflicting proposals, which one came first
> has no bearing on how people vote as far as I can tell.  It's not even
> clear why it would or should.
>

But that's usually because people avoid conflicting syntax in the first
place. If there's a proposal that uses some syntax that has general
committee approval and standard wording, and you're starting a proposal
that would rather use that syntax for something else, odds are really good
that among the suggestions for improving it will be "Proposal X has dibs on
that syntax; find something else."

For example, right now I would not suggest making a proposal that uses
`auto {...}` syntax in a way that conflicts with P0144.


> The merits of this proposal may be syntactic sugar, but basically nobody
>> liked the "namespace protection level" idea except the person who suggested
>> it.
>>
>
> You can't tell that from a std-proposals thread.  The general sentiment on
> std-proposals doesn't really correlate well with how proposals go at
> meetings.
>

In some ways, this is true. The committee has shot down plenty of proposals
that had broad approval on this forum. And the committee has accepted many
proposals that haven't exactly achieved consensus here. However, I don't
recall a time when a proposal suggested here gained basically universal
*disapproval*, yet fared well in the committee.

So I'd say that, while approval here doesn't mean that it will pass muster,
widespread dislike here probably is a bad sign. *Especially* when that
widespread dislike includes the *EWG chair*
<https://isocpp.org/wiki/faq/wg21#ville-voutilainen> saying this:

A new access mode needs very strong motivation; it's not sufficient that it
> doesn't cause damage, or that it would be nice for a few selected examples.
> It must be of fundamental importance. Is it?
>

This is hardly a guarantee of failure, but I wouldn't be too hopeful just
the same. Not until you can find a *really* good answer to that question.

--

---
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_638_939141424.1448464240191
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, November 25, 2015 at 2:37:45 AM UTC-5, Andrew Tomazos wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div clas=
s=3D"gmail_quote">On Sat, Nov 21, 2015 at 3:01 AM, Nicol Bolas <span dir=3D=
"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"2hWcXt2zBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return =
true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr"><div>As far as I&#39;m concerned, syntax should be apportioned on =
two bases: merit and first-come-first-serve.</div></div></blockquote><div><=
br></div><div>Ummm.=C2=A0 Yes, proposals are evaluated based on their merit=
s.=C2=A0 The merits in the opinion of people who show up to meetings and vo=
te, after a presentation and discussion (and some of those present will hav=
e actually read the paper carefully from the mailing).</div><div><br></div>=
<div>I have no idea what the &quot;first-come-first-serve&quot; part is you=
 are talking about.=C2=A0 If there are competing/conflicting proposals, whi=
ch one came first has no bearing on how people vote as far as I can tell.=
=C2=A0 It&#39;s not even clear why it would or should.</div></div></div></d=
iv></blockquote><div><br>But that&#39;s usually because people avoid confli=
cting syntax in the first place. If there&#39;s a proposal that uses some s=
yntax that has general committee approval and standard wording, and you&#39=
;re starting a proposal that would rather use that syntax for something els=
e, odds are really good that among the suggestions for improving it will be=
 &quot;Proposal X has dibs on that syntax; find something else.&quot;<br><b=
r>For example, right now I would not suggest making a proposal that uses `a=
uto {...}` syntax in a way that conflicts with P0144.<br>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex"><div dir=3D"ltr"><div>The merits of this prop=
osal may be syntactic sugar, but basically nobody liked the &quot;namespace=
 protection level&quot; idea except the person who suggested it.<br></div><=
/div></blockquote><div>=C2=A0</div><div>You can&#39;t tell that from a std-=
proposals thread.=C2=A0 The general sentiment on std-proposals doesn&#39;t =
really correlate well with how proposals go at meetings.</div></div></div><=
/div></blockquote><div><br>In some ways, this is true. The committee has sh=
ot down plenty of proposals that had broad approval on this forum. And the =
committee has accepted many proposals that haven&#39;t exactly achieved con=
sensus here. However, I don&#39;t recall a time when a proposal suggested h=
ere gained basically universal <i>disapproval</i>, yet fared well in the co=
mmittee.<br><br>So I&#39;d say that, while approval here doesn&#39;t mean t=
hat it will pass muster, widespread dislike here probably is a bad sign. <i=
>Especially</i> when that widespread dislike includes the <a href=3D"https:=
//isocpp.org/wiki/faq/wg21#ville-voutilainen"><i>EWG chair</i></a> saying t=
his:<br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1p=
x solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">A new=
 access mode needs very strong motivation; it&#39;s not sufficient that it =
doesn&#39;t cause damage, or that it would be nice for a few selected examp=
les. It must be of fundamental importance. Is it?<br></blockquote><br>This =
is hardly a guarantee of failure, but I wouldn&#39;t be too hopeful just th=
e same. Not until you can find a <i>really</i> good answer to that question=
..</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_638_939141424.1448464240191--
------=_Part_637_1820321914.1448464240190--

.

On 2015-11-25 09:58, Matthew Woehlke wrote:
> On 2015-11-24 17:39, Bengt Gustafsson wrote:
>> Anyhow, maybe this purpose would be better served by allowing private: and
>> public: on the namespace level. This of course offers more protection than
>> the current detail:: system but I will not say more about it as it is off
>> topic here.
>
> I'm not aware of any proposal like this, even for namespace as the
> access level. (What, for example, would private mean, anyway? Private to
> what?)

Oh, sorry, I misread what you wrote. Now I understand what you are
saying. Off topic, but potentially interesting.

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

.

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

On Wed, Nov 25, 2015 at 4:10 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Wednesday, November 25, 2015 at 2:37:45 AM UTC-5, Andrew Tomazos wrote:
>>
>> On Sat, Nov 21, 2015 at 3:01 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> As far as I'm concerned, syntax should be apportioned on two bases:
>>> merit and first-come-first-serve.
>>>
>>
>> Ummm.  Yes, proposals are evaluated based on their merits.  The merits in
>> the opinion of people who show up to meetings and vote, after a
>> presentation and discussion (and some of those present will have actually
>> read the paper carefully from the mailing).
>>
>> I have no idea what the "first-come-first-serve" part is you are talking
>> about.  If there are competing/conflicting proposals, which one came first
>> has no bearing on how people vote as far as I can tell.  It's not even
>> clear why it would or should.
>>
>
> But that's usually because people avoid conflicting syntax in the first
> place. If there's a proposal that uses some syntax that has general
> committee approval and standard wording, and you're starting a proposal
> that would rather use that syntax for something else, odds are really good
> that among the suggestions for improving it will be "Proposal X has dibs on
> that syntax; find something else."
>
> For example, right now I would not suggest making a proposal that uses
> `auto {...}` syntax in a way that conflicts with P0144.
>

If you have a better idea for something that auto {...} should mean, by all
means propose it.

As it happens there are other ideas floating around for what auto { ... }
could mean.  It could mean a temporary of deduced type from a
braced-init-list, for example maybe a std::initializer_list.  This
possibility (at least syntactically) is one of the problems with the
proposal as I point out in P0151.

Don't be intimidated because Herb/Bjarne/Gaby's names are on the paper.
Papers are not evaluated based on who wrote them.  Author reputation has
only a very weak influence.  We hope proposals are objectively evaluated
based on their content (time permitting).


> So I'd say that, while approval here doesn't mean that it will pass
> muster, widespread dislike here probably is a bad sign. *Especially* when
> that widespread dislike includes the *EWG chair*
> <https://isocpp.org/wiki/faq/wg21#ville-voutilainen> saying this:
>

> A new access mode needs very strong motivation; it's not sufficient that
>> it doesn't cause damage, or that it would be nice for a few selected
>> examples. It must be of fundamental importance. Is it?
>>
>
> This is hardly a guarantee of failure, but I wouldn't be too hopeful just
> the same. Not until you can find a *really* good answer to that question.
>
> Ville is just pointing out that a new access mode needs very strong
motivation (that's exactly what he said in fact).  He made that comment in
response to someone else that was defending the idea w.r.t the "openness"
issue.  The "openness" issue was getting far too much air-time.

The two points I take away from the responses are:

- A namespace access level would need to be contrasted with the proposed
"internal" access level of modules.  We would need to show such an access
level will still be relevant in a modules-world.  As it looks like modules
and namespaces are going to be distinct and orthogonal, I think this can be
done.

- We would need to explore the "openness" of namespaces and how it relates
to the access level.  Although I think modules are open too, so this is the
same issue for internal module access.  I think the importance of the issue
was exadurated on std-proposals.

Beyond those two points there was very little else said.  Predicting how
EWG will react to a proposal is extremely difficult - and while I
appreciate your attempt to do so for mine - I think it may be beyond your
abilities. :)

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Nov 25, 2015 at 4:10 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex">On Wednesday, November 25, 2015 at 2:37:45 =
AM UTC-5, Andrew Tomazos wrote:<span class=3D""><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote">On Sat, Nov 21, 2015 at 3:01 AM, N=
icol Bolas <span dir=3D"ltr">&lt;<a rel=3D"nofollow">jmck...@gmail.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>As far as I&#39=
;m concerned, syntax should be apportioned on two bases: merit and first-co=
me-first-serve.</div></div></blockquote><div><br></div><div>Ummm.=C2=A0 Yes=
, proposals are evaluated based on their merits.=C2=A0 The merits in the op=
inion of people who show up to meetings and vote, after a presentation and =
discussion (and some of those present will have actually read the paper car=
efully from the mailing).</div><div><br></div><div>I have no idea what the =
&quot;first-come-first-serve&quot; part is you are talking about.=C2=A0 If =
there are competing/conflicting proposals, which one came first has no bear=
ing on how people vote as far as I can tell.=C2=A0 It&#39;s not even clear =
why it would or should.</div></div></div></div></blockquote></span><div><br=
>But that&#39;s usually because people avoid conflicting syntax in the firs=
t place. If there&#39;s a proposal that uses some syntax that has general c=
ommittee approval and standard wording, and you&#39;re starting a proposal =
that would rather use that syntax for something else, odds are really good =
that among the suggestions for improving it will be &quot;Proposal X has di=
bs on that syntax; find something else.&quot;<br><br>For example, right now=
 I would not suggest making a proposal that uses `auto {...}` syntax in a w=
ay that conflicts with P0144.</div></blockquote><div><br></div><div>If you =
have a better idea for something that auto {...} should mean, by all means =
propose it.</div><div><br></div><div>As it happens there are other ideas fl=
oating around for what auto { ... } could mean.=C2=A0 It could mean a tempo=
rary of deduced type from a braced-init-list, for example maybe a std::init=
ializer_list.=C2=A0 This possibility (at least syntactically) is one of the=
 problems with the proposal as I point out in=C2=A0P0151.</div><div><br></d=
iv><div>Don&#39;t be intimidated because Herb/Bjarne/Gaby&#39;s names are o=
n the paper.=C2=A0 Papers are not evaluated based on who wrote them.=C2=A0 =
Author reputation has only a very weak influence.=C2=A0 We hope proposals a=
re objectively evaluated based on their content (time permitting).</div><di=
v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div>So I&#39;d say that, while approval her=
e doesn&#39;t mean that it will pass muster, widespread dislike here probab=
ly is a bad sign. <i>Especially</i> when that widespread dislike includes t=
he <a href=3D"https://isocpp.org/wiki/faq/wg21#ville-voutilainen" target=3D=
"_blank"><i>EWG chair</i></a> saying this:<br></div></blockquote><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width=
:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-lef=
t:1ex"><div><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding=
-left:1ex" class=3D"gmail_quote">A new access mode needs very strong motiva=
tion; it&#39;s not sufficient that it doesn&#39;t cause damage, or that it =
would be nice for a few selected examples. It must be of fundamental import=
ance. Is it?<br></blockquote><br>This is hardly a guarantee of failure, but=
 I wouldn&#39;t be too hopeful just the same. Not until you can find a <i>r=
eally</i> good answer to that question.</div><div class=3D""><div class=3D"=
h5">

<p></p></div></div></blockquote></div>Ville is just pointing out that a new=
 access mode needs very strong motivation (that&#39;s exactly what he said =
in fact).=C2=A0 He made that comment in response to someone else that was d=
efending the idea w.r.t the &quot;openness&quot; issue.=C2=A0 The &quot;ope=
nness&quot; issue was getting far too much air-time.</div><div class=3D"gma=
il_extra"><br></div><div class=3D"gmail_extra">The two points I take away f=
rom the responses are:</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">- A namespace access level would need to be contrasted wit=
h the proposed &quot;internal&quot; access level of modules.=C2=A0 We would=
 need to show such an access level will still be relevant in a modules-worl=
d.=C2=A0 As it looks like modules and namespaces are going to be distinct a=
nd orthogonal, I think this can be done.</div><div class=3D"gmail_extra"><b=
r></div><div class=3D"gmail_extra">- We would need to explore the &quot;ope=
nness&quot; of namespaces and how it relates to the access level.=C2=A0 Alt=
hough I think modules are open too, so this is the same issue for internal =
module access.=C2=A0 I think the importance of the issue was exadurated on =
std-proposals.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmai=
l_extra">Beyond those two points there was very little else said.=C2=A0 Pre=
dicting how EWG will react to a proposal is extremely difficult - and while=
 I appreciate your attempt to do so for mine - I think it may be beyond you=
r abilities. :)</div><div class=3D"gmail_extra"><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 />

--001a1148e62a66218b0525618a22--

.

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

On 2015-11-19 14:42, Matthew Woehlke wrote:
> I've written up a draft proposal for a "class namespace" feature based
> on the recent thread. In short, it introduces the new syntax:
>
>   template <...> // optional
>   namespace class Foo
>   {
>     Foo(...) { ... }
>     void foo(...) { ... }
>   }
>
> ...which is equivalent to:
>
>   template <...> Foo<...>::Foo(...) { ... }
>   template <...> void Foo<...>::foo(...) { ... }
>
> Basically, it allows one to "hoist" the class name (along with template
> specifications) out of a collection of out-of-line class member
> definitions and into a block scope. The class name (and template bits)
> are then implicitly applied to all definitions within said scope.
>
> I'm attaching the current version for you lazy people that like to see
> it in-line :-). You can also find the up to date version (with pretty
> HTML formatting) at
> https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-class-namespace/PXXXX%20Class%20Namespace.rst.

Updated version, for lazy folks, attached. I've added reference to N1420
and made "natural consequences" more explicit.

Still TO-DO: try to get in touch with Carl Daniel (N1420) and Vincent
Ordy (who apparently was implementing this in some fashion).

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

--------------010605040207000302070408
Content-Type: text/prs.fallenstein.rst;
 name="PXXXX Class Namespace.rst"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="PXXXX Class Namespace.rst"

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
  Class Namespace
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
~~~~~~~~~~~~~~~~~~~
 November 23, 2015
~~~~~~~~~~~~~~~~~~~

=2E. raw:: html

  <style>
    html { color: black; background: white; }
  </style>

=2E. role:: cpp(code)
   :language: c++

Abstract
=3D=3D=3D=3D=3D=3D=3D=3D

This proposal provides a new language feature, "class namespace", as a sh=
ortcut for providing a series of definitions belonging to a class scope, =
similar to the manner in which a traditional namespace can provide a seri=
es of definitions belonging to a namespace scope.

This proposal is effectively a continuation / resurrection of N1420_ whic=
h was tagged for further consideration without being either accepted or r=
ejected. However, much of the text of this proposal was written prior to =
the author's discovery of the same.

In contrast to N1420, we avoid use of the term "reopen", which implies th=
e ability to add to a class. Class definitions are currently closed; memb=
ers may only be added to a class during the initial definition thereof (t=
emplate specialization notwithstanding). Although many have asked for the=
 ability to add members to classes after the definition, such proposals a=
re generally not well received. Although it is not the intent of this pro=
posal to categorically forbid any such future direction, we also recogniz=
e these concerns and specifically do not wish to suggest any movement in =
that direction.

=2E. contents::


Rationale
=3D=3D=3D=3D=3D=3D=3D=3D=3D

`Don't Repeat Yourself <https://en.wikipedia.org/wiki/Don't_repeat_yourse=
lf>`_ (DRY) is a well known principle of software design. However, there =
are certain instances when providing definitions of class members that ca=
n fall prey to repetition, to the detriment of readability and maintainab=
ility.

We will present, as a particularly egregious example, a complicated templ=
ate class:

=2E. code:: c++

  template <typename CharType, typename Traits, typename Allocator>
  class MyString { ... };

There are strong reasons why method definitions should not be inline. For=
 starters, they inhibit readability; it is difficult to quickly parse the=
 interface |--| especially the public interface |--| as declarations and =
definitions are necessarily interleaved. Additionally, they are *inline*,=
 which results in all manner of compile time and cross-version compatibil=
ity issues. Even for template classes, it is sometimes preferred to keep =
definitions in a separate TU (e.g. extern templates with only specific, e=
xported explicit instantiations).

The problem that arises is the necessity to repeat a long prefix for all =
definitions provided outside of the class definition. For example:

=2E. code:: c++

  template <typename CharType, typename Traits, typename Allocator>
  MyString<CharType, Traits, Allocator>::MyString
  { ... }

This repetition increases the space over which accidental errors may be i=
ntroduced, and increases the work required for refactoring. The problem i=
s compounded for templates within templates.

This is a real, extant problem. Presumably as a result of this overhead, =
some authors will use only inline definitions of methods, which can make =
it difficult to separate implementation details |--| which are often unne=
cessary noise for a user trying to understand a class |--| from a class's=
 interface. Other authors may resort to separating return types, template=
 parameters, class names, and method names, placing each on separate line=
s, resulting in method headers that are four lines long even before the a=
rgument list is considered. In the latter case, the need to repeat the cl=
ass prefix is frustrating and, in the author's opinion, unnecessary.

(See https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/e=
0_ceXFQX-A for additional discussion.)

It is also worth noting that this situation is inconsistent with namespac=
es. Given a function declared in a namespace:

=2E. code:: c++

  namespace Foo
  {
    void foo();
  }

=2E..there are currently two ways to provide the definition:

=2E. code:: c++

  // Method 1: fully qualified
  void Foo::foo() { ... }

  // Method 2: namespace scope
  namespace Foo
  {
    void foo() { ... }
  }

There is currently no equivalent to the second form for class members. Th=
is proposal would remove this inconsistency.


Proposal
=3D=3D=3D=3D=3D=3D=3D=3D

This proposal is to eliminate the redundancy by introducing a new "class =
scope" syntax, as follows:

=2E. code:: c++

  template <...> // optional; only used for template classes
  namespace class Name
  {
    // definitions of class members
  }

The effect of this scope is to treat each member definition (variable or =
method) as if it were prefixed by the class template specification and na=
me. Specifically, these two codes would be exactly equivalent:

=2E. code:: c++

  // Declarations
  class A { ... };

  template <typename T> class B { ... };

  // Existing syntax
  A::A(...) { ... }
  A::Enum A::foo(...) { ... }
  int A::value =3D ...;

  template <typename T> B<T>::B(...) { ... }
  template <typename T> B<T>& B<T>::operator=3D(B<T> const& other) { ... =
}
  template <typename T> void B<T>::bar(...) { ... }

  // Proposed syntax
  namespace class A {
    A(...) { ... }
    Enum foo() { ... }
    int value =3D ...;
  }

  template <typename T>
  namespace class B {
    B(...) { ... }
    B& operator=3D(B const& other) { ... }
    void bar(...) { ... }
  }

Following the introduction of the scope (i.e. the keywords :cpp:`namespac=
e class`), the template parameters shall be implicitly applied to the cla=
ss name and any subsequent mention of the class name that does not have a=
n explicit argument list. It shall be an error to provide an argument lis=
t for the introducing class name except in the case of specialization. Ty=
pe name look-up within the scope shall additionally consider the class sc=
ope first (note in the above example the use of :cpp:`Enum` without the :=
cpp:`B::` qualifier). (These rules should be applied in the same manner a=
s for a class definition. Note that this only affects non-trailing return=
 types, as other types already use the class scope for type resolution.)

Some consequences of the scope acting simply as a name transformation sho=
uld be noted. First, such a scope can be "opened" on the same class name =
any number of times. Second, definitions in a class name scope may be mix=
ed with traditional, fully qualified definitions (provided that no defini=
tions are duplicated, as always). Third, an empty scope is permissible as=
 long as the named class is recognized. Last, but perhaps most important,=
 the scope does not permit the addition of members not present in the cla=
ss definition, nor in general does it allow the user to accomplish anythi=
ng that could not be accomplished otherwise.

Additionally:

- :cpp:`namespace struct` and :cpp:`namespace class` shall be equivalent =
and interchangeable. (In general, the use of "class" throughout should be=
 understood to mean either a :cpp:`class` or :cpp:`struct`.)
- Use of a class name scope requires that the named class has been define=
d. Forward declaration is not sufficient.
- Nested class name scopes are permitted.
- Any members that may legally be defined using their qualified name may =
be defined within a class name scope. This includes member types, member =
functions, and static member variables.
- As with traditional namespaces, a :cpp:`;` is not required following th=
e closing :cpp:`}`.
- Access modifiers are not allowed in a class name scope. The :cpp:`virtu=
al` and :cpp:`static` modifiers are not allowed in a class name scope. (N=
one of these are allowed outside of a class definition, and the class nam=
e scope is not a class definition.)
- A class name scope may not add class members to a class definition.
- This proposal does not affect :cpp:`using` directives. (A :cpp:`using` =
directive on a class name scope remains illegal.)


Specification
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The most straight forward way in which to describe this feature is with a=
 syntax transformation. Specifically, the syntax:

=2E. parsed-literal::

  *[<template_specification>]* **namespace class** *<name>* **{**
    *[<type>]* *<member_name><...>*
  **}**

=2E..shall be equivalent to:

=2E. parsed-literal::

  *[<template_specification>]* *[<type>]* *<name>*\ **::**\ *<member_name=
><...>*

=2E..for each *<member_name>* in the scope. Rules for interpretation of m=
embers within a class name scope, and for what sorts of code is permitted=
 or ill-formed, may all be derived directly from this transformation.


Additional Examples
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This feature is particularly useful for template members of template clas=
ses, including nested template types:

=2E. code:: c++

  template <typename T> class Foo
  {
    template <typename U> void foo(U);
    template <typename U> class Bar { Bar() };
  };

  template <typename T> namespace class Foo
  {
    template <typename U> void foo(U) { ... }

    template <typename U> class Bar
    {
      Bar() { ... }
    }
  }

  // Compare to the old syntax:
  template <typename T>
  template <typename U>
  void Foo<T>::foo<U>(U) { ... }

  template <typename T>
  template <typename U>
  void Foo<T>::Bar<U>::Bar() { ... }

Per the transformation rule, it works with specializations, as one would =
expect:

=2E. code:: c++

  template <> namespace class Foo<int>
  {
    ...
  }

(Note that this is allowed with or without a specialization of :cpp:`Foo<=
int>`, just as it is currently permitted to specialize class members with=
out specializing the entire class definition. Naturally, if the class def=
inition *is* specialized, then definitions in the corresponding class nam=
e scope must match members declared in said specialization.)


Discussion
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Syntax
------

The proposed syntax for introducing the scope is open for debate. Alterna=
tive suggestions include:

#. :cpp:`class namespace <name>`
#. :cpp:`namespace <classname>`
#. Introduction of a new contextual keyword, e.g. :cpp:`class <name> impl=
ementation`.
#. Introduction of a new (global) keyword, e.g. :cpp:`implement class <na=
me>`.

The author considers #1 to be very nearly as good as the suggested syntax=
=2E #2 is okay, but risks confusion, as the reader must know a priori if =
the named scope is a class (the #2 syntax would only introduce a class na=
me scope if the identifier following the :cpp:`namespace` keyword is an a=
lready declared class-type). #3 is of similar quality to #2; it lacks the=
 ambiguity problem, but the indication that "something is different" occu=
rs later, and it does require a new (albeit contextual) keyword. #4 has t=
he advantage of maximum possible clarity, but introducing new keywords wi=
thout breaking existing code is always tricky.

We additionally feel that the proposed syntax is the most consistent with=
 the current state of the language. It maintains the traditional order of=
 tokens, e.g. compared to use of traditional namespaces. It uses tokens i=
n an order than makes sense according to English grammar rules, i.e. *<ve=
rb> <adjective> <noun>* (with :cpp:`namespace` here acting as a verb, ind=
icating that a scope block is starting) with :cpp:`namespace class Foo` c=
omparable to e.g. "open blue ball".

Inline
------

Should :cpp:`inline namespace class <name>` be permitted? The "inline nam=
espace" concept does not make sense in this context. If it is permitted, =
it should be equivalent to including :cpp:`inline` as part of every conta=
ined definition. The author's inclination is to forbid use of :cpp:`inlin=
e` with :cpp:`namespace class`.


Acknowledgments
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This proposal is a continuation of N1420_ by Carl Daniel. It was original=
ly written prior to the author's discovery of N1420. The original feature=
 request that spawned this new proposal comes from John Yates. Miro Knejp=
 and P=C3=A9ter Radics contributed valuable suggestions. Other contempora=
ry participants include Larry Evans, Russell Greene, Bjorn Reese, Evan Te=
ran and Andrew Tomazos. (The author also acknowledges prior discussion of=
 a very similar feature: see https://groups.google.com/a/isocpp.org/d/msg=
/std-proposals/xukd1mgd21I/uHjx6YR_EnQJ and https://groups.google.com/a/i=
socpp.org/d/msg/std-proposals/xukd1mgd21I/gh5W0KS856oJ.)

=2E. _N1420: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n142=
0.pdf

=2E. |--| unicode:: U+02014 .. em dash

--------------010605040207000302070408--

.

------=_Part_8858_2041452796.1448492576327
Content-Type: multipart/alternative;
 boundary="----=_Part_8859_1853982524.1448492576327"

------=_Part_8859_1853982524.1448492576327
Content-Type: text/plain; charset=UTF-8

Reading through today's posts I think that the confusion has been reduced.
There are three suggestions around:

1) The topic of this thread: Reopening a class for implementation purposes.
Using namespace at either end of the introducer is fine with me. I think
the quite dramatic clutter reduction in the later half of include files
makes it worth the while.

2) The previous suggestion regarding a namespace: possibility inside
classes to restrict use of specific members to the surrounding namespace.
This is what didn't get very much traction, but if anyone wants to
formalize it that's fine with me.

3) My suggestion of allowing private: (and hence public:) on namespace
level to serve the purpose of the current rather clumsy "detail" namespace.
This has two benefits: a) it makes it harder to break in to private parts
of the namespace, b) it makes namespaces and classes more similar, one less
difference to teach. I see some merit to this, but I don't think it is
worth focussing standardization work on. If someone wants to do it, fine,
ubt I'm not going to push it further.

Den onsdag 25 november 2015 kl. 20:30:31 UTC+1 skrev Matthew Woehlke:
>
> On 2015-11-19 14:42, Matthew Woehlke wrote:
> > I've written up a draft proposal for a "class namespace" feature based
> > on the recent thread. In short, it introduces the new syntax:
> >
> >   template <...> // optional
> >   namespace class Foo
> >   {
> >     Foo(...) { ... }
> >     void foo(...) { ... }
> >   }
> >
> > ...which is equivalent to:
> >
> >   template <...> Foo<...>::Foo(...) { ... }
> >   template <...> void Foo<...>::foo(...) { ... }
> >
> > Basically, it allows one to "hoist" the class name (along with template
> > specifications) out of a collection of out-of-line class member
> > definitions and into a block scope. The class name (and template bits)
> > are then implicitly applied to all definitions within said scope.
> >
> > I'm attaching the current version for you lazy people that like to see
> > it in-line :-). You can also find the up to date version (with pretty
> > HTML formatting) at
> >
> https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-class-namespace/PXXXX%20Class%20Namespace.rst.
>
>
> Updated version, for lazy folks, attached. I've added reference to N1420
> and made "natural consequences" more explicit.
>
> Still TO-DO: try to get in touch with Carl Daniel (N1420) and Vincent
> Ordy (who apparently was implementing this in some fashion).
>
> --
> 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_8859_1853982524.1448492576327
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Reading through today&#39;s posts I think that the confusi=
on has been reduced. There are three suggestions around:<div><br></div><div=
>1) The topic of this thread: Reopening a class for implementation purposes=
.. Using namespace at either end of the introducer is fine with me. I think =
the quite dramatic clutter reduction in the later half of include files mak=
es it worth the while.</div><div><br></div><div>2) The previous suggestion =
regarding a namespace: possibility inside classes to restrict use of specif=
ic members to the surrounding namespace. This is what didn&#39;t get very m=
uch traction, but if anyone wants to formalize it that&#39;s fine with me.<=
/div><div><br></div><div>3) My suggestion of allowing private: (and hence p=
ublic:) on namespace level to serve the purpose of the current rather clums=
y &quot;detail&quot; namespace. This has two benefits: a) it makes it harde=
r to break in to private parts of the namespace, b) it makes namespaces and=
 classes more similar, one less difference to teach. I see some merit to th=
is, but I don&#39;t think it is worth focussing standardization work on. If=
 someone wants to do it, fine, ubt I&#39;m not going to push it further.<br=
><br>Den onsdag 25 november 2015 kl. 20:30:31 UTC+1 skrev Matthew Woehlke:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">On 2015-11-19 14:42, Matthew Wo=
ehlke wrote:
<br>&gt; I&#39;ve written up a draft proposal for a &quot;class namespace&q=
uot; feature based
<br>&gt; on the recent thread. In short, it introduces the new syntax:
<br>&gt;=20
<br>&gt; =C2=A0 template &lt;...&gt; // optional
<br>&gt; =C2=A0 namespace class Foo
<br>&gt; =C2=A0 {
<br>&gt; =C2=A0 =C2=A0 Foo(...) { ... }
<br>&gt; =C2=A0 =C2=A0 void foo(...) { ... }
<br>&gt; =C2=A0 }
<br>&gt;=20
<br>&gt; ...which is equivalent to:
<br>&gt;=20
<br>&gt; =C2=A0 template &lt;...&gt; Foo&lt;...&gt;::Foo(...) { ... }
<br>&gt; =C2=A0 template &lt;...&gt; void Foo&lt;...&gt;::foo(...) { ... }
<br>&gt;=20
<br>&gt; Basically, it allows one to &quot;hoist&quot; the class name (alon=
g with template
<br>&gt; specifications) out of a collection of out-of-line class member
<br>&gt; definitions and into a block scope. The class name (and template b=
its)
<br>&gt; are then implicitly applied to all definitions within said scope.
<br>&gt;=20
<br>&gt; I&#39;m attaching the current version for you lazy people that lik=
e to see
<br>&gt; it in-line :-). You can also find the up to date version (with pre=
tty
<br>&gt; HTML formatting) at
<br>&gt; <a href=3D"https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-cla=
ss-namespace/PXXXX%20Class%20Namespace.rst" target=3D"_blank" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\75https%3A=
%2F%2Fgithub.com%2Fmwoehlke%2Fcpp-proposals%2Fblob%2FPxxx-class-namespace%2=
FPXXXX%2520Class%2520Namespace.rst\46sa\75D\46sntz\0751\46usg\75AFQjCNHzOoB=
JLGk6b57aGwxkyagkmkDjEg&#39;;return true;" onclick=3D"this.href=3D&#39;http=
s://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fmwoehlke%2Fcpp-propos=
als%2Fblob%2FPxxx-class-namespace%2FPXXXX%2520Class%2520Namespace.rst\46sa\=
75D\46sntz\0751\46usg\75AFQjCNHzOoBJLGk6b57aGwxkyagkmkDjEg&#39;;return true=
;">https://github.com/mwoehlke/<wbr>cpp-proposals/blob/Pxxx-class-<wbr>name=
space/PXXXX%20Class%<wbr>20Namespace.rst</a>.
<br>
<br>Updated version, for lazy folks, attached. I&#39;ve added reference to =
N1420
<br>and made &quot;natural consequences&quot; more explicit.
<br>
<br>Still TO-DO: try to get in touch with Carl Daniel (N1420) and Vincent
<br>Ordy (who apparently was implementing this in some fashion).
<br>
<br>--=20
<br>Matthew
<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_8859_1853982524.1448492576327--
------=_Part_8858_2041452796.1448492576327--

.

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

On Wed, Nov 25, 2015 at 8:30 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2015-11-19 14:42, Matthew Woehlke wrote:
> > I've written up a draft proposal for a "class namespace" feature based
> > on the recent thread. In short, it introduces the new syntax:
> >
> >   template <...> // optional
> >   namespace class Foo
> >   {
> >     Foo(...) { ... }
> >     void foo(...) { ... }
> >   }
> >
> > ...which is equivalent to:
> >
> >   template <...> Foo<...>::Foo(...) { ... }
> >   template <...> void Foo<...>::foo(...) { ... }
> >
> > Basically, it allows one to "hoist" the class name (along with template
> > specifications) out of a collection of out-of-line class member
> > definitions and into a block scope. The class name (and template bits)
> > are then implicitly applied to all definitions within said scope.
> >
> > I'm attaching the current version for you lazy people that like to see
> > it in-line :-). You can also find the up to date version (with pretty
> > HTML formatting) at
> >
> https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-class-namespace/PXXXX%20Class%20Namespace.rst
> .
>
> Updated version, for lazy folks, attached. I've added reference to N1420
> and made "natural consequences" more explicit.
>
> Still TO-DO: try to get in touch with Carl Daniel (N1420) and Vincent
> Ordy (who apparently was implementing this in some fashion).
>
>
I found this paper describing the implementation.  Apparently it's done via
some code transformation tool:
https://www.lrde.epita.fr/dload/20080709-Seminar/ordy-classnamespaces.pdf

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Nov 25, 2015 at 8:30 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex"><span class=3D"">On 2015-11-=
19 14:42, Matthew Woehlke wrote:<br>
&gt; I&#39;ve written up a draft proposal for a &quot;class namespace&quot;=
 feature based<br>
</span>&gt; on the recent thread. In short, it introduces the new syntax:<b=
r>
<span class=3D"">&gt;<br>
&gt;=C2=A0 =C2=A0template &lt;...&gt; // optional<br>
&gt;=C2=A0 =C2=A0namespace class Foo<br>
&gt;=C2=A0 =C2=A0{<br>
&gt;=C2=A0 =C2=A0 =C2=A0Foo(...) { ... }<br>
&gt;=C2=A0 =C2=A0 =C2=A0void foo(...) { ... }<br>
&gt;=C2=A0 =C2=A0}<br>
&gt;<br>
&gt; ...which is equivalent to:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0template &lt;...&gt; Foo&lt;...&gt;::Foo(...) { ... }<br>
&gt;=C2=A0 =C2=A0template &lt;...&gt; void Foo&lt;...&gt;::foo(...) { ... }=
<br>
&gt;<br>
&gt; Basically, it allows one to &quot;hoist&quot; the class name (along wi=
th template<br>
&gt; specifications) out of a collection of out-of-line class member<br>
&gt; definitions and into a block scope. The class name (and template bits)=
<br>
&gt; are then implicitly applied to all definitions within said scope.<br>
&gt;<br>
&gt; I&#39;m attaching the current version for you lazy people that like to=
 see<br>
&gt; it in-line :-). You can also find the up to date version (with pretty<=
br>
&gt; HTML formatting) at<br>
&gt; <a href=3D"https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-class-n=
amespace/PXXXX%20Class%20Namespace.rst" rel=3D"noreferrer" target=3D"_blank=
">https://github.com/mwoehlke/cpp-proposals/blob/Pxxx-class-namespace/PXXXX=
%20Class%20Namespace.rst</a>.<br>
<br>
</span>Updated version, for lazy folks, attached. I&#39;ve added reference =
to N1420<br>
and made &quot;natural consequences&quot; more explicit.<br>
<br>
Still TO-DO: try to get in touch with Carl Daniel (N1420) and Vincent<br>
Ordy (who apparently was implementing this in some fashion).<br><span class=
=3D""><font color=3D"#888888"><br></font></span></blockquote><div><br></div=
><div>I found this paper describing the implementation.=C2=A0 Apparently it=
&#39;s done via some code transformation tool: <a href=3D"https://www.lrde.=
epita.fr/dload/20080709-Seminar/ordy-classnamespaces.pdf">https://www.lrde.=
epita.fr/dload/20080709-Seminar/ordy-classnamespaces.pdf</a></div><div><br>=
</div><div><br></div></div></div></div>

<p></p>

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

--089e013c66b415562805256e17cb--

.

------=_Part_36_155498776.1448977139261
Content-Type: multipart/alternative;
 boundary="----=_Part_37_855352912.1448977139265"

------=_Part_37_855352912.1448977139265
Content-Type: text/plain; charset=UTF-8

Since unions can have member functions too, wouldn't it be better to extend
this facility to unions as well?  Of course union should not be
interchangeable with struct/class: "namespace union Foo" must refer to a
previously declared "union Foo", not a class or struct Foo.

--

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

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

<div dir=3D"ltr">Since unions can have member functions too, wouldn&#39;t i=
t be better to extend this facility to unions as well? =C2=A0Of course unio=
n should not be interchangeable with struct/class: &quot;namespace union Fo=
o&quot; must refer to a previously declared &quot;union Foo&quot;, not a cl=
ass or struct Foo.</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_37_855352912.1448977139265--
------=_Part_36_155498776.1448977139261--

.

------=_Part_882_1657043003.1458676068470
Content-Type: multipart/alternative;
 boundary="----=_Part_883_974596373.1458676068470"

------=_Part_883_974596373.1458676068470
Content-Type: text/plain; charset=UTF-8

Has there been any updates on this proposal (Maybe in Jacksonville?) ?.

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

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

<div dir=3D"ltr">Has there been any updates on this proposal (Maybe in Jack=
sonville?) ?.</div>

<p></p>

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

------=_Part_883_974596373.1458676068470--
------=_Part_882_1657043003.1458676068470--

.

On 2016-03-22 15:47, Paul wrote:
> Has there been any updates on this proposal (Maybe in Jacksonville?) ?.

It wasn't presented. A few individuals expressed that they thought it
doesn't go far enough, i.e. that 'using <classname>' should also be
supported. Others waved their arms making noises of doom and gloom
regarding name lookup.

The general impression I got was that it needs an implementation to be
seriously considered. (At any rate, it won't be in C++17.)

--
Matthew

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

.

------=_Part_1245_164197903.1458679581838
Content-Type: multipart/alternative;
 boundary="----=_Part_1246_1507052385.1458679581838"

------=_Part_1246_1507052385.1458679581838
Content-Type: text/plain; charset=UTF-8

That's really disappointing.
I have just started again using C++ and of course there were tons of class
templates everywhere with these awful long instantiation names.

On Tuesday, March 22, 2016 at 9:08:00 PM UTC+1, Matthew Woehlke wrote:
>
> On 2016-03-22 15:47, Paul wrote:
> > Has there been any updates on this proposal (Maybe in Jacksonville?) ?.
>
> It wasn't presented. A few individuals expressed that they thought it
> doesn't go far enough, i.e. that 'using <classname>' should also be
> supported. Others waved their arms making noises of doom and gloom
> regarding name lookup.
>

Could you explain more about these "issues" in name lookup?.


>
> The general impression I got was that it needs an implementation to be
> seriously considered. (At any rate, it won't be in C++17.)
>
> --
> Matthew
>
>

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

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

<div dir=3D"ltr">That&#39;s really disappointing.<div>I have just started a=
gain using C++ and of course there were tons of class templates everywhere =
with these awful long instantiation names.<br><br>On Tuesday, March 22, 201=
6 at 9:08:00 PM UTC+1, Matthew Woehlke wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">On 2016-03-22 15:47, Paul wrote:
<br>&gt; Has there been any updates on this proposal (Maybe in Jacksonville=
?) ?.
<br>
<br>It wasn&#39;t presented. A few individuals expressed that they thought =
it
<br>doesn&#39;t go far enough, i.e. that &#39;using &lt;classname&gt;&#39; =
should also be
<br>supported. Others waved their arms making noises of doom and gloom
<br>regarding name lookup.
<br></blockquote><div><br></div><div>Could you explain more about these &qu=
ot;issues&quot; in name lookup?.</div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;">
<br>The general impression I got was that it needs an implementation to be
<br>seriously considered. (At any rate, it won&#39;t be in C++17.)
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></div></div>

<p></p>

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

------=_Part_1246_1507052385.1458679581838--
------=_Part_1245_164197903.1458679581838--

.

On 2016-03-22 16:46, Paul wrote:
> On Tuesday, March 22, 2016 at 9:08:00 PM UTC+1, Matthew Woehlke wrote:
>> On 2016-03-22 15:47, Paul wrote:
>>> Has there been any updates on this proposal (Maybe in Jacksonville?) ?.
>>
>> It wasn't presented.
>
> That's really disappointing. I have just started again using C++ and
> of course there were tons of class templates everywhere with these
> awful long instantiation names.

Do you have examples you can share? Anything that can add to the
motivation would help...

>> A few individuals expressed that they thought it doesn't go far
>> enough, i.e. that 'using <classname>' should also be supported.
>> Others waved their arms making noises of doom and gloom regarding
>> name lookup.
>
> Could you explain more about these "issues" in name lookup?.

No. At least one of the compiler devs had strong words about how 'lookup
is the scariest part of the compiler and I'm opposed in principle to
anything going in there and mucking about'. No details were given, just
general statements made. (Personally, I think concerns here are not
rational - compilers already know how to do name lookup in the context
that P0223 would create - but as mentioned, the impression I was given
was that there would be a lot of opposition without an implementation to
prove that such concerns are unfounded.)

--
Matthew

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

.

------=_Part_24_1683744784.1458682569343
Content-Type: multipart/alternative;
 boundary="----=_Part_25_530726033.1458682569343"

------=_Part_25_530726033.1458682569343
Content-Type: text/plain; charset=UTF-8

On Tuesday, March 22, 2016 at 10:10:18 PM UTC+1, Matthew Woehlke wrote:
>
> On 2016-03-22 16:46, Paul wrote:
> > On Tuesday, March 22, 2016 at 9:08:00 PM UTC+1, Matthew Woehlke wrote:
> >> On 2016-03-22 15:47, Paul wrote:
> >>> Has there been any updates on this proposal (Maybe in Jacksonville?)
> ?.
> >>
> >> It wasn't presented.
> >
> > That's really disappointing. I have just started again using C++ and
> > of course there were tons of class templates everywhere with these
> > awful long instantiation names.
>
> Do you have examples you can share? Anything that can add to the
> motivation would help...
>
>
I think your proposal already contains such examples. My code looks like
this:

  template <typename Wrapper, typename SBType, typename... DefaultTypes>
  class SBWrapper : public Nan::ObjectWrap {
  private:
    using ThisTy = SBWrapper<Wrapper, SBType, DefaultTypes...>;

  public:
   ...
  }

  template <typename Wrapper, typename SBType, typename... DefaultTypes>
  Nan::Persistent<v8::FunctionTemplate>
      SBWrapper<Wrapper, SBType, DefaultTypes...>::s_ConstTemplate;

  template <typename Wrapper, typename SBType, typename... DefaultTypes>
  Nan::Persistent<v8::Function>
      SBWrapper<Wrapper, SBType, DefaultTypes...>::s_Constructor;

  template <typename Wrapper, typename SBType, typename... DefaultTypes>
  SBWrapper<Wrapper, SBType, DefaultTypes...>::SBWrapper(
      const SBType& SbObject) : m_SBObject{SbObject} {
  }

  template <typename Wrapper, typename SBType, typename... DefaultTypes>
  void SBWrapper<Wrapper, SBType, DefaultTypes...>::Initialize(
      const v8::Local<v8::Object>& exports) {
  }

And I think I am going to add even more template parameters and as you can
clearly see, lots of redundant typing (C&P), unclear/confusing code, ...
One could argue that I should simply move all the code into the class scope
but I prefer keeping "interface and implementation" separate just for the
sake of more code clarity :).

With you proposal my code could look like this:

template <typename Wrapper, typename SBType, typename... DefaultTypes>
namespace class SBWrapper {
  Nan::Persistent<v8::FunctionTemplate> s_ConstTemplate;
  Nan::Persistent<v8::Function> s_Constructor;

  SBWrapper(const SBType& SbObject) : m_SBObject{SbObject} {
  }

  void Initialize(const v8::Local<v8::Object>& exports) {
  }
}

:)


> >> A few individuals expressed that they thought it doesn't go far
> >> enough, i.e. that 'using <classname>' should also be supported.
> >> Others waved their arms making noises of doom and gloom regarding
> >> name lookup.
> >
> > Could you explain more about these "issues" in name lookup?.
>
> No. At least one of the compiler devs had strong words about how 'lookup
> is the scariest part of the compiler and I'm opposed in principle to
> anything going in there and mucking about'. No details were given, just
> general statements made. (Personally, I think concerns here are not
> rational - compilers already know how to do name lookup in the context
> that P0223 would create - but as mentioned, the impression I was given
> was that there would be a lot of opposition without an implementation to
> prove that such concerns are unfounded.)
>
> --
> Matthew
>
>

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

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

<div dir=3D"ltr">On Tuesday, March 22, 2016 at 10:10:18 PM UTC+1, Matthew W=
oehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-03-22 16:=
46, Paul wrote:
<br>&gt; On Tuesday, March 22, 2016 at 9:08:00 PM UTC+1, Matthew Woehlke wr=
ote:
<br>&gt;&gt; On 2016-03-22 15:47, Paul wrote:=20
<br>&gt;&gt;&gt; Has there been any updates on this proposal (Maybe in Jack=
sonville?) ?.=20
<br>&gt;&gt;
<br>&gt;&gt; It wasn&#39;t presented.
<br>&gt;=20
<br>&gt; That&#39;s really disappointing. I have just started again using C=
++ and=20
<br>&gt; of course there were tons of class templates everywhere with these
<br>&gt; awful long instantiation names.
<br>
<br>Do you have examples you can share? Anything that can add to the
<br>motivation would help...
<br>
<br></blockquote><div><br></div><div>I think your proposal already contains=
 such examples. My code looks like this:</div><div><br></div><div><div>=C2=
=A0 template &lt;typename Wrapper, typename SBType, typename... DefaultType=
s&gt;</div><div>=C2=A0 class SBWrapper : public Nan::ObjectWrap {</div><div=
>=C2=A0 private:</div><div>=C2=A0 =C2=A0 using ThisTy =3D SBWrapper&lt;Wrap=
per, SBType, DefaultTypes...&gt;;</div><div><br></div><div>=C2=A0 public:</=
div><div>=C2=A0 =C2=A0...</div><div>=C2=A0 }</div><div>=C2=A0=C2=A0</div><d=
iv>=C2=A0 template &lt;typename Wrapper, typename SBType, typename... Defau=
ltTypes&gt;</div><div>=C2=A0 Nan::Persistent&lt;v8::FunctionTemplate&gt;</d=
iv><div>=C2=A0 =C2=A0 =C2=A0 SBWrapper&lt;Wrapper, SBType, DefaultTypes...&=
gt;::s_ConstTemplate;</div><div><br></div><div>=C2=A0 template &lt;typename=
 Wrapper, typename SBType, typename... DefaultTypes&gt;</div><div>=C2=A0 Na=
n::Persistent&lt;v8::Function&gt;</div><div>=C2=A0 =C2=A0 =C2=A0 SBWrapper&=
lt;Wrapper, SBType, DefaultTypes...&gt;::s_Constructor;</div><div><br></div=
><div>=C2=A0 template &lt;typename Wrapper, typename SBType, typename... De=
faultTypes&gt;</div><div>=C2=A0 SBWrapper&lt;Wrapper, SBType, DefaultTypes.=
...&gt;::SBWrapper(</div><div>=C2=A0 =C2=A0 =C2=A0 const SBType&amp; SbObjec=
t) : m_SBObject{SbObject} {</div><div>=C2=A0 }</div><div><br></div><div>=C2=
=A0 template &lt;typename Wrapper, typename SBType, typename... DefaultType=
s&gt;</div><div>=C2=A0 void SBWrapper&lt;Wrapper, SBType, DefaultTypes...&g=
t;::Initialize(</div><div>=C2=A0 =C2=A0 =C2=A0 const v8::Local&lt;v8::Objec=
t&gt;&amp; exports) {</div><div>=C2=A0 }</div></div><div><br></div><div>And=
 I think I am going to add even more template parameters and as you can cle=
arly see, lots of redundant typing (C&amp;P), unclear/confusing code, ...</=
div><div>One could argue that I should simply move all the code into the cl=
ass scope but I prefer keeping &quot;interface and implementation&quot; sep=
arate just for the sake of more code clarity :).</div><div>=C2=A0</div><div=
>With you proposal my code could look like this:</div><div><br></div><div><=
div>template &lt;typename Wrapper, typename SBType, typename... DefaultType=
s&gt;</div><div>namespace class SBWrapper {</div><div>=C2=A0 Nan::Persisten=
t&lt;v8::FunctionTemplate&gt; s_ConstTemplate;</div><div>=C2=A0 Nan::Persis=
tent&lt;v8::Function&gt; s_Constructor;</div><div><br></div><div>=C2=A0 SBW=
rapper(const SBType&amp; SbObject) : m_SBObject{SbObject} {</div><div>=C2=
=A0 }</div><div><br></div><div>=C2=A0 void Initialize(const v8::Local&lt;v8=
::Object&gt;&amp; exports) {</div><div>=C2=A0 }</div><div>}</div></div><div=
><br></div><div>:)</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;">&gt;&gt; A few individuals expressed that they thought it doesn&=
#39;t go far
<br>&gt;&gt; enough, i.e. that &#39;using &lt;classname&gt;&#39; should als=
o be supported.
<br>&gt;&gt; Others waved their arms making noises of doom and gloom regard=
ing
<br>&gt;&gt; name lookup.
<br>&gt;=20
<br>&gt; Could you explain more about these &quot;issues&quot; in name look=
up?.
<br>
<br>No. At least one of the compiler devs had strong words about how &#39;l=
ookup
<br>is the scariest part of the compiler and I&#39;m opposed in principle t=
o
<br>anything going in there and mucking about&#39;. No details were given, =
just
<br>general statements made. (Personally, I think concerns here are not
<br>rational - compilers already know how to do name lookup in the context
<br>that P0223 would create - but as mentioned, the impression I was given
<br>was that there would be a lot of opposition without an implementation t=
o
<br>prove that such concerns are unfounded.)
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></div>

<p></p>

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

------=_Part_25_530726033.1458682569343--
------=_Part_24_1683744784.1458682569343--

.

------=_Part_5693_426750860.1458704059834
Content-Type: multipart/alternative;
 boundary="----=_Part_5694_1971239098.1458704059834"

------=_Part_5694_1971239098.1458704059834
Content-Type: text/plain; charset=UTF-8

On Tuesday, March 22, 2016 at 5:10:18 PM UTC-4, Matthew Woehlke wrote:
>
> On 2016-03-22 16:46, Paul wrote:
> > On Tuesday, March 22, 2016 at 9:08:00 PM UTC+1, Matthew Woehlke wrote:
> >> On 2016-03-22 15:47, Paul wrote:
> >>> Has there been any updates on this proposal (Maybe in Jacksonville?)
> ?.
> >>
> >> It wasn't presented.
> >
> > That's really disappointing. I have just started again using C++ and
> > of course there were tons of class templates everywhere with these
> > awful long instantiation names.
>
> Do you have examples you can share? Anything that can add to the
> motivation would help...
>
> >> A few individuals expressed that they thought it doesn't go far
> >> enough, i.e. that 'using <classname>' should also be supported.
> >> Others waved their arms making noises of doom and gloom regarding
> >> name lookup.
> >
> > Could you explain more about these "issues" in name lookup?.
>
> No. At least one of the compiler devs had strong words about how 'lookup
> is the scariest part of the compiler and I'm opposed in principle to
> anything going in there and mucking about'. No details were given, just
> general statements made. (Personally, I think concerns here are not
> rational - compilers already know how to do name lookup in the context
> that P0223 would create - but as mentioned, the impression I was given
> was that there would be a lot of opposition without an implementation to
> prove that such concerns are unfounded.)
>

I'm curious. When Bjarne Stroustrup and Herb Sutter were playing around
with unified function call syntax, did anyone ever ask *them* if someone
had implemented their incredibly complicated name lookup rules?

It's not like your proposal was anywhere nearly as complex look-up wise.
Especially considering that yours doesn't actually affect name lookup...

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

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

<div dir=3D"ltr">On Tuesday, March 22, 2016 at 5:10:18 PM UTC-4, Matthew Wo=
ehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-03-22 16:4=
6, Paul wrote:
<br>&gt; On Tuesday, March 22, 2016 at 9:08:00 PM UTC+1, Matthew Woehlke wr=
ote:
<br>&gt;&gt; On 2016-03-22 15:47, Paul wrote:=20
<br>&gt;&gt;&gt; Has there been any updates on this proposal (Maybe in Jack=
sonville?) ?.=20
<br>&gt;&gt;
<br>&gt;&gt; It wasn&#39;t presented.
<br>&gt;=20
<br>&gt; That&#39;s really disappointing. I have just started again using C=
++ and=20
<br>&gt; of course there were tons of class templates everywhere with these
<br>&gt; awful long instantiation names.
<br>
<br>Do you have examples you can share? Anything that can add to the
<br>motivation would help...
<br>
<br>&gt;&gt; A few individuals expressed that they thought it doesn&#39;t g=
o far
<br>&gt;&gt; enough, i.e. that &#39;using &lt;classname&gt;&#39; should als=
o be supported.
<br>&gt;&gt; Others waved their arms making noises of doom and gloom regard=
ing
<br>&gt;&gt; name lookup.
<br>&gt;=20
<br>&gt; Could you explain more about these &quot;issues&quot; in name look=
up?.
<br>
<br>No. At least one of the compiler devs had strong words about how &#39;l=
ookup
<br>is the scariest part of the compiler and I&#39;m opposed in principle t=
o
<br>anything going in there and mucking about&#39;. No details were given, =
just
<br>general statements made. (Personally, I think concerns here are not
<br>rational - compilers already know how to do name lookup in the context
<br>that P0223 would create - but as mentioned, the impression I was given
<br>was that there would be a lot of opposition without an implementation t=
o
<br>prove that such concerns are unfounded.)
<br></blockquote><div><br>I&#39;m curious. When Bjarne Stroustrup and Herb =
Sutter were playing around with unified function call syntax, did anyone ev=
er ask <i>them</i> if someone had implemented their incredibly complicated =
name lookup rules?<br><br>It&#39;s not like your proposal was anywhere near=
ly as complex look-up wise. Especially considering that yours doesn&#39;t a=
ctually affect name lookup...<br></div></div>

<p></p>

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

------=_Part_5694_1971239098.1458704059834--
------=_Part_5693_426750860.1458704059834--

.

On 3/22/2016 4:36 PM, Paul wrote:
> One could argue that I should simply move all the code into the class
> scope but I prefer keeping "interface and implementation" separate just
> for the sake of more code clarity :).

Well, it's somewhat beside the point, but unless you have no private
members, you have to mix interface and implementation anyway. :)

- Jim


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

.

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

>
> I prefer keeping "interface and implementation" separate just for the sake
> of more code clarity


Me too. I always separate the implementations in a .inl or .icc header to
keep the interface clean. But the implementation header gets really ugly
and unreadable exactly because of the problem which this proposal is going
to solve. That's why I'm interested it this proposal too. It's really
disappointing to see it's not going anywhere soon.

On Wed, Mar 23, 2016 at 12:00 PM, Jim Porter <jvp4846@g.rit.edu> wrote:

> On 3/22/2016 4:36 PM, Paul wrote:
>
>> One could argue that I should simply move all the code into the class
>> scope but I prefer keeping "interface and implementation" separate just
>> for the sake of more code clarity :).
>>
>
> Well, it's somewhat beside the point, but unless you have no private
> members, you have to mix interface and implementation anyway. :)
>
> - Jim
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nct4ch%24emp%241%40ger.gmane.org
> .
>

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

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><span style=3D"font-size:12.8px">I prefer=
 keeping &quot;interface and implementation&quot; separate just for the sak=
e of more code clarity=C2=A0</span></blockquote><div>=C2=A0</div><div>Me to=
o. I always separate the implementations in a .inl or .icc header to keep t=
he interface clean. But the implementation header gets really ugly and unre=
adable exactly because of the problem which this proposal is going to solve=
.. That&#39;s why I&#39;m interested it this proposal too. It&#39;s really d=
isappointing to see it&#39;s not going anywhere soon.</div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Mar 23, 2016 at 12:=
00 PM, Jim Porter <span dir=3D"ltr">&lt;<a href=3D"mailto:jvp4846@g.rit.edu=
" target=3D"_blank">jvp4846@g.rit.edu</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><span class=3D"">On 3/22/2016 4:36 PM, Paul wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
One could argue that I should simply move all the code into the class<br>
scope but I prefer keeping &quot;interface and implementation&quot; separat=
e just<br>
for the sake of more code clarity :).<br>
</blockquote>
<br></span>
Well, it&#39;s somewhat beside the point, but unless you have no private me=
mbers, you have to mix interface and implementation anyway. :)<br>
<br>
- Jim<span class=3D""><br>
<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/nct4ch%24emp%241%40ger.gmane.org" rel=
=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/=
msgid/std-proposals/nct4ch%24emp%241%40ger.gmane.org</a>.<br>
</blockquote></div><br></div>

<p></p>

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

--001a11471c947b7c11052eaf726d--

.