------=_Part_440_551773755.1542271266331
Content-Type: multipart/alternative;
 boundary="----=_Part_441_221839169.1542271266331"

------=_Part_441_221839169.1542271266331
Content-Type: text/plain; charset="UTF-8"

Hi Everyone

Currently in C++ we defined code in namespaces like this

namespace my_name_space
{
class whatever
{
}
} // my_name_space


I find this syntax unsatisfying because:
1. The general advice in most code style guidelines I've seen is to not
intent code in a namespace. This means it puts two braces together at the
same indentation level which I find rather ugly.
2.  As namespaces tend to contain many lines of code the closing brace is a
long way away from where it is opened which means you are obligated to put
a comment in saying what the namespace closing namespace brace refers to.
If you don't, it's really hard to know what the brace refers to just by
looking at i.
3. If you do put a comment you the comment can get out of sync if you
change the namespace name.

I would much rather something like this:

namespace my_name_space:

class whatever
{
}

namespace my_name_space;


This new syntax:
* Seems visually much cleaner to me.
* Doesn't encourage nesting so much as braces so helps encourage the
typically desired thing of no nesting in a namespace.
* Enforces developers to write self documenting code by requiring a closing
namespace name that matches the opening one.
* The compiler can check closing names match opening names so the code
can't get out of sync like a comment can.

It's really is more along the lines of what we do anyway when we write a
namespace and close it and put a comment.

Thoughts?

--
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/e3afb61b-bdbf-45a8-b914-d555848baade%40isocpp.org.

------=_Part_441_221839169.1542271266331
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Everyone</div><div><br></div><div>Currently in C++=
 we defined code in namespaces like this</div><div><br></div><div>namespace=
=C2=A0my_name_space</div><div>{</div><div>class whatever</div><div>{<br>}</=
div><div>} // my_name_space</div><div><br></div><div><br></div><div>I find =
this syntax unsatisfying because:</div><div>1.=C2=A0The general advice in m=
ost code style guidelines I&#39;ve seen is to not intent code in a namespac=
e. This means it puts two braces together at the same indentation level whi=
ch I find rather ugly.</div><div>2.=C2=A0=C2=A0As namespaces tend to contai=
n many lines of code the closing brace is a long way away from where it is =
opened which means you are obligated to put a comment in saying what the na=
mespace closing namespace brace refers to. If you don&#39;t, it&#39;s reall=
y hard to know what the brace refers to=C2=A0just by looking at i.</div><di=
v>3. If you do put a comment you=C2=A0the comment can get out of sync if yo=
u change the namespace name.</div><div><br></div><div>I would much rather s=
omething like this:</div><div><br></div><div><div>namespace=C2=A0my_name_sp=
ace:</div><div><br></div><div>class whatever</div><div>{<br>}</div><div><br=
></div><div>namespace my_name_space;</div><div><br></div><div><br></div><di=
v>This new syntax:</div><div>* Seems visually much cleaner to me.</div><div=
>* Doesn&#39;t encourage nesting so much as braces so helps encourage the t=
ypically desired thing of no nesting in=C2=A0a namespace.</div><div>*=C2=A0=
Enforces developers=C2=A0to write self documenting code by requiring a clos=
ing namespace name that matches the opening one.</div><div>*=C2=A0The compi=
ler=C2=A0can check closing names=C2=A0match opening names so the code can&#=
39;t get out of sync like a comment can.</div><div><br></div><div>It&#39;s =
really is more along the lines of what we do anyway when we write a namespa=
ce and close it and put a comment.</div><div><br></div><div>Thoughts?</div>=
</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/e3afb61b-bdbf-45a8-b914-d555848baade%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e3afb61b-bdbf-45a8-b914-d555848baade=
%40isocpp.org</a>.<br />

------=_Part_441_221839169.1542271266331--

------=_Part_440_551773755.1542271266331--

.

Hi,

On Thu, Nov 15, 2018 at 12:41:06AM -0800, gmisocpp@gmail.com wrote:
> Currently in C++ we defined code in namespaces like this
>
> namespace my_name_space
> {
> class whatever
> {
> }
> } // my_name_space
>
>
> I find this syntax unsatisfying because:
> 1. The general advice in most code style guidelines I've seen is to not
> intent code in a namespace. This means it puts two braces together at the
> same indentation level which I find rather ugly.

Really, is that the advice? Don't think I have seen that advice.


> 2.  As namespaces tend to contain many lines of code the closing brace is a
> long way away from where it is opened which means you are obligated to put
> a comment in saying what the namespace closing namespace brace refers to.
> If you don't, it's really hard to know what the brace refers to just by
> looking at i.

Code editors know how to match braces.

BTW, another option would be:

namespace my_name_space
{
  class whatever;
}

class my_name_space::whatever
{
};


> 3. If you do put a comment you the comment can get out of sync if you
> change the namespace name.
>
> I would much rather something like this:
>
> namespace my_name_space:
>
> class whatever
> {
> }
>
> namespace my_name_space;

It seems way too easy to confuse ":" with ";" to make this a viable
option.


Christof

--

http://cmeerw.org                              sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org                   xmpp:cmeerw at cmeerw.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/20181115085939.GO2073%40edge.cmeerw.net.

.

On 11/15/18 11:41 AM, gmisocpp@gmail.com wrote:
> Hi Everyone
>=20
> Currently in C++ we defined code in namespaces like this
>=20
> namespace=C2=A0my_name_space
> {
> class whatever
> {
> }
> } // my_name_space
>=20
>=20
> I find this syntax unsatisfying because:
> 1.=C2=A0The general advice in most code style guidelines I've seen is to =
not=20
> intent code in a namespace.

That's some really wrong/misguided guidelines you've seen.

> This means it puts two braces together at=20
> the same indentation level which I find rather ugly.

So, instead of doing the indentation or code styling which you'd like,=20
you propose a new core language syntax?

> 2.=C2=A0=C2=A0As namespaces tend to contain many lines of code the closin=
g brace=20
> is a long way away from where it is opened which means you are obligated=
=20
> to put a comment in saying what the namespace closing namespace brace=20
> refers to. If you don't, it's really hard to know what the brace refers=
=20
> to=C2=A0just by looking at i.

There's not too many alternatives where a closing brace can appear=20
alone. Class and enum definitions end with "};" or "} variable;", so=20
you're not going to confuse those with a namespace brace. Function=20
bodies end with a single "}", but it's usually pretty obvious that there=20
is a function body above it.

The reason we add a comment is when we have multiple nested namespaces,=20
so that we can track which namespace we're closing and which are still=20
open. This has been a much lesser problem since the compact syntax for=20
multiple nested namespace declaration was introduced.

> 3. If you do put a comment you=C2=A0the comment can get out of sync if yo=
u=20
> change the namespace name.
>=20
> I would much rather something like this:
>=20
> namespace=C2=A0my_name_space:
>=20
> class whatever
> {
> }
>=20
> namespace my_name_space;

So, you'd rather type "namespace my_name_space;" instead of a single=20
closing brace, which will likely be typed by the editor anyway?

> This new syntax:
> * Seems visually much cleaner to me.

Not to me, sorry. Besides the ":" vs. ";" confusion that was pointed=20
out, the use of ";" looks misplaced in this instance. Semicolons are=20
used to terminate a declaration in C/C++, and in this case it is used=20
for something else entirely.

> * Doesn't encourage nesting so much as braces so helps encourage the=20
> typically desired thing of no nesting in=C2=A0a namespace.

I don't understand this argument. Are you suggesting that having a flat=20
namespace is good? If so, I disagree.

> *=C2=A0Enforces developers=C2=A0to write self documenting code by requiri=
ng a=20
> closing namespace name that matches the opening one.

This sounds like a constant nuiscance to me.

> Thoughts?

Sorry, but no, thanks.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/478c4327-5665-082a-9654-8cc3cecd46fb%40gmail.com=
..

.

------=_Part_496_2132190330.1542282574547
Content-Type: multipart/alternative;
 boundary="----=_Part_497_907031961.1542282574547"

------=_Part_497_907031961.1542282574547
Content-Type: text/plain; charset="UTF-8"


Even if some syntax change would be slightly more readable, it's not going
to make a big difference.
These sort of readability issues can only be solved by a good code editor
IDE. You need to read c++ in an editor that marks all braces and
parentheses clearly with lines, colors and/or tags.

On Thursday, 15 November 2018 10:41:06 UTC+2, gmis...@gmail.com wrote:
>
> Hi Everyone
>
> Currently in C++ we defined code in namespaces like this
>
> namespace my_name_space
> {
> class whatever
> {
> }
> } // my_name_space
>
>
> I find this syntax unsatisfying because:
> 1. The general advice in most code style guidelines I've seen is to not
> intent code in a namespace. This means it puts two braces together at the
> same indentation level which I find rather ugly.
> 2.  As namespaces tend to contain many lines of code the closing brace is
> a long way away from where it is opened which means you are obligated to
> put a comment in saying what the namespace closing namespace brace refers
> to. If you don't, it's really hard to know what the brace refers to just by
> looking at i.
> 3. If you do put a comment you the comment can get out of sync if you
> change the namespace name.
>
> I would much rather something like this:
>
> namespace my_name_space:
>
> class whatever
> {
> }
>
> namespace my_name_space;
>
>
> This new syntax:
> * Seems visually much cleaner to me.
> * Doesn't encourage nesting so much as braces so helps encourage the
> typically desired thing of no nesting in a namespace.
> * Enforces developers to write self documenting code by requiring a
> closing namespace name that matches the opening one.
> * The compiler can check closing names match opening names so the code
> can't get out of sync like a comment can.
>
> It's really is more along the lines of what we do anyway when we write a
> namespace and close it and put a comment.
>
> Thoughts?
>

--
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/f94bbd1a-c97a-4ac3-8387-11e092e7f8b4%40isocpp.org.

------=_Part_497_907031961.1542282574547
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>Even if some syntax change would be slightly more read=
able, it&#39;s not going to make a big difference.<br>These sort of readabi=
lity issues can only be solved by a good code editor IDE. You need to read =
c++ in an editor that marks all braces and parentheses clearly with lines, =
colors and/or tags.<br><br>On Thursday, 15 November 2018 10:41:06 UTC+2, gm=
is...@gmail.com  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div>Hi Everyone</div><div><br></div><div>Currently in C++ we def=
ined code in namespaces like this</div><div><br></div><div>namespace=C2=A0m=
y_name_space</div><div>{</div><div>class whatever</div><div>{<br>}</div><di=
v>} // my_name_space</div><div><br></div><div><br></div><div>I find this sy=
ntax unsatisfying because:</div><div>1.=C2=A0The general advice in most cod=
e style guidelines I&#39;ve seen is to not intent code in a namespace. This=
 means it puts two braces together at the same indentation level which I fi=
nd rather ugly.</div><div>2.=C2=A0=C2=A0As namespaces tend to contain many =
lines of code the closing brace is a long way away from where it is opened =
which means you are obligated to put a comment in saying what the namespace=
 closing namespace brace refers to. If you don&#39;t, it&#39;s really hard =
to know what the brace refers to=C2=A0just by looking at i.</div><div>3. If=
 you do put a comment you=C2=A0the comment can get out of sync if you chang=
e the namespace name.</div><div><br></div><div>I would much rather somethin=
g like this:</div><div><br></div><div><div>namespace=C2=A0my_name_space:</d=
iv><div><br></div><div>class whatever</div><div>{<br>}</div><div><br></div>=
<div>namespace my_name_space;</div><div><br></div><div><br></div><div>This =
new syntax:</div><div>* Seems visually much cleaner to me.</div><div>* Does=
n&#39;t encourage nesting so much as braces so helps encourage the typicall=
y desired thing of no nesting in=C2=A0a namespace.</div><div>*=C2=A0Enforce=
s developers=C2=A0to write self documenting code by requiring a closing nam=
espace name that matches the opening one.</div><div>*=C2=A0The compiler=C2=
=A0can check closing names=C2=A0match opening names so the code can&#39;t g=
et out of sync like a comment can.</div><div><br></div><div>It&#39;s really=
 is more along the lines of what we do anyway when we write a namespace and=
 close it and put a comment.</div><div><br></div><div>Thoughts?</div></div>=
</div></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/f94bbd1a-c97a-4ac3-8387-11e092e7f8b4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f94bbd1a-c97a-4ac3-8387-11e092e7f8b4=
%40isocpp.org</a>.<br />

------=_Part_497_907031961.1542282574547--

------=_Part_496_2132190330.1542282574547--

.

On 15/11/2018 03.59, Christof Meerwald wrote:
> On Thu, Nov 15, 2018 at 12:41:06AM -0800, gmisocpp@gmail.com wrote:
>> Currently in C++ we defined code in namespaces like this
>>
>> namespace my_name_space
>> {
>> class whatever
>> {
>> }
>> } // my_name_space
>>
>>
>> I find this syntax unsatisfying because:
>> 1. The general advice in most code style guidelines I've seen is to not
>> intent code in a namespace. This means it puts two braces together at the
>> same indentation level which I find rather ugly.
>
> Really, is that the advice? Don't think I have seen that advice.

Some projects do that. Others don't.

Note https://github.com/uncrustify/uncrustify/pull/1989.

(@Andrey, "misguided" is your opinion. Note, I'm not *advocating* that
style, but I have no objection to it, either. Use whichever you prefer.)

> BTW, another option would be:
>
> namespace my_name_space
> {
>   class whatever;
> }
>
> class my_name_space::whatever
> {
> };

I would *maybe* be okay with this. With the original proposal, not so
much. However, in either case, it would take a very strong rationale to
justify spending committee time on this. Personally, I don't see either
proposal lasting five minutes in EWG.

--
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/b633d9dc-de20-d009-83dd-c82f650e35b0%40gmail.com.

.

On Thu, 15 Nov 2018 at 17:59, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> > BTW, another option would be:
> >
> > namespace my_name_space
> > {
> >   class whatever;
> > }
> >
> > class my_name_space::whatever
> > {
> > };
>
> I would *maybe* be okay with this.

That's valid C++ code today, so it's not a proposal.

--
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/CAFk2RUaffFdLkDRa_Eub6t9HhHvsi%2Bt2t_r1yr8%3Dwi94bZCTQg%40mail.gmail.com.

.

On 11/15/18 6:59 PM, Matthew Woehlke wrote:
>
> @Andrey, "misguided" is your opinion.

Well, yes. My whole reply is my opinion. Although, I fail to see how a
guideline that recommends to avoid namespaces on the basis of aesthetics
of code indentation is not misguided.

--
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/91d86eb1-a74d-b2ce-0e80-a4c0d720ccd5%40gmail.com.

.

On 15/11/2018 11.25, Andrey Semashev wrote:
> On 11/15/18 6:59 PM, Matthew Woehlke wrote:
>> @Andrey, "misguided" is your opinion.
>
> Well, yes. My whole reply is my opinion. Although, I fail to see how a
> guideline that recommends to avoid namespaces on the basis of aesthetics
> of code indentation is not misguided.

*That* I agree with... but we were talking about whether or not to
*indent* namespace bodies, not whether or not to *have* namespaces.

--
Matthew

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

.

On Thu, Nov 15, 2018 at 7:49 PM Matthew Woehlke
<mwoehlke.floss@gmail.com> wrote:
>
> On 15/11/2018 11.25, Andrey Semashev wrote:
> > On 11/15/18 6:59 PM, Matthew Woehlke wrote:
> >> @Andrey, "misguided" is your opinion.
> >
> > Well, yes. My whole reply is my opinion. Although, I fail to see how a
> > guideline that recommends to avoid namespaces on the basis of aesthetics
> > of code indentation is not misguided.
>
> *That* I agree with... but we were talking about whether or not to
> *indent* namespace bodies, not whether or not to *have* namespaces.

Oh, I must have misread the original post then. Sorry.

--
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/CAEhD%2B6Drfu%2BG5A7ja5jL_qxV-Y0S9s24gLZYfbVf8FAb%2BrwEPA%40mail.gmail.com.

.

------=_Part_1060_392903181.1542352099780
Content-Type: multipart/alternative;
 boundary="----=_Part_1061_2093260103.1542352099780"

------=_Part_1061_2093260103.1542352099780
Content-Type: text/plain; charset="UTF-8"

On Thursday, November 15, 2018 at 11:41:06 AM UTC+3, gmis...@gmail.com
wrote:
>
> Hi Everyone
>
> Currently in C++ we defined code in namespaces like this
>
> namespace my_name_space
> {
> class whatever
> {
> }
> } // my_name_space
>
>
namespace my_name_space {

//////////////////////////////////////////////////////////////////////////////
class whatever
{
};
//////////////////////////////////////////////////////////////////////////////

} // namespace

--
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/1edc199f-e6a7-4cf0-92f7-1823d086824a%40isocpp.org.

------=_Part_1061_2093260103.1542352099780
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, November 15, 2018 at 11:41:06 AM UTC+3, gmis.=
...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div>Hi Everyone</div><div><br></div><div>Currently in C++ we defined=
 code in namespaces like this</div><div><br></div><div>namespace=C2=A0my_na=
me_space</div><div>{</div><div>class whatever</div><div>{<br>}</div><div>} =
// my_name_space<br></div><br></div></blockquote><div><br></div><div><span =
style=3D"font-family: courier new, monospace;">namespace my_name_space {<br=
><br>//////////////////////////////////////////////////////////////////////=
////////<br>class whatever<br>{<br>};<br>//////////////////////////////////=
////////////////////////////////////////////<br><br>} // namespace </span><=
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/1edc199f-e6a7-4cf0-92f7-1823d086824a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1edc199f-e6a7-4cf0-92f7-1823d086824a=
%40isocpp.org</a>.<br />

------=_Part_1061_2093260103.1542352099780--

------=_Part_1060_392903181.1542352099780--

.

------=_Part_1052_56696488.1542363217713
Content-Type: multipart/alternative;
 boundary="----=_Part_1053_1139535237.1542363217713"

------=_Part_1053_1139535237.1542363217713
Content-Type: text/plain; charset="UTF-8"

On Friday, November 16, 2018 at 8:08:19 AM UTC+1, Victor Dyachenko wrote:
>
> On Thursday, November 15, 2018 at 11:41:06 AM UTC+3, gmis...@gmail.com
> wrote:
>>
>> Hi Everyone
>>
>> Currently in C++ we defined code in namespaces like this
>>
>> namespace my_name_space
>> {
>> class whatever
>> {
>> }
>> } // my_name_space
>>
>>
> namespace my_name_space {
>
>
> //////////////////////////////////////////////////////////////////////////////
> class whatever
> {
> };
>
> //////////////////////////////////////////////////////////////////////////////
>
> } // namespace
>

Or, using clang-format (which I would definitely recommend), it would
automatically add the comment

namespace my_name_space {

////////////////////////////////////////////////////////////
//////////////////
class whatever
{
};
////////////////////////////////////////////////////////////
//////////////////

} // namespace my_name_space

--
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/5574e659-76a1-4675-bf94-cbf5cfcc00a6%40isocpp.org.

------=_Part_1053_1139535237.1542363217713
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, November 16, 2018 at 8:08:19 AM UTC+1, Victor D=
yachenko 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=
">On Thursday, November 15, 2018 at 11:41:06 AM UTC+3, <a>gmis...@gmail.com=
</a> 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"><div>Hi=
 Everyone</div><div><br></div><div>Currently in C++ we defined code in name=
spaces like this</div><div><br></div><div>namespace=C2=A0my_name_space</div=
><div>{</div><div>class whatever</div><div>{<br>}</div><div>} // my_name_sp=
ace<br></div><br></div></blockquote><div><br></div><div><span style=3D"font=
-family:courier new,monospace">namespace my_name_space {<br><br>///////////=
///////////////////<wbr>//////////////////////////////<wbr>////////////////=
//<br>class whatever<br>{<br>};<br>//////////////////////////////<wbr>/////=
/////////////////////////<wbr>//////////////////<br><br>} // namespace </sp=
an></div></div></blockquote><div><br></div><div>Or, using clang-format (whi=
ch I would definitely recommend), it would automatically add the comment</d=
iv><div><br></div><div><span style=3D"font-family: &quot;courier new&quot;,=
 monospace;">namespace my_name_space {</span><br style=3D"font-family: &quo=
t;courier new&quot;, monospace;"><br style=3D"font-family: &quot;courier ne=
w&quot;, monospace;"><span style=3D"font-family: &quot;courier new&quot;, m=
onospace;">//////////////////////////////</span><wbr style=3D"font-family: =
&quot;courier new&quot;, monospace;"><span style=3D"font-family: &quot;cour=
ier new&quot;, monospace;">//////////////////////////////</span><wbr style=
=3D"font-family: &quot;courier new&quot;, monospace;"><span style=3D"font-f=
amily: &quot;courier new&quot;, monospace;">//////////////////</span><br st=
yle=3D"font-family: &quot;courier new&quot;, monospace;"><span style=3D"fon=
t-family: &quot;courier new&quot;, monospace;">class whatever</span><br sty=
le=3D"font-family: &quot;courier new&quot;, monospace;"><span style=3D"font=
-family: &quot;courier new&quot;, monospace;">{</span><br style=3D"font-fam=
ily: &quot;courier new&quot;, monospace;"><span style=3D"font-family: &quot=
;courier new&quot;, monospace;">};</span><br style=3D"font-family: &quot;co=
urier new&quot;, monospace;"><span style=3D"font-family: &quot;courier new&=
quot;, monospace;">//////////////////////////////</span><wbr style=3D"font-=
family: &quot;courier new&quot;, monospace;"><span style=3D"font-family: &q=
uot;courier new&quot;, monospace;">//////////////////////////////</span><wb=
r style=3D"font-family: &quot;courier new&quot;, monospace;"><span style=3D=
"font-family: &quot;courier new&quot;, monospace;">//////////////////</span=
><br style=3D"font-family: &quot;courier new&quot;, monospace;"><br style=
=3D"font-family: &quot;courier new&quot;, monospace;"><span style=3D"font-f=
amily: &quot;courier new&quot;, monospace;">} // namespace=C2=A0</span><spa=
n style=3D"font-family: &quot;courier new&quot;, monospace;">my_name_space<=
/span><span style=3D"font-family: &quot;courier new&quot;, monospace;">=C2=
=A0</span><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/5574e659-76a1-4675-bf94-cbf5cfcc00a6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5574e659-76a1-4675-bf94-cbf5cfcc00a6=
%40isocpp.org</a>.<br />

------=_Part_1053_1139535237.1542363217713--

------=_Part_1052_56696488.1542363217713--

.

------=_Part_1057_1687457273.1542363783630
Content-Type: multipart/alternative;
 boundary="----=_Part_1058_1876801726.1542363783630"

------=_Part_1058_1876801726.1542363783630
Content-Type: text/plain; charset="UTF-8"

On Friday, November 16, 2018 at 1:13:37 PM UTC+3, jul...@nanolive.ch wrote:
>
>
> Or, using clang-format (which I would definitely recommend), it would
> automatically add the comment
>
> namespace my_name_space {
>
> ////////////////////////////////////////////////////////////
> //////////////////
> class whatever
> {
> };
> ////////////////////////////////////////////////////////////
> //////////////////
>
> } // namespace my_name_space
>

I strongly dislike duplicating identifiers (namespace name in this case)
because of such cases:

namespace renamed_namespace {
....
} // namespace my_name_space

DRY! (Don't Repeat Yourself)

--
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/8b6f9f0b-31de-41a4-aae7-1649c9779afb%40isocpp.org.

------=_Part_1058_1876801726.1542363783630
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, November 16, 2018 at 1:13:37 PM UTC+3, jul...@n=
anolive.ch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><br><div>Or, using clang-format (which I would definitely recommend), i=
t would automatically add the comment</div><div><br></div><div><span style=
=3D"font-family:&quot;courier new&quot;,monospace">namespace my_name_space =
{</span><br style=3D"font-family:&quot;courier new&quot;,monospace"><br sty=
le=3D"font-family:&quot;courier new&quot;,monospace"><span style=3D"font-fa=
mily:&quot;courier new&quot;,monospace">//////////////////////////////</spa=
n><span style=3D"font-family:&quot;courier new&quot;,monospace"><wbr>//////=
////////////////////////</span><span style=3D"font-family:&quot;courier new=
&quot;,monospace"><wbr>//////////////////</span><br style=3D"font-family:&q=
uot;courier new&quot;,monospace"><span style=3D"font-family:&quot;courier n=
ew&quot;,monospace">class whatever</span><br style=3D"font-family:&quot;cou=
rier new&quot;,monospace"><span style=3D"font-family:&quot;courier new&quot=
;,monospace">{</span><br style=3D"font-family:&quot;courier new&quot;,monos=
pace"><span style=3D"font-family:&quot;courier new&quot;,monospace">};</spa=
n><br style=3D"font-family:&quot;courier new&quot;,monospace"><span style=
=3D"font-family:&quot;courier new&quot;,monospace">////////////////////////=
//////</span><span style=3D"font-family:&quot;courier new&quot;,monospace">=
<wbr>//////////////////////////////</span><span style=3D"font-family:&quot;=
courier new&quot;,monospace"><wbr>//////////////////</span><br style=3D"fon=
t-family:&quot;courier new&quot;,monospace"><br style=3D"font-family:&quot;=
courier new&quot;,monospace"><span style=3D"font-family:&quot;courier new&q=
uot;,monospace">} // namespace=C2=A0</span><span style=3D"font-family:&quot=
;courier new&quot;,monospace">my_name_space</span><span style=3D"font-famil=
y:&quot;courier new&quot;,monospace">=C2=A0</span></div></div></blockquote>=
<div><br></div><div>I strongly dislike duplicating identifiers (namespace n=
ame in this case) because of such cases:</div><div><br></div><div><span sty=
le=3D"font-family:&quot;courier new&quot;,monospace">namespace renamed_name=
space {<br></span></div><div><span style=3D"font-family:&quot;courier new&q=
uot;,monospace">...<br></span></div><div><span style=3D"font-family:&quot;c=
ourier new&quot;,monospace">} // namespace=C2=A0</span><span style=3D"font-=
family:&quot;courier new&quot;,monospace">my_name_space</span><span style=
=3D"font-family:&quot;courier new&quot;,monospace">=C2=A0</span><div><br></=
div><div>DRY! (Don&#39;t Repeat Yourself)<br></div></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/8b6f9f0b-31de-41a4-aae7-1649c9779afb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8b6f9f0b-31de-41a4-aae7-1649c9779afb=
%40isocpp.org</a>.<br />

------=_Part_1058_1876801726.1542363783630--

------=_Part_1057_1687457273.1542363783630--

.

--000000000000e3b75a057ac5b979
Content-Type: text/plain; charset="UTF-8"

TOTALLY making a feature request to jetbrains to make clion display /* end
namespace NAMESPACE */ after a closing brace without modifying the file.
Killer feature.

On Fri, Nov 16, 2018 at 10:23 AM Victor Dyachenko <
victor.dyachenko@gmail.com> wrote:

> On Friday, November 16, 2018 at 1:13:37 PM UTC+3, jul...@nanolive.ch
> wrote:
>>
>>
>> Or, using clang-format (which I would definitely recommend), it would
>> automatically add the comment
>>
>> namespace my_name_space {
>>
>> ////////////////////////////////////////////////////////////
>> //////////////////
>> class whatever
>> {
>> };
>> ////////////////////////////////////////////////////////////
>> //////////////////
>>
>> } // namespace my_name_space
>>
>
> I strongly dislike duplicating identifiers (namespace name in this case)
> because of such cases:
>
> namespace renamed_namespace {
> ...
> } // namespace my_name_space
>
> DRY! (Don't Repeat Yourself)
>
> --
> 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/8b6f9f0b-31de-41a4-aae7-1649c9779afb%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8b6f9f0b-31de-41a4-aae7-1649c9779afb%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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/CAANG%3DkXg-UmmmUEixSxAT%3D%3Dy9E%2BhxsGzejaVbBfXkGNLO%2BQmcg%40mail.gmail.com.

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

<div dir=3D"ltr">TOTALLY making a feature request to jetbrains to make clio=
n display /* end namespace NAMESPACE */ after a closing brace without modif=
ying the file. Killer feature.</div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr">On Fri, Nov 16, 2018 at 10:23 AM Victor Dyachenko &lt;<a href=3D"m=
ailto:victor.dyachenko@gmail.com">victor.dyachenko@gmail.com</a>&gt; wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Friday, Novemb=
er 16, 2018 at 1:13:37 PM UTC+3, <a href=3D"mailto:jul...@nanolive.ch" targ=
et=3D"_blank">jul...@nanolive.ch</a> wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><br><div>Or, using clang-format (which I would def=
initely recommend), it would automatically add the comment</div><div><br></=
div><div><span style=3D"font-family:&quot;courier new&quot;,monospace">name=
space my_name_space {</span><br style=3D"font-family:&quot;courier new&quot=
;,monospace"><br style=3D"font-family:&quot;courier new&quot;,monospace"><s=
pan style=3D"font-family:&quot;courier new&quot;,monospace">///////////////=
///////////////</span><span style=3D"font-family:&quot;courier new&quot;,mo=
nospace">//////////////////////////////</span><span style=3D"font-family:&q=
uot;courier new&quot;,monospace">//////////////////</span><br style=3D"font=
-family:&quot;courier new&quot;,monospace"><span style=3D"font-family:&quot=
;courier new&quot;,monospace">class whatever</span><br style=3D"font-family=
:&quot;courier new&quot;,monospace"><span style=3D"font-family:&quot;courie=
r new&quot;,monospace">{</span><br style=3D"font-family:&quot;courier new&q=
uot;,monospace"><span style=3D"font-family:&quot;courier new&quot;,monospac=
e">};</span><br style=3D"font-family:&quot;courier new&quot;,monospace"><sp=
an style=3D"font-family:&quot;courier new&quot;,monospace">////////////////=
//////////////</span><span style=3D"font-family:&quot;courier new&quot;,mon=
ospace">//////////////////////////////</span><span style=3D"font-family:&qu=
ot;courier new&quot;,monospace">//////////////////</span><br style=3D"font-=
family:&quot;courier new&quot;,monospace"><br style=3D"font-family:&quot;co=
urier new&quot;,monospace"><span style=3D"font-family:&quot;courier new&quo=
t;,monospace">} // namespace=C2=A0</span><span style=3D"font-family:&quot;c=
ourier new&quot;,monospace">my_name_space</span><span style=3D"font-family:=
&quot;courier new&quot;,monospace">=C2=A0</span></div></div></blockquote><d=
iv><br></div><div>I strongly dislike duplicating identifiers (namespace nam=
e in this case) because of such cases:</div><div><br></div><div><span style=
=3D"font-family:&quot;courier new&quot;,monospace">namespace renamed_namesp=
ace {<br></span></div><div><span style=3D"font-family:&quot;courier new&quo=
t;,monospace">...<br></span></div><div><span style=3D"font-family:&quot;cou=
rier new&quot;,monospace">} // namespace=C2=A0</span><span style=3D"font-fa=
mily:&quot;courier new&quot;,monospace">my_name_space</span><span style=3D"=
font-family:&quot;courier new&quot;,monospace">=C2=A0</span><div><br></div>=
<div>DRY! (Don&#39;t Repeat Yourself)<br></div></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" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8b6f9f0b-31de-41a4-aae7-1649c9779afb%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8b6f9f0b-31de-=
41a4-aae7-1649c9779afb%40isocpp.org</a>.<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/CAANG%3DkXg-UmmmUEixSxAT%3D%3Dy9E%2Bh=
xsGzejaVbBfXkGNLO%2BQmcg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3=
DkXg-UmmmUEixSxAT%3D%3Dy9E%2BhxsGzejaVbBfXkGNLO%2BQmcg%40mail.gmail.com</a>=
..<br />

--000000000000e3b75a057ac5b979--

.

--000000000000d5e71e057ac619a7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

As promised. Would having this kind of editor support solve your issue?
https://youtrack.jetbrains.com/issue/CPP-14711

On Fri, Nov 16, 2018 at 10:35 AM Ga=C5=A1per A=C5=BEman <gasper.azman@gmail=
..com>
wrote:

> TOTALLY making a feature request to jetbrains to make clion display /* en=
d
> namespace NAMESPACE */ after a closing brace without modifying the file.
> Killer feature.
>
> On Fri, Nov 16, 2018 at 10:23 AM Victor Dyachenko <
> victor.dyachenko@gmail.com> wrote:
>
>> On Friday, November 16, 2018 at 1:13:37 PM UTC+3, jul...@nanolive.ch
>> wrote:
>>>
>>>
>>> Or, using clang-format (which I would definitely recommend), it would
>>> automatically add the comment
>>>
>>> namespace my_name_space {
>>>
>>> ////////////////////////////////////////////////////////////
>>> //////////////////
>>> class whatever
>>> {
>>> };
>>> ////////////////////////////////////////////////////////////
>>> //////////////////
>>>
>>> } // namespace my_name_space
>>>
>>
>> I strongly dislike duplicating identifiers (namespace name in this case)
>> because of such cases:
>>
>> namespace renamed_namespace {
>> ...
>> } // namespace my_name_space
>>
>> DRY! (Don't Repeat Yourself)
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/8b6f9f0b-31=
de-41a4-aae7-1649c9779afb%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8b6f9f0b-3=
1de-41a4-aae7-1649c9779afb%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAANG%3DkXtb_c2Std-CZP47BbOV1KFyfaJObZ4k7emimqcD=
4pBGA%40mail.gmail.com.

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

<div dir=3D"ltr"><div dir=3D"ltr">As promised. Would having this kind of ed=
itor support solve your issue?<div><a href=3D"https://youtrack.jetbrains.co=
m/issue/CPP-14711">https://youtrack.jetbrains.com/issue/CPP-14711</a><br></=
div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Nov=
 16, 2018 at 10:35 AM Ga=C5=A1per A=C5=BEman &lt;<a href=3D"mailto:gasper.a=
zman@gmail.com">gasper.azman@gmail.com</a>&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr">TOTALLY making a feature request to jet=
brains to make clion display /* end namespace NAMESPACE */ after a closing =
brace without modifying the file. Killer feature.</div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr">On Fri, Nov 16, 2018 at 10:23 AM Victor Dyachen=
ko &lt;<a href=3D"mailto:victor.dyachenko@gmail.com" target=3D"_blank">vict=
or.dyachenko@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr">On Friday, November 16, 2018 at 1:13:37 PM UTC+3, <a hr=
ef=3D"mailto:jul...@nanolive.ch" target=3D"_blank">jul...@nanolive.ch</a> w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div>Or, =
using clang-format (which I would definitely recommend), it would automatic=
ally add the comment</div><div><br></div><div><span style=3D"font-family:&q=
uot;courier new&quot;,monospace">namespace my_name_space {</span><br style=
=3D"font-family:&quot;courier new&quot;,monospace"><br style=3D"font-family=
:&quot;courier new&quot;,monospace"><span style=3D"font-family:&quot;courie=
r new&quot;,monospace">//////////////////////////////</span><span style=3D"=
font-family:&quot;courier new&quot;,monospace">////////////////////////////=
//</span><span style=3D"font-family:&quot;courier new&quot;,monospace">////=
//////////////</span><br style=3D"font-family:&quot;courier new&quot;,monos=
pace"><span style=3D"font-family:&quot;courier new&quot;,monospace">class w=
hatever</span><br style=3D"font-family:&quot;courier new&quot;,monospace"><=
span style=3D"font-family:&quot;courier new&quot;,monospace">{</span><br st=
yle=3D"font-family:&quot;courier new&quot;,monospace"><span style=3D"font-f=
amily:&quot;courier new&quot;,monospace">};</span><br style=3D"font-family:=
&quot;courier new&quot;,monospace"><span style=3D"font-family:&quot;courier=
 new&quot;,monospace">//////////////////////////////</span><span style=3D"f=
ont-family:&quot;courier new&quot;,monospace">/////////////////////////////=
/</span><span style=3D"font-family:&quot;courier new&quot;,monospace">/////=
/////////////</span><br style=3D"font-family:&quot;courier new&quot;,monosp=
ace"><br style=3D"font-family:&quot;courier new&quot;,monospace"><span styl=
e=3D"font-family:&quot;courier new&quot;,monospace">} // namespace=C2=A0</s=
pan><span style=3D"font-family:&quot;courier new&quot;,monospace">my_name_s=
pace</span><span style=3D"font-family:&quot;courier new&quot;,monospace">=
=C2=A0</span></div></div></blockquote><div><br></div><div>I strongly dislik=
e duplicating identifiers (namespace name in this case) because of such cas=
es:</div><div><br></div><div><span style=3D"font-family:&quot;courier new&q=
uot;,monospace">namespace renamed_namespace {<br></span></div><div><span st=
yle=3D"font-family:&quot;courier new&quot;,monospace">...<br></span></div><=
div><span style=3D"font-family:&quot;courier new&quot;,monospace">} // name=
space=C2=A0</span><span style=3D"font-family:&quot;courier new&quot;,monosp=
ace">my_name_space</span><span style=3D"font-family:&quot;courier new&quot;=
,monospace">=C2=A0</span><div><br></div><div>DRY! (Don&#39;t Repeat Yoursel=
f)<br></div></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" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8b6f9f0b-31de-41a4-aae7-1649c9779afb%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8b6f9f0b-31de-=
41a4-aae7-1649c9779afb%40isocpp.org</a>.<br>
</blockquote></div>
</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/CAANG%3DkXtb_c2Std-CZP47BbOV1KFyfaJOb=
Z4k7emimqcD4pBGA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkXtb_c2=
Std-CZP47BbOV1KFyfaJObZ4k7emimqcD4pBGA%40mail.gmail.com</a>.<br />

--000000000000d5e71e057ac619a7--

.

------=_Part_1064_1575103877.1542372290904
Content-Type: multipart/alternative;
 boundary="----=_Part_1065_1516638372.1542372290904"

------=_Part_1065_1516638372.1542372290904
Content-Type: text/plain; charset="UTF-8"

If I read the grammar correctly, the form

namespace NS;

is currently free to use.  So it could be defined to start a namespace body
that lasts to end of file. Or another such statement.

However I see little benefit from it, neither does it "solves a problem",
so IMHO it is not worth the committee time until we run out of more
valuable 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/926a8382-9fc5-4976-a8e1-eb30ab2401bc%40isocpp.org.

------=_Part_1065_1516638372.1542372290904
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>If I read the grammar correctly, the form <br></div><=
div><br></div><div>namespace NS;</div><div><br></div><div>is currently free=
 to use.=C2=A0 So it could be defined to start a namespace body that lasts =
to end of file. Or another such statement.=C2=A0=C2=A0 <br></div><div><br><=
/div><div>However I see little benefit from it, neither does it &quot;solve=
s a problem&quot;, so IMHO it is not worth the committee time until we run =
out of more valuable proposals. <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/926a8382-9fc5-4976-a8e1-eb30ab2401bc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/926a8382-9fc5-4976-a8e1-eb30ab2401bc=
%40isocpp.org</a>.<br />

------=_Part_1065_1516638372.1542372290904--

------=_Part_1064_1575103877.1542372290904--

.

------=_Part_1149_1956381989.1542373330101
Content-Type: multipart/alternative;
 boundary="----=_Part_1150_1985788601.1542373330101"

------=_Part_1150_1985788601.1542373330101
Content-Type: text/plain; charset="UTF-8"

On Thursday, 15 November 2018 08:41:06 UTC, gmis...@gmail.com wrote:
>
> 1. The general advice in most code style guidelines I've seen is to not
> intent code in a namespace. This means it puts two braces together at the
> same indentation level which I find rather ugly.
>

A few thoughts: Under this guideline, code is independent of the namespace
it appears in. Refactoring does not need to touch any code other than the
fringes of a file. (With C++17's nested namespace declarations, this is
less of an issue, but that's a very recent change, and the style guideline
is much older. Also, unnamed namespaces still exist, and refactoring
between internal and external linkage still happens.) Whether that's
important to you depends perhaps on how much your codebase is getting
refactored.

Additionally, this style avoids wasting large amounts of effectively
meaningless whitespace on the left. There's very little information learned
from the fact that you're inside a namespace, and even less so from the
various *levels* of indent if you're in nested namespaces. If you indent by
four or eight spaces, the waste is particularly gratuitous.

I'm sympathetic to the "successive braces at same column" problem, but I
guess that's why you annotate the namespace close with a matching-comment
so that you have *some* visual distinction.

In a nutshell, namespaces are an ancillary tool for large-scale code
organization, not a microsyntactical one, and so one can argue that they
don't deserve the same stylistic markers (and the attention those demand)
as other parts of the language. It's certainly a trade-off and a matter of
taste, but I find it a fairly defensible choice.

--
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/32d2e07a-a82c-48d4-b88c-69482229b680%40isocpp.org.

------=_Part_1150_1985788601.1542373330101
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, 15 November 2018 08:41:06 UTC, gmis...@gmail.=
com  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv>1.=C2=A0The general advice in most code style guidelines I&#39;ve seen i=
s to not intent code in a namespace. This means it puts two braces together=
 at the same indentation level which I find rather ugly.</div></div></block=
quote><div><br></div><div>A few thoughts: Under this guideline, code is ind=
ependent of the namespace it appears in. Refactoring does not need to touch=
 any code other than the fringes of a file. (With C++17&#39;s nested namesp=
ace declarations, this is less of an issue, but that&#39;s a very recent ch=
ange, and the style guideline is much older. Also, unnamed namespaces still=
 exist, and refactoring between internal and external linkage still happens=
..) Whether that&#39;s important to you depends perhaps on how much your cod=
ebase is getting refactored.</div><div><br></div><div>Additionally, this st=
yle avoids wasting large amounts of effectively meaningless whitespace on t=
he left. There&#39;s very little information learned from the fact that you=
&#39;re inside a namespace, and even less so from the various <i>levels</i>=
 of indent if you&#39;re in nested namespaces. If you indent by four or eig=
ht spaces, the waste is particularly gratuitous.</div><div><br></div><div>I=
&#39;m sympathetic to the &quot;successive braces at same column&quot; prob=
lem, but I guess that&#39;s why you annotate the namespace close with a mat=
ching-comment so that you have <i>some</i>=C2=A0visual distinction.</div><d=
iv><br></div><div>In a nutshell, namespaces are an ancillary tool for large=
-scale code organization, not a microsyntactical one, and so one can argue =
that they don&#39;t deserve the same stylistic markers (and the attention t=
hose demand) as other parts of the language. It&#39;s certainly a trade-off=
 and a matter of taste, but I find it a fairly defensible choice.</div></di=
v>

<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/32d2e07a-a82c-48d4-b88c-69482229b680%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/32d2e07a-a82c-48d4-b88c-69482229b680=
%40isocpp.org</a>.<br />

------=_Part_1150_1985788601.1542373330101--

------=_Part_1149_1956381989.1542373330101--

.

--000000000000deecdf057ac7f35d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 16 Nov 2018, 13:02 'Thomas K=C3=B6ppe' via ISO C++ Standard - Futur=
e
Proposals <std-proposals@isocpp.org wrote:

> On Thursday, 15 November 2018 08:41:06 UTC, gmis...@gmail.com wrote:
>>
>> 1. The general advice in most code style guidelines I've seen is to not
>> intent code in a namespace. This means it puts two braces together at th=
e
>> same indentation level which I find rather ugly.
>>
>
> A few thoughts: Under this guideline, code is independent of the namespac=
e
> it appears in. Refactoring does not need to touch any code other than the
> fringes of a file. (With C++17's nested namespace declarations, this is
> less of an issue, but that's a very recent change, and the style guidelin=
e
> is much older. Also, unnamed namespaces still exist, and refactoring
> between internal and external linkage still happens.) Whether that's
> important to you depends perhaps on how much your codebase is getting
> refactored.
>

That would explain why the clang-format default styles all leave namespaces
unindented. I've always indented them, but I don't mess around much with
namespace changes often and my repos aren't exactly huge. Definitely
something I'll consider changing.

Additionally, this style avoids wasting large amounts of effectively
> meaningless whitespace on the left. There's very little information learn=
ed
> from the fact that you're inside a namespace, and even less so from the
> various *levels* of indent if you're in nested namespaces. If you indent
> by four or eight spaces, the waste is particularly gratuitous.
>

> I'm sympathetic to the "successive braces at same column" problem, but I
> guess that's why you annotate the namespace close with a matching-comment
> so that you have *some* visual distinction.
>

Maybe it's a habit I picked up from python, but I see namespaces as scope
blocks for types (which I'd love to see templatable, but that's not a
popular opinion) and I recoil in horror when I don't see scope blocks
indented.

In a nutshell, namespaces are an ancillary tool for large-scale code
> organization, not a microsyntactical one, and so one can argue that they
> don't deserve the same stylistic markers (and the attention those demand)
> as other parts of the language. It's certainly a trade-off and a matter o=
f
> taste, but I find it a fairly defensible choice.
>

That's fair enough. I think this response might make me change my ways. I
still stick to an 80 char column width limit and have no problem, but then
most all of my code is 2 namespaces deep, and in almost-always-auto land
those 8 characters arent as precious.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAC%2B0CCPOmtnNCQBXm97apyA8HDVht7VugC0iBi098u_0v=
0h%2BrA%40mail.gmail.com.

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

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, =
16 Nov 2018, 13:02 &#39;Thomas K=C3=B6ppe&#39; via ISO C++ Standard - Futur=
e Proposals &lt;<a href=3D"mailto:std-proposals@isocpp.org">std-proposals@i=
socpp.org</a> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">On Thursday, 15 November 2018 08:41:06 UTC, <a href=3D"mailto:gmis...@gm=
ail.com" target=3D"_blank" rel=3D"noreferrer">gmis...@gmail.com</a>  wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>1.=C2=A0The g=
eneral advice in most code style guidelines I&#39;ve seen is to not intent =
code in a namespace. This means it puts two braces together at the same ind=
entation level which I find rather ugly.</div></div></blockquote><div><br><=
/div><div>A few thoughts: Under this guideline, code is independent of the =
namespace it appears in. Refactoring does not need to touch any code other =
than the fringes of a file. (With C++17&#39;s nested namespace declarations=
, this is less of an issue, but that&#39;s a very recent change, and the st=
yle guideline is much older. Also, unnamed namespaces still exist, and refa=
ctoring between internal and external linkage still happens.) Whether that&=
#39;s important to you depends perhaps on how much your codebase is getting=
 refactored.</div></div></blockquote></div></div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">That would explain why the clang-format default styles =
all leave namespaces unindented. I&#39;ve always indented them, but I don&#=
39;t mess around much with namespace changes often and my repos aren&#39;t =
exactly huge. Definitely something I&#39;ll consider changing.=C2=A0</div><=
div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Additionally, this style =
avoids wasting large amounts of effectively meaningless whitespace on the l=
eft. There&#39;s very little information learned from the fact that you&#39=
;re inside a namespace, and even less so from the various <i>levels</i> of =
indent if you&#39;re in nested namespaces. If you indent by four or eight s=
paces, the waste is particularly gratuitous.</div></div></blockquote></div>=
</div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div></div><div><br></div><div>I&#39;m sympathetic =
to the &quot;successive braces at same column&quot; problem, but I guess th=
at&#39;s why you annotate the namespace close with a matching-comment so th=
at you have <i>some</i>=C2=A0visual distinction.</div></div></blockquote></=
div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Maybe it&#39;s a ha=
bit I picked up from python, but I see namespaces as scope blocks for types=
 (which I&#39;d love to see templatable, but that&#39;s not a popular opini=
on) and I recoil in horror when I don&#39;t see scope blocks indented.</div=
><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>In a nutshell, namespac=
es are an ancillary tool for large-scale code organization, not a microsynt=
actical one, and so one can argue that they don&#39;t deserve the same styl=
istic markers (and the attention those demand) as other parts of the langua=
ge. It&#39;s certainly a trade-off and a matter of taste, but I find it a f=
airly defensible choice.<br></div></div></blockquote></div></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">That&#39;s fair enough. I think this =
response might make me change my ways. I still stick to an 80 char column w=
idth limit and have no problem, but then most all of my code is 2 namespace=
s deep, and in almost-always-auto land those 8 characters arent as precious=
..</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/CAC%2B0CCPOmtnNCQBXm97apyA8HDVht7VugC=
0iBi098u_0v0h%2BrA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPOmt=
nNCQBXm97apyA8HDVht7VugC0iBi098u_0v0h%2BrA%40mail.gmail.com</a>.<br />

--000000000000deecdf057ac7f35d--

.