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

To fix a minor annoyance for a long time, I think that the initializer list=
 following a constructor prototype should allow a trailing comma with nothi=
ng after it.  This also makes initializer lists consistent with enums (C++1=
1) and aggregate initializers (C++03?).  The purpose is to assist when edit=
ing, and helping when using "svn blame" or the equivalent for your version =
control.

Yes, I have seen the workaround of putting commas on the next line, but thi=
s doesn't match some coding styles.

class dword_table
{
public:
    dword_table(std::size_t count)
    try
    :   m_array(new std::uint32_t[count]),
        m_count(count),
    {
    }
    catch (std::bad_alloc)
    {
        std::fprintf(stderr, "out of memory allocating %zu dwords", count);
        throw;
    }
    ...
};

Melissa

--=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_4098_1457296154.1438034527020--

.

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

To fix a minor annoyance for a long time, I think that the initializer list=
 following a constructor prototype should allow a trailing comma with nothi=
ng after it.  This also makes initializer lists consistent with enums (C++1=
1) and aggregate initializers (C++03?).  The purpose is to assist when edit=
ing, and helping when using "svn blame" or the equivalent for your version =
control.

Yes, I have seen the workaround of putting commas on the next line, but thi=
s doesn't match some coding styles.

class dword_table
{
public:
    dword_table(std::size_t count)
    try
    :   m_array(new std::uint32_t[count]),
        m_count(count),
    {
    }
    catch (std::bad_alloc)
    {
        std::fprintf(stderr, "out of memory allocating %zu dwords", count);
        throw;
    }
    ...
};

Melissa

--=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_28_2042011089.1438034526468--

.

On Monday 27 July 2015 15:02:06 Myriachan wrote:
> To fix a minor annoyance for a long time, I think that the initializer list
> following a constructor prototype should allow a trailing comma with
> nothing after it.  This also makes initializer lists consistent with enums
> (C++11) and aggregate initializers (C++03?).  The purpose is to assist when
> editing, and helping when using "svn blame" or the equivalent for your
> version control.
>
> Yes, I have seen the workaround of putting commas on the next line, but this
> doesn't match some coding styles.
>
> class dword_table
> {
> public:
>     dword_table(std::size_t count)
>     try
>
>     :   m_array(new std::uint32_t[count]),
>
>         m_count(count),
>     {
>     }
>     catch (std::bad_alloc)
>     {
>         std::fprintf(stderr, "out of memory allocating %zu dwords", count);
>         throw;
>     }
>     ...
> };

I would favour this, even if for the simple reason that it would be another
argument against writing:

    dword_table(std::size_t count)
    :   m_array(new std::uint32_t[count])
    , m_count(count)
    , m_other(1)
    {
    }

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

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

What's wrong with:

my_class(int something)
    : m_something(something)
    , m_something_else(nullptr)
    , m_init(false) {
}

I think it looks nice, reads well, cuts-and-pastes well, etc.  Is there
something here other than personal preference?

On Mon, Jul 27, 2015 at 4:11 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> On Monday 27 July 2015 15:02:06 Myriachan wrote:
> > To fix a minor annoyance for a long time, I think that the initializer
> list
> > following a constructor prototype should allow a trailing comma with
> > nothing after it.  This also makes initializer lists consistent with
> enums
> > (C++11) and aggregate initializers (C++03?).  The purpose is to assist
> when
> > editing, and helping when using "svn blame" or the equivalent for your
> > version control.
> >
> > Yes, I have seen the workaround of putting commas on the next line, but
> this
> > doesn't match some coding styles.
> >
> > class dword_table
> > {
> > public:
> >     dword_table(std::size_t count)
> >     try
> >
> >     :   m_array(new std::uint32_t[count]),
> >
> >         m_count(count),
> >     {
> >     }
> >     catch (std::bad_alloc)
> >     {
> >         std::fprintf(stderr, "out of memory allocating %zu dwords",
> count);
> >         throw;
> >     }
> >     ...
> > };
>
> I would favour this, even if for the simple reason that it would be another
> argument against writing:
>
>     dword_table(std::size_t count)
>     :   m_array(new std::uint32_t[count])
>     , m_count(count)
>     , m_other(1)
>     {
>     }
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr">What&#39;s wrong with:<div><br></div><div>my_class(int som=
ething)</div><div>=C2=A0 =C2=A0 : m_something(something)</div><div>=C2=A0 =
=C2=A0 , m_something_else(nullptr)</div><div>=C2=A0 =C2=A0 , m_init(false) =
{</div><div>}</div><div><br></div><div>I think it looks nice, reads well, c=
uts-and-pastes well, etc.=C2=A0 Is there something here other than personal=
 preference?</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote">On Mon, Jul 27, 2015 at 4:11 PM, Thiago Macieira <span dir=3D"ltr">&=
lt;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira=
..org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D=
"">On Monday 27 July 2015 15:02:06 Myriachan wrote:<br>
&gt; To fix a minor annoyance for a long time, I think that the initializer=
 list<br>
&gt; following a constructor prototype should allow a trailing comma with<b=
r>
&gt; nothing after it.=C2=A0 This also makes initializer lists consistent w=
ith enums<br>
&gt; (C++11) and aggregate initializers (C++03?).=C2=A0 The purpose is to a=
ssist when<br>
&gt; editing, and helping when using &quot;svn blame&quot; or the equivalen=
t for your<br>
&gt; version control.<br>
&gt;<br>
&gt; Yes, I have seen the workaround of putting commas on the next line, bu=
t this<br>
&gt; doesn&#39;t match some coding styles.<br>
&gt;<br>
&gt; class dword_table<br>
&gt; {<br>
&gt; public:<br>
&gt;=C2=A0 =C2=A0 =C2=A0dword_table(std::size_t count)<br>
&gt;=C2=A0 =C2=A0 =C2=A0try<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0m_array(new std::uint32_t[count]),<br=
>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0m_count(count),<br>
&gt;=C2=A0 =C2=A0 =C2=A0{<br>
&gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt;=C2=A0 =C2=A0 =C2=A0catch (std::bad_alloc)<br>
&gt;=C2=A0 =C2=A0 =C2=A0{<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::fprintf(stderr, &quot;out of mem=
ory allocating %zu dwords&quot;, count);<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0throw;<br>
&gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt;=C2=A0 =C2=A0 =C2=A0...<br>
&gt; };<br>
<br>
</span>I would favour this, even if for the simple reason that it would be =
another<br>
argument against writing:<br>
<br>
=C2=A0 =C2=A0 dword_table(std::size_t count)<br>
=C2=A0 =C2=A0 :=C2=A0 =C2=A0m_array(new std::uint32_t[count])<br>
=C2=A0 =C2=A0 , m_count(count)<br>
=C2=A0 =C2=A0 , m_other(1)<br>
=C2=A0 =C2=A0 {<br>
=C2=A0 =C2=A0 }<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF4 535=
8<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" 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 />

--001a114081d8eb55d3051be3a1c6--

.

On Monday 27 July 2015 16:22:51 Christopher Horvath wrote:
> What's wrong with:
>
> my_class(int something)
>     : m_something(something)
>     , m_something_else(nullptr)
>     , m_init(false) {
> }
>
> I think it looks nice, reads well, cuts-and-pastes well, etc.  Is there
> something here other than personal preference?

Personal preference. I find lines starting with a comma to be poor taste.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

--047d7b86dd26ddb28d051be3c63c
Content-Type: text/plain; charset=UTF-8

I like the way they line up.  This is the only place I use this idiom.
Apologies for the noise and the distasteful code!

On Mon, Jul 27, 2015 at 4:26 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> On Monday 27 July 2015 16:22:51 Christopher Horvath wrote:
> > What's wrong with:
> >
> > my_class(int something)
> >     : m_something(something)
> >     , m_something_else(nullptr)
> >     , m_init(false) {
> > }
> >
> > I think it looks nice, reads well, cuts-and-pastes well, etc.  Is there
> > something here other than personal preference?
>
> Personal preference. I find lines starting with a comma to be poor taste.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr">I like the way they line up.=C2=A0 This is the only place =
I use this idiom.=C2=A0 Apologies for the noise and the distasteful code!</=
div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Jul 2=
7, 2015 at 4:26 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=3D"mailto=
:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Monday 27 July=
 2015 16:22:51 Christopher Horvath wrote:<br>
&gt; What&#39;s wrong with:<br>
&gt;<br>
&gt; my_class(int something)<br>
&gt;=C2=A0 =C2=A0 =C2=A0: m_something(something)<br>
&gt;=C2=A0 =C2=A0 =C2=A0, m_something_else(nullptr)<br>
&gt;=C2=A0 =C2=A0 =C2=A0, m_init(false) {<br>
&gt; }<br>
&gt;<br>
&gt; I think it looks nice, reads well, cuts-and-pastes well, etc.=C2=A0 Is=
 there<br>
&gt; something here other than personal preference?<br>
<br>
</span>Personal preference. I find lines starting with a comma to be poor t=
aste.<br>
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
<span class=3D"">=C2=A0 =C2=A0Software Architect - Intel Open Source Techno=
logy Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF4 535=
8<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>
</span>To unsubscribe from this group and stop receiving emails from it, se=
nd an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">st=
d-proposals+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/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</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 />

--047d7b86dd26ddb28d051be3c63c--

.

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

On Mon, Jul 27, 2015 at 4:22 PM, Christopher Horvath <blackencino@gmail.com>
wrote:

> What's wrong with:
>
> my_class(int something)
>     : m_something(something)
>     , m_something_else(nullptr)
>     , m_init(false) {
> }
>
> I think it looks nice, reads well, cuts-and-pastes well, etc.  Is there
> something here other than personal preference?
>

Yes. This convention has a special case for the first line (it has a colon
not a comma) and for the last line (since you are putting the open brace
there), so adding/removing/reordering fields is not as simple as reordering
the lines.

On Mon, Jul 27, 2015 at 4:11 PM, Thiago Macieira <thiago@macieira.org>
> wrote:
>
>> On Monday 27 July 2015 15:02:06 Myriachan wrote:
>> > To fix a minor annoyance for a long time, I think that the initializer
>> list
>> > following a constructor prototype should allow a trailing comma with
>> > nothing after it.  This also makes initializer lists consistent with
>> enums
>> > (C++11) and aggregate initializers (C++03?).  The purpose is to assist
>> when
>> > editing, and helping when using "svn blame" or the equivalent for your
>> > version control.
>> >
>> > Yes, I have seen the workaround of putting commas on the next line, but
>> this
>> > doesn't match some coding styles.
>> >
>> > class dword_table
>> > {
>> > public:
>> >     dword_table(std::size_t count)
>> >     try
>> >
>> >     :   m_array(new std::uint32_t[count]),
>> >
>> >         m_count(count),
>> >     {
>> >     }
>> >     catch (std::bad_alloc)
>> >     {
>> >         std::fprintf(stderr, "out of memory allocating %zu dwords",
>> count);
>> >         throw;
>> >     }
>> >     ...
>> > };
>>
>> I would favour this, even if for the simple reason that it would be
>> another
>> argument against writing:
>>
>>     dword_table(std::size_t count)
>>     :   m_array(new std::uint32_t[count])
>>     , m_count(count)
>>     , m_other(1)
>>     {
>>     }
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>    Software Architect - Intel Open Source Technology Center
>>       PGP/GPG: 0x6EF45358; fingerprint:
>>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>>
>> --
>>
>> ---
>> 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/.
>

--

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

--bcaec52d52ddcd3ccf051be44331
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 M=
on, Jul 27, 2015 at 4:22 PM, Christopher Horvath <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:blackencino@gmail.com" target=3D"_blank">blackencino@gmail.co=
m</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
What&#39;s wrong with:<div><br></div><div>my_class(int something)</div><div=
>=C2=A0 =C2=A0 : m_something(something)</div><div>=C2=A0 =C2=A0 , m_somethi=
ng_else(nullptr)</div><div>=C2=A0 =C2=A0 , m_init(false) {</div><div>}</div=
><div><br></div><div>I think it looks nice, reads well, cuts-and-pastes wel=
l, etc.=C2=A0 Is there something here other than personal preference?</div>=
</div></blockquote><div><br></div><div>Yes. This convention has a special c=
ase for the first line (it has a colon not a comma) and for the last line (=
since you are putting the open brace there), so adding/removing/reordering =
fields is not as simple as reordering the lines.</div><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div class=3D"gmail_extra"><div class=3D"gmail_quo=
te"><div><div class=3D"h5">On Mon, Jul 27, 2015 at 4:11 PM, Thiago Macieira=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.org" target=3D"_bl=
ank">thiago@macieira.org</a>&gt;</span> wrote:<br></div></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div><div class=3D"h5"><span>On Monday 27 July 2015 15:02=
:06 Myriachan wrote:<br>
&gt; To fix a minor annoyance for a long time, I think that the initializer=
 list<br>
&gt; following a constructor prototype should allow a trailing comma with<b=
r>
&gt; nothing after it.=C2=A0 This also makes initializer lists consistent w=
ith enums<br>
&gt; (C++11) and aggregate initializers (C++03?).=C2=A0 The purpose is to a=
ssist when<br>
&gt; editing, and helping when using &quot;svn blame&quot; or the equivalen=
t for your<br>
&gt; version control.<br>
&gt;<br>
&gt; Yes, I have seen the workaround of putting commas on the next line, bu=
t this<br>
&gt; doesn&#39;t match some coding styles.<br>
&gt;<br>
&gt; class dword_table<br>
&gt; {<br>
&gt; public:<br>
&gt;=C2=A0 =C2=A0 =C2=A0dword_table(std::size_t count)<br>
&gt;=C2=A0 =C2=A0 =C2=A0try<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0m_array(new std::uint32_t[count]),<br=
>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0m_count(count),<br>
&gt;=C2=A0 =C2=A0 =C2=A0{<br>
&gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt;=C2=A0 =C2=A0 =C2=A0catch (std::bad_alloc)<br>
&gt;=C2=A0 =C2=A0 =C2=A0{<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::fprintf(stderr, &quot;out of mem=
ory allocating %zu dwords&quot;, count);<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0throw;<br>
&gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt;=C2=A0 =C2=A0 =C2=A0...<br>
&gt; };<br>
<br>
</span>I would favour this, even if for the simple reason that it would be =
another<br>
argument against writing:<br>
<br>
=C2=A0 =C2=A0 dword_table(std::size_t count)<br>
=C2=A0 =C2=A0 :=C2=A0 =C2=A0m_array(new std::uint32_t[count])<br>
=C2=A0 =C2=A0 , m_count(count)<br>
=C2=A0 =C2=A0 , m_other(1)<br>
=C2=A0 =C2=A0 {<br>
=C2=A0 =C2=A0 }<br>
</div></div><span><font color=3D"#888888"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><span class=3D""><=
br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF4 535=
8<br>
</span></font></span><div><div><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></span>
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>
</div></div></blockquote></div><br></div><span class=3D"">

<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></span>
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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></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 />

--bcaec52d52ddcd3ccf051be44331--

.

On 2015-07-27 18:02, Myriachan wrote:
> To fix a minor annoyance for a long time, I think that the
> initializer list following a constructor prototype should allow a
> trailing comma with nothing after it.  This also makes initializer
> lists consistent with enums (C++11) and aggregate initializers
> (C++03?).  The purpose is to assist when editing, and helping when
> using "svn blame" or the equivalent for your version control.

+1

> Yes, I have seen the workaround of putting commas on the next line,
> but this doesn't match some coding styles.

And it has analogous problems with inserting members at the front.

John Bytheway

--

---
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_205_2065510274.1438046553295
Content-Type: multipart/alternative;
 boundary="----=_Part_206_1226202398.1438046553295"

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

The actual wording change seems to be trivial:
https://github.com/cplusplus/draft/commit/5417003045bad50705847f3d20ff72d78=
aeec32a

I suppose a formal proposal is still required, though, since otherwise=20
there'd be no way for committee members to register opposition?

=E2=80=93Arthur

On Monday, July 27, 2015 at 3:02:06 PM UTC-7, Myriachan wrote:
>
> To fix a minor annoyance for a long time, I think that the initializer=20
> list following a constructor prototype should allow a trailing comma with=
=20
> nothing after it.  This also makes initializer lists consistent with enum=
s=20
> (C++11) and aggregate initializers (C++03?).  The purpose is to assist wh=
en=20
> editing, and helping when using "svn blame" or the equivalent for your=20
> version control.
>
> Yes, I have seen the workaround of putting commas on the next line, but=
=20
> this doesn't match some coding styles.
>
> class dword_table
> {
> public:
>     dword_table(std::size_t count)
>     try
>     :   m_array(new std::uint32_t[count]),
>         m_count(count),
>     {
>     }
>     catch (std::bad_alloc)
>     {
>         std::fprintf(stderr, "out of memory allocating %zu dwords", count=
);
>         throw;
>     }
>     ...
> };
>
> Melissa
>
>

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

<div dir=3D"ltr">The actual wording change seems to be trivial:<div>https:/=
/github.com/cplusplus/draft/commit/5417003045bad50705847f3d20ff72d78aeec32a=
</div><div><br></div><div>I suppose a formal proposal is still required, th=
ough, since otherwise there&#39;d be no way for committee members to regist=
er opposition?</div><div><br></div><div>=E2=80=93Arthur<br><br>On Monday, J=
uly 27, 2015 at 3:02:06 PM UTC-7, Myriachan wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;">To fix a minor annoyance for a long time, I think that =
the initializer list following a constructor prototype should allow a trail=
ing comma with nothing after it. =C2=A0This also makes initializer lists co=
nsistent with enums (C++11) and aggregate initializers (C++03?). =C2=A0The =
purpose is to assist when editing, and helping when using &quot;svn blame&q=
uot; or the equivalent for your version control.<p>Yes, I have seen the wor=
karound of putting commas on the next line, but this doesn&#39;t match some=
 coding styles.</p><p>class dword_table<br>{<br>public:<br>=C2=A0 =C2=A0 dw=
ord_table(std::size_t count)<br>=C2=A0 =C2=A0 try<br>=C2=A0 =C2=A0 : =C2=A0=
 m_array(new std::uint32_t[count]),<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 m_count(=
count),<br>=C2=A0 =C2=A0 {<br>=C2=A0 =C2=A0 }<br>=C2=A0 =C2=A0 catch (std::=
bad_alloc)<br>=C2=A0 =C2=A0 {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 std::fprintf(s=
tderr, &quot;out of memory allocating %zu dwords&quot;, count);<br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 throw;<br>=C2=A0 =C2=A0 }<br>=C2=A0 =C2=A0 ...<br>};</=
p><p>Melissa</p><p></p><p></p></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_206_1226202398.1438046553295--
------=_Part_205_2065510274.1438046553295--

.

------=_Part_1549_1171996137.1438049627715
Content-Type: multipart/alternative;
 boundary="----=_Part_1550_725617214.1438049627715"

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

On Monday, July 27, 2015 at 4:22:53 PM UTC-7, Christopher Horvath wrote:
>
> What's wrong with:
>
> my_class(int something)
>     : m_something(something)
>     , m_something_else(nullptr)
>     , m_init(false) {
> }
>
> I think it looks nice, reads well, cuts-and-pastes well, etc.  Is there=
=20
> something here other than personal preference?
>
>
Nothing is wrong with your way, except the location of the brace (adding to=
=20
the list requires deleting the brace).  It's just personal preference.  I=
=20
think beginning with a comma is weird, like Thiago thinks, but you may not=
=20
feel that it's weird.  Use whichever, IMO.


I like the way they line up.  This is the only place I use this idiom. =20
> Apologies for the noise and the distasteful code!
>
=20
>

That it's the only place this idiom gets used is to me a symptom of what I=
=20
see as a problem: in two other similar cases, enums and aggregate=20
initializers, you don't use it.

We wouldn't want to allow it for the comma operator, I would think, because=
=20
otherwise either a new overload (unary postfix operator ,) would be=20
required or a special rule to ignore it would be required.

For function calls, it would be awkward, because it kind of looks like=20
another parameter is there.  Python does allow this, though.  (Python,=20
however, gives the single parameter (x,) different meaning to (x); the=20
comma forces tuple/argument parsing instead of merely a parenthesized=20
expression.)

For function prototypes (including as part of definitions), it could be=20
useful for very long argument lists that are written one per line; this is=
=20
an uncommon edge case, though.  Similar for template parameters.  (What the=
=20
heck you're doing with a template parameter list so large, I don't know >.<=
)

Regarding being distasteful, it's just a visual preference.  Both are quite=
=20
readable.  I would get a lot more distaste for not encapsulating classes=20
properly or undefined behavior. =3D^-^=3D

On Monday, July 27, 2015 at 6:22:33 PM UTC-7, Arthur O'Dwyer wrote:
>
> The actual wording change seems to be trivial:
>
> https://github.com/cplusplus/draft/commit/5417003045bad50705847f3d20ff72d=
78aeec32a
>
> I suppose a formal proposal is still required, though, since otherwise=20
> there'd be no way for committee members to register opposition?
>
> =E2=80=93Arthur
>
>
Shouldn't that have happened before committing to the draft?  Just curious;=
=20
I'm not sure what the protocol should be.

By the way, I apologize for the double post.  Apparently, Google's posting=
=20
form doesn't have bounce protection--the two "clicks" were from my thumb on=
=20
my phone 1/8 second part.

Melissa

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

<div dir=3D"ltr">On Monday, July 27, 2015 at 4:22:53 PM UTC-7, Christopher =
Horvath wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>What&#39;s wrong with:<div><br></div><div>my_class(int something)</div><di=
v>=C2=A0 =C2=A0 : m_something(something)</div><div>=C2=A0 =C2=A0 , m_someth=
ing_else(nullptr)</div><div>=C2=A0 =C2=A0 , m_init(false) {</div><div>}</di=
v><div><br></div><div>I think it looks nice, reads well, cuts-and-pastes we=
ll, etc.=C2=A0 Is there something here other than personal preference?</div=
></div><div><br></div></blockquote><br>Nothing
 is wrong with your way, except the location of the brace (adding to the
 list requires deleting the brace).=C2=A0 It&#39;s just personal preference=
..=C2=A0 I=20
think beginning with a comma is weird, like Thiago thinks, but you may not
 feel that it&#39;s weird.=C2=A0 Use whichever, IMO.<br><br><br><blockquote=
 style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 2=
04); padding-left: 1ex;" class=3D"gmail_quote">I like the way they line up.=
=C2=A0 This is the only place I use this idiom.=C2=A0 Apologies for the noi=
se and the distasteful code!<br></blockquote><blockquote style=3D"margin: 0=
px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: =
1ex;" class=3D"gmail_quote"><div>=C2=A0</div></blockquote><br>That it&#39;s=
 the only place this idiom gets used is to me a symptom of what I see as a =
problem: in two other similar cases, enums and aggregate initializers, you =
don&#39;t use it.<br><br>We wouldn&#39;t want to allow it for the comma ope=
rator, I would think, because otherwise either a new overload (unary postfi=
x operator ,) would be required or a special rule to ignore it would be req=
uired.<br><br>For function calls, it would be awkward, because it kind of l=
ooks like another parameter is there.=C2=A0 Python does allow this, though.=
=C2=A0 (Python, however, gives the single parameter (x,) different meaning =
to (x); the comma forces tuple/argument parsing instead of merely a parenth=
esized expression.)<br><br>For function prototypes (including as part of de=
finitions), it could be useful for very long argument lists that are writte=
n one per line; this is an uncommon edge case, though.=C2=A0 Similar for te=
mplate parameters.=C2=A0 (What the heck you&#39;re doing with a template pa=
rameter list so large, I don&#39;t know &gt;.&lt;)<br><br>Regarding being d=
istasteful, it&#39;s just a visual preference.=C2=A0 Both are quite readabl=
e.=C2=A0 I would get a lot more distaste for not encapsulating classes prop=
erly or undefined behavior. =3D^-^=3D<br><br>On Monday, July 27, 2015 at 6:=
22:33 PM UTC-7, Arthur O&#39;Dwyer wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr">The actual wording change seems to be trivial:<=
div><a href=3D"https://github.com/cplusplus/draft/commit/5417003045bad50705=
847f3d20ff72d78aeec32a" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fc=
plusplus%2Fdraft%2Fcommit%2F5417003045bad50705847f3d20ff72d78aeec32a\46sa\7=
5D\46sntz\0751\46usg\75AFQjCNFsBeyQ09JpN4au_A02ZL3CY3w-cg&#39;;return true;=
" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2F=
github.com%2Fcplusplus%2Fdraft%2Fcommit%2F5417003045bad50705847f3d20ff72d78=
aeec32a\46sa\75D\46sntz\0751\46usg\75AFQjCNFsBeyQ09JpN4au_A02ZL3CY3w-cg&#39=
;;return true;">https://github.com/cplusplus/draft/commit/5417003045bad5070=
5847f3d20ff72d78aeec32a</a></div><div><br></div><div>I suppose a formal pro=
posal is still required, though, since otherwise there&#39;d be no way for =
committee members to register opposition?</div><div><br></div><div>=E2=80=
=93Arthur<br><br></div></div></blockquote><div><br>Shouldn&#39;t that have =
happened before committing to the draft?=C2=A0 Just curious; I&#39;m not su=
re what the protocol should be.<br><br>By the way, I apologize for the doub=
le post.=C2=A0 Apparently, Google&#39;s=20
posting form doesn&#39;t have bounce protection--the two &quot;clicks&quot;=
 were from=20
my thumb on my phone 1/8 second part.<br><br>Melissa<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_1550_725617214.1438049627715--
------=_Part_1549_1171996137.1438049627715--

.

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

El 27/7/2015 21:52, "John Bytheway" <jbytheway@gmail.com> escribi=C3=B3:
>
> On 2015-07-27 18:02, Myriachan wrote:
> > To fix a minor annoyance for a long time, I think that the
> > initializer list following a constructor prototype should allow a
> > trailing comma with nothing after it.  This also makes initializer
> > lists consistent with enums (C++11) and aggregate initializers
> > (C++03?).  The purpose is to assist when editing, and helping when
> > using "svn blame" or the equivalent for your version control.
>
> +1

FWIW, maybe it's irrelevant, but differentiating the last member in the
initialization list has always been annoying when either automatic
generating code or in X-macros.

>
> > Yes, I have seen the workaround of putting commas on the next line,
> > but this doesn't match some coding styles.
>
> And it has analogous problems with inserting members at the front.
>
> John Bytheway
>
> --
>
> ---
> 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/.

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

<p dir=3D"ltr"><br>
El 27/7/2015 21:52, &quot;John Bytheway&quot; &lt;<a href=3D"mailto:jbythew=
ay@gmail.com">jbytheway@gmail.com</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt; On 2015-07-27 18:02, Myriachan wrote:<br>
&gt; &gt; To fix a minor annoyance for a long time, I think that the<br>
&gt; &gt; initializer list following a constructor prototype should allow a=
<br>
&gt; &gt; trailing comma with nothing after it.=C2=A0 This also makes initi=
alizer<br>
&gt; &gt; lists consistent with enums (C++11) and aggregate initializers<br=
>
&gt; &gt; (C++03?).=C2=A0 The purpose is to assist when editing, and helpin=
g when<br>
&gt; &gt; using &quot;svn blame&quot; or the equivalent for your version co=
ntrol.<br>
&gt;<br>
&gt; +1</p>
<p dir=3D"ltr">FWIW, maybe it&#39;s irrelevant, but differentiating the las=
t member in the initialization list has always been annoying when either au=
tomatic generating code or in X-macros.<br></p>
<p dir=3D"ltr">&gt;<br>
&gt; &gt; Yes, I have seen the workaround of putting commas on the next lin=
e,<br>
&gt; &gt; but this doesn&#39;t match some coding styles.<br>
&gt;<br>
&gt; And it has analogous problems with inserting members at the front.<br>
&gt;<br>
&gt; John Bytheway<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; ---<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>

<p></p>

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

--089e0141a8dca49b89051be606b3--

.

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

On Mon, Jul 27, 2015 at 7:13 PM, Myriachan <myriachan@gmail.com> wrote:

> On Monday, July 27, 2015 at 4:22:53 PM UTC-7, Christopher Horvath wrote:
>>
>> What's wrong with:
>>
>> my_class(int something)
>>     : m_something(something)
>>     , m_something_else(nullptr)
>>     , m_init(false) {
>> }
>>
>> I think it looks nice, reads well, cuts-and-pastes well, etc.  Is there
>> something here other than personal preference?
>>
>>
> Nothing is wrong with your way, except the location of the brace (adding
> to the list requires deleting the brace).  It's just personal preference.
> I think beginning with a comma is weird, like Thiago thinks, but you may
> not feel that it's weird.  Use whichever, IMO.
>
>
> I like the way they line up.  This is the only place I use this idiom.
>> Apologies for the noise and the distasteful code!
>>
>
>>
>
> That it's the only place this idiom gets used is to me a symptom of what =
I
> see as a problem: in two other similar cases, enums and aggregate
> initializers, you don't use it.
>
> We wouldn't want to allow it for the comma operator, I would think,
> because otherwise either a new overload (unary postfix operator ,) would =
be
> required or a special rule to ignore it would be required.
>
> For function calls, it would be awkward, because it kind of looks like
> another parameter is there.  Python does allow this, though.  (Python,
> however, gives the single parameter (x,) different meaning to (x); the
> comma forces tuple/argument parsing instead of merely a parenthesized
> expression.)
>
> For function prototypes (including as part of definitions), it could be
> useful for very long argument lists that are written one per line; this i=
s
> an uncommon edge case, though.  Similar for template parameters.  (What t=
he
> heck you're doing with a template parameter list so large, I don't know >=
..<)
>
> Regarding being distasteful, it's just a visual preference.  Both are
> quite readable.  I would get a lot more distaste for not encapsulating
> classes properly or undefined behavior. =3D^-^=3D
>
> On Monday, July 27, 2015 at 6:22:33 PM UTC-7, Arthur O'Dwyer wrote:
>>
>> The actual wording change seems to be trivial:
>>
>> https://github.com/cplusplus/draft/commit/5417003045bad50705847f3d20ff72=
d78aeec32a
>>
>> I suppose a formal proposal is still required, though, since otherwise
>> there'd be no way for committee members to register opposition?
>>
>> =E2=80=93Arthur
>>
>>
> Shouldn't that have happened before committing to the draft?  Just
> curious; I'm not sure what the protocol should be.
>

This change has not been committed to the draft.

It looks like github treats all forks of a repository as being part of the
same repository internally, and you can put any of those forks into a URL,
even if the named repository doesn't contain the specified commit. The
commit is actually on the mem_initializer_list_comma branch in the
repository Quuxplusone/draft, and not in the standard's repository at all.


> By the way, I apologize for the double post.  Apparently, Google's postin=
g
> form doesn't have bounce protection--the two "clicks" were from my thumb =
on
> my phone 1/8 second part.
>
> Melissa
>
> --
>
> ---
> 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/.

--bcaec52d52ddb6ea90051be675a7
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 M=
on, Jul 27, 2015 at 7:13 PM, Myriachan <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:myriachan@gmail.com" target=3D"_blank">myriachan@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D=
"">On Monday, July 27, 2015 at 4:22:53 PM UTC-7, Christopher Horvath 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">What&#39;s wrong w=
ith:<div><br></div><div>my_class(int something)</div><div>=C2=A0 =C2=A0 : m=
_something(something)</div><div>=C2=A0 =C2=A0 , m_something_else(nullptr)</=
div><div>=C2=A0 =C2=A0 , m_init(false) {</div><div>}</div><div><br></div><d=
iv>I think it looks nice, reads well, cuts-and-pastes well, etc.=C2=A0 Is t=
here something here other than personal preference?</div></div><div><br></d=
iv></blockquote><br></span>Nothing
 is wrong with your way, except the location of the brace (adding to the
 list requires deleting the brace).=C2=A0 It&#39;s just personal preference=
..=C2=A0 I=20
think beginning with a comma is weird, like Thiago thinks, but you may not
 feel that it&#39;s weird.=C2=A0 Use whichever, IMO.<span class=3D""><br><b=
r><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex" class=3D"gmail_quote">I like the way they=
 line up.=C2=A0 This is the only place I use this idiom.=C2=A0 Apologies fo=
r the noise and the distasteful code!<br></blockquote><blockquote style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex" class=3D"gmail_quote"><div>=C2=A0</div></blockquote><br></span>That =
it&#39;s the only place this idiom gets used is to me a symptom of what I s=
ee as a problem: in two other similar cases, enums and aggregate initialize=
rs, you don&#39;t use it.<br><br>We wouldn&#39;t want to allow it for the c=
omma operator, I would think, because otherwise either a new overload (unar=
y postfix operator ,) would be required or a special rule to ignore it woul=
d be required.<br><br>For function calls, it would be awkward, because it k=
ind of looks like another parameter is there.=C2=A0 Python does allow this,=
 though.=C2=A0 (Python, however, gives the single parameter (x,) different =
meaning to (x); the comma forces tuple/argument parsing instead of merely a=
 parenthesized expression.)<br><br>For function prototypes (including as pa=
rt of definitions), it could be useful for very long argument lists that ar=
e written one per line; this is an uncommon edge case, though.=C2=A0 Simila=
r for template parameters.=C2=A0 (What the heck you&#39;re doing with a tem=
plate parameter list so large, I don&#39;t know &gt;.&lt;)<br><br>Regarding=
 being distasteful, it&#39;s just a visual preference.=C2=A0 Both are quite=
 readable.=C2=A0 I would get a lot more distaste for not encapsulating clas=
ses properly or undefined behavior. =3D^-^=3D<span class=3D""><br><br>On Mo=
nday, July 27, 2015 at 6:22:33 PM UTC-7, Arthur O&#39;Dwyer wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">The actual wording change s=
eems to be trivial:<div><a href=3D"https://github.com/cplusplus/draft/commi=
t/5417003045bad50705847f3d20ff72d78aeec32a" rel=3D"nofollow" target=3D"_bla=
nk">https://github.com/cplusplus/draft/commit/5417003045bad50705847f3d20ff7=
2d78aeec32a</a></div><div><br></div><div>I suppose a formal proposal is sti=
ll required, though, since otherwise there&#39;d be no way for committee me=
mbers to register opposition?</div><div><br></div><div>=E2=80=93Arthur<br><=
br></div></div></blockquote></span><div><br>Shouldn&#39;t that have happene=
d before committing to the draft?=C2=A0 Just curious; I&#39;m not sure what=
 the protocol should be.<br></div></div></blockquote><div><br></div><div>Th=
is change has not been committed to the draft.</div><div><br></div><div>It =
looks like github treats all forks of a repository as being part of the sam=
e repository internally, and you can put any of those forks into a URL, eve=
n if the named repository doesn&#39;t contain the specified commit. The com=
mit is actually on the mem_initializer_list_comma branch in the repository =
Quuxplusone/draft, and not in the standard&#39;s repository at all.</div><d=
iv>=C2=A0</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"><div>By the =
way, I apologize for the double post.=C2=A0 Apparently, Google&#39;s=20
posting form doesn&#39;t have bounce protection--the two &quot;clicks&quot;=
 were from=20
my thumb on my phone 1/8 second part.<br><br>Melissa<br></div></div><div cl=
ass=3D"HOEnZb"><div class=3D"h5">

<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" 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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></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 />

--bcaec52d52ddb6ea90051be675a7--

.

------=_Part_278_1901303590.1438059184072
Content-Type: multipart/alternative;
 boundary="----=_Part_279_1137208313.1438059184073"

------=_Part_279_1137208313.1438059184073
Content-Type: text/plain; charset=UTF-8

On Monday, July 27, 2015 at 7:14:12 PM UTC-7, dgutson wrote:
>
> FWIW, maybe it's irrelevant, but differentiating the last member in the
> initialization list has always been annoying when either automatic
> generating code or in X-macros.
>

It's also a pain point if there happens to be many people working on a
project potentially making additions to the list and it eventually has to
be manually resolved after otherwise unnecessary merge conflicts.

--

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

<div dir=3D"ltr">On Monday, July 27, 2015 at 7:14:12 PM UTC-7, dgutson wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">FWIW, maybe i=
t&#39;s irrelevant, but differentiating the last member in the initializati=
on list has always been annoying when either automatic generating code or i=
n X-macros.<br></p></blockquote><div><br></div><div>It&#39;s also a pain po=
int if there happens to be many people working on a project potentially mak=
ing additions to the list and it eventually has to be manually resolved aft=
er otherwise unnecessary merge conflicts.</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_279_1137208313.1438059184073--
------=_Part_278_1901303590.1438059184072--

.

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

On Mon, Jul 27, 2015 at 7:45 PM, Richard Smith <richard@metafoo.co.uk>
wrote:
> On Mon, Jul 27, 2015 at 7:13 PM, Myriachan <myriachan@gmail.com> wrote:
>>
>> That it's the only place this idiom gets used is to me a symptom of what
I
>> see as a problem: in two other similar cases, enums and aggregate
>> initializers, you don't use it.

Yep, that's the obvious argument in favor, IMO.

>> On Monday, July 27, 2015 at 6:22:33 PM UTC-7, Arthur O'Dwyer wrote:
>>>
>>>
https://github.com/cplusplus/draft/commit/5417003045bad50705847f3d20ff72d78=
aeec32a
>>>
>>> I suppose a formal proposal is still required, though, since otherwise
>>> there'd be no way for committee members to register opposition?
>>
>> Shouldn't that have happened before committing to the draft?  Just
>> curious; I'm not sure what the protocol should be.
>
> This change has not been committed to the draft.
>
> It looks like github treats all forks of a repository as being part of th=
e
> same repository internally, and you can put any of those forks into a URL=
,
> even if the named repository doesn't contain the specified commit. The
> commit is actually on the mem_initializer_list_comma branch in the
> repository Quuxplusone/draft, and not in the standard's repository at all=
..

Yes. I was surprised, myself, to notice that I'd posted what looks like a
link into the official repo! Indeed, it *really* points into my own fork of
the repo. My question still stands, though: would this require
- a whole proposal, with N1234 number and all?
- an informal motion of some sort at Kona?
- a pull request against cplusplus/draft?
(Listed in order of decreasing formality and decreasing likelihood. ;))

Thanks,
=E2=80=93Arthur

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

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

<div dir=3D"ltr">On Mon, Jul 27, 2015 at 7:45 PM, Richard Smith &lt;<a href=
=3D"mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>&gt; wrote:<br>&=
gt; On Mon, Jul 27, 2015 at 7:13 PM, Myriachan &lt;<a href=3D"mailto:myriac=
han@gmail.com">myriachan@gmail.com</a>&gt; wrote:<br>&gt;&gt;<br>&gt;&gt; T=
hat it&#39;s the only place this idiom gets used is to me a symptom of what=
 I<br>&gt;&gt; see as a problem: in two other similar cases, enums and aggr=
egate<br>&gt;&gt; initializers, you don&#39;t use it.<br><br><div>Yep, that=
&#39;s the obvious argument in favor, IMO.</div><div><br></div><div>&gt;&gt=
; On Monday, July 27, 2015 at 6:22:33 PM UTC-7, Arthur O&#39;Dwyer wrote:<b=
r>&gt;&gt;&gt;<br>&gt;&gt;&gt; <a href=3D"https://github.com/cplusplus/draf=
t/commit/5417003045bad50705847f3d20ff72d78aeec32a">https://github.com/cplus=
plus/draft/commit/5417003045bad50705847f3d20ff72d78aeec32a</a><br>&gt;&gt;&=
gt;<br>&gt;&gt;&gt; I suppose a formal proposal is still required, though, =
since otherwise<br>&gt;&gt;&gt; there&#39;d be no way for committee members=
 to register opposition?<br>&gt;&gt;<br>&gt;&gt; Shouldn&#39;t that have ha=
ppened before committing to the draft?=C2=A0 Just<br>&gt;&gt; curious; I&#3=
9;m not sure what the protocol should be.<br>&gt;<br>&gt; This change has n=
ot been committed to the draft.<br>&gt;<br>&gt; It looks like github treats=
 all forks of a repository as being part of the<br>&gt; same repository int=
ernally, and you can put any of those forks into a URL,<br>&gt; even if the=
 named repository doesn&#39;t contain the specified commit. The<br>&gt; com=
mit is actually on the mem_initializer_list_comma branch in the<br>&gt; rep=
ository Quuxplusone/draft, and not in the standard&#39;s repository at all.=
<br><br></div><div>Yes. I was surprised, myself, to notice that I&#39;d pos=
ted what looks like a link into the official repo! Indeed, it <i>really</i>=
 points into my own fork of the repo. My question still stands, though: wou=
ld this require</div><div>- a whole proposal, with N1234 number and all?</d=
iv><div>- an informal motion of some sort at Kona?</div><div>- a pull reque=
st against cplusplus/draft?</div><div>(Listed in order of decreasing formal=
ity and decreasing likelihood. ;))</div><div><br></div><div>Thanks,</div><d=
iv>=E2=80=93Arthur</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 />

--047d7b472548c4d0df051be97d49--

.

On 2015-07-28 08:22, Arthur O'Dwyer wrote:
> On Mon, Jul 27, 2015 at 7:45 PM, Richard Smith <richard@metafoo.co.uk
> <mailto:richard@metafoo.co.uk>> wrote:
>  > On Mon, Jul 27, 2015 at 7:13 PM, Myriachan <myriachan@gmail.com
> <mailto:myriachan@gmail.com>> wrote:
>  >>
>  >> That it's the only place this idiom gets used is to me a symptom of
> what I
>  >> see as a problem: in two other similar cases, enums and aggregate
>  >> initializers, you don't use it.
>
> Yep, that's the obvious argument in favor, IMO.
>
>  >> On Monday, July 27, 2015 at 6:22:33 PM UTC-7, Arthur O'Dwyer wrote:
>  >>>
>  >>>
> https://github.com/cplusplus/draft/commit/5417003045bad50705847f3d20ff72d78aeec32a
>  >>>
>  >>> I suppose a formal proposal is still required, though, since otherwise
>  >>> there'd be no way for committee members to register opposition?
>  >>
>  >> Shouldn't that have happened before committing to the draft?  Just
>  >> curious; I'm not sure what the protocol should be.
>  >
>  > This change has not been committed to the draft.
>  >
>  > It looks like github treats all forks of a repository as being part
> of the
>  > same repository internally, and you can put any of those forks into a
> URL,
>  > even if the named repository doesn't contain the specified commit. The
>  > commit is actually on the mem_initializer_list_comma branch in the
>  > repository Quuxplusone/draft, and not in the standard's repository at
> all.
>
> Yes. I was surprised, myself, to notice that I'd posted what looks like
> a link into the official repo! Indeed, it /really/ points into my own
> fork of the repo. My question still stands, though: would this require
> - a whole proposal, with N1234 number and all?
> - an informal motion of some sort at Kona?
> - a pull request against cplusplus/draft?
> (Listed in order of decreasing formality and decreasing likelihood. ;))
>

This being a language change, the committee would probably like a formal
paper discussing the pros and cons. Like if this code

my_class(int something)
     : m_something(something), m_something_else(nullptr),
{ }

should still be accepted, or if I just forgot the third initializer.
Perhaps my phone rang at that point?


A pull request by itself is only for "editorial changes", where the
editor can accept obvious small fixes for formatting, typos or any
misapplied earlier changes.



Bo Persson


--

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

.

I genuinely cannot believe what I'm reading in this discussion.
Do C++ really has no other *bigger* problems to solve, that we can
discuss if comma should be allowed at the end of constructor's
initializer list, because some one has preferences towards it?
Seriously?

On 7/28/15, Bo Persson <bop@gmb.dk> wrote:
> On 2015-07-28 08:22, Arthur O'Dwyer wrote:
>> On Mon, Jul 27, 2015 at 7:45 PM, Richard Smith <richard@metafoo.co.uk
>> <mailto:richard@metafoo.co.uk>> wrote:
>>  > On Mon, Jul 27, 2015 at 7:13 PM, Myriachan <myriachan@gmail.com
>> <mailto:myriachan@gmail.com>> wrote:
>>  >>
>>  >> That it's the only place this idiom gets used is to me a symptom of
>> what I
>>  >> see as a problem: in two other similar cases, enums and aggregate
>>  >> initializers, you don't use it.
>>
>> Yep, that's the obvious argument in favor, IMO.
>>
>>  >> On Monday, July 27, 2015 at 6:22:33 PM UTC-7, Arthur O'Dwyer wrote:
>>  >>>
>>  >>>
>> https://github.com/cplusplus/draft/commit/5417003045bad50705847f3d20ff72d78aeec32a
>>  >>>
>>  >>> I suppose a formal proposal is still required, though, since
>> otherwise
>>  >>> there'd be no way for committee members to register opposition?
>>  >>
>>  >> Shouldn't that have happened before committing to the draft?  Just
>>  >> curious; I'm not sure what the protocol should be.
>>  >
>>  > This change has not been committed to the draft.
>>  >
>>  > It looks like github treats all forks of a repository as being part
>> of the
>>  > same repository internally, and you can put any of those forks into a
>> URL,
>>  > even if the named repository doesn't contain the specified commit. The
>>  > commit is actually on the mem_initializer_list_comma branch in the
>>  > repository Quuxplusone/draft, and not in the standard's repository at
>> all.
>>
>> Yes. I was surprised, myself, to notice that I'd posted what looks like
>> a link into the official repo! Indeed, it /really/ points into my own
>> fork of the repo. My question still stands, though: would this require
>> - a whole proposal, with N1234 number and all?
>> - an informal motion of some sort at Kona?
>> - a pull request against cplusplus/draft?
>> (Listed in order of decreasing formality and decreasing likelihood. ;))
>>
>
> This being a language change, the committee would probably like a formal
> paper discussing the pros and cons. Like if this code
>
> my_class(int something)
>      : m_something(something), m_something_else(nullptr),
> { }
>
> should still be accepted, or if I just forgot the third initializer.
> Perhaps my phone rang at that point?
>
>
> A pull request by itself is only for "editorial changes", where the
> editor can accept obvious small fixes for formatting, typos or any
> misapplied earlier changes.
>
>
>
> Bo Persson
>
>
> --
>
> ---
> 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/.
>


--
Yours sincerely
Artur Czajkowski

--

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

.

And it simply look weird having a comma and nothing following it. It
looks like there is something missing.

On 7/28/15, Arthur Tchaikovsky <atch.cpp@gmail.com> wrote:
> I genuinely cannot believe what I'm reading in this discussion.
> Do C++ really has no other *bigger* problems to solve, that we can
> discuss if comma should be allowed at the end of constructor's
> initializer list, because some one has preferences towards it?
> Seriously?
>
> On 7/28/15, Bo Persson <bop@gmb.dk> wrote:
>> On 2015-07-28 08:22, Arthur O'Dwyer wrote:
>>> On Mon, Jul 27, 2015 at 7:45 PM, Richard Smith <richard@metafoo.co.uk
>>> <mailto:richard@metafoo.co.uk>> wrote:
>>>  > On Mon, Jul 27, 2015 at 7:13 PM, Myriachan <myriachan@gmail.com
>>> <mailto:myriachan@gmail.com>> wrote:
>>>  >>
>>>  >> That it's the only place this idiom gets used is to me a symptom of
>>> what I
>>>  >> see as a problem: in two other similar cases, enums and aggregate
>>>  >> initializers, you don't use it.
>>>
>>> Yep, that's the obvious argument in favor, IMO.
>>>
>>>  >> On Monday, July 27, 2015 at 6:22:33 PM UTC-7, Arthur O'Dwyer wrote:
>>>  >>>
>>>  >>>
>>> https://github.com/cplusplus/draft/commit/5417003045bad50705847f3d20ff72d78aeec32a
>>>  >>>
>>>  >>> I suppose a formal proposal is still required, though, since
>>> otherwise
>>>  >>> there'd be no way for committee members to register opposition?
>>>  >>
>>>  >> Shouldn't that have happened before committing to the draft?  Just
>>>  >> curious; I'm not sure what the protocol should be.
>>>  >
>>>  > This change has not been committed to the draft.
>>>  >
>>>  > It looks like github treats all forks of a repository as being part
>>> of the
>>>  > same repository internally, and you can put any of those forks into a
>>> URL,
>>>  > even if the named repository doesn't contain the specified commit.
>>> The
>>>  > commit is actually on the mem_initializer_list_comma branch in the
>>>  > repository Quuxplusone/draft, and not in the standard's repository at
>>> all.
>>>
>>> Yes. I was surprised, myself, to notice that I'd posted what looks like
>>> a link into the official repo! Indeed, it /really/ points into my own
>>> fork of the repo. My question still stands, though: would this require
>>> - a whole proposal, with N1234 number and all?
>>> - an informal motion of some sort at Kona?
>>> - a pull request against cplusplus/draft?
>>> (Listed in order of decreasing formality and decreasing likelihood. ;))
>>>
>>
>> This being a language change, the committee would probably like a formal
>> paper discussing the pros and cons. Like if this code
>>
>> my_class(int something)
>>      : m_something(something), m_something_else(nullptr),
>> { }
>>
>> should still be accepted, or if I just forgot the third initializer.
>> Perhaps my phone rang at that point?
>>
>>
>> A pull request by itself is only for "editorial changes", where the
>> editor can accept obvious small fixes for formatting, typos or any
>> misapplied earlier changes.
>>
>>
>>
>> Bo Persson
>>
>>
>> --
>>
>> ---
>> 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/.
>>
>
>
> --
> Yours sincerely
> Artur Czajkowski
>


--
Yours sincerely
Artur Czajkowski

--

---
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=E2=80=9307=E2=80=9328, at 8:37 PM, Arthur Tchaikovsky <atch.cpp@g=
mail.com> wrote:
>=20
> I genuinely cannot believe what I'm reading in this discussion.
> Do C++ really has no other *bigger* problems to solve, that we can
> discuss if comma should be allowed at the end of constructor's
> initializer list, because some one has preferences towards it?
> Seriously?

Maybe there are a lot of people sharing this preference.

Regardless of the number of messages in this thread, the committee effort s=
hould be low. It should be a small proposal, a brief meeting discussion, an=
d a minor change to the normative grammar spec.

--=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_314_678701276.1438087367454
Content-Type: multipart/alternative;
 boundary="----=_Part_315_2053028303.1438087367454"

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



On Tuesday, 28 July 2015 03:13:47 UTC+1, Myriachan wrote:
>
>  I think beginning with a comma is weird, like Thiago thinks, but you may=
=20
> not feel that it's weird.  Use whichever, IMO.
>
> I think ending with comma is even weirder.
=20

>
> I like the way they line up.  This is the only place I use this idiom. =
=20
>> Apologies for the noise and the distasteful code!
>>
> =20
>>
>
> That it's the only place this idiom gets used is to me a symptom of what =
I=20
> see as a problem: in two other similar cases, enums and aggregate=20
> initializers, you don't use it.
>
> We wouldn't want to allow it for the comma operator, I would think,=20
> because otherwise either a new overload (unary postfix operator ,) would =
be=20
> required or a special rule to ignore it would be required.
>
> For function calls, it would be awkward, because it kind of looks like=20
> another parameter is there.  Python does allow this, though.  (Python,=20
> however, gives the single parameter (x,) different meaning to (x); the=20
> comma forces tuple/argument parsing instead of merely a parenthesized=20
> expression.)
>
> For function prototypes (including as part of definitions), it could be=
=20
> useful for very long argument lists that are written one per line; this i=
s=20
> an uncommon edge case, though.  Similar for template parameters.  (What t=
he=20
> heck you're doing with a template parameter list so large, I don't know >=
..<)
>
> Regarding being distasteful, it's just a visual preference.  Both are=20
> quite readable.  I would get a lot more distaste for not encapsulating=20
> classes properly or undefined behavior. =3D^-^=3D
>
> On Monday, July 27, 2015 at 6:22:33 PM UTC-7, Arthur O'Dwyer wrote:
>>
>> The actual wording change seems to be trivial:
>>
>> https://github.com/cplusplus/draft/commit/5417003045bad50705847f3d20ff72=
d78aeec32a
>>
>> I suppose a formal proposal is still required, though, since otherwise=
=20
>> there'd be no way for committee members to register opposition?
>>
>> =E2=80=93Arthur
>>
>>
> Shouldn't that have happened before committing to the draft?  Just=20
> curious; I'm not sure what the protocol should be.
>
> By the way, I apologize for the double post.  Apparently, Google's postin=
g=20
> form doesn't have bounce protection--the two "clicks" were from my thumb =
on=20
> my phone 1/8 second part.
>
> Melissa
>

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

<div dir=3D"ltr"><br><br>On Tuesday, 28 July 2015 03:13:47 UTC+1, Myriachan=
  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">=C2=
=A0I=20
think beginning with a comma is weird, like Thiago thinks, but you may not
 feel that it&#39;s weird.=C2=A0 Use whichever, IMO.<br><br></div></blockqu=
ote><div>I think ending with comma is even weirder.<br>=C2=A0</div><blockqu=
ote 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><blockquote style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex" class=3D"gmail_quote">I like the way they line up.=C2=A0 This is=
 the only place I use this idiom.=C2=A0 Apologies for the noise and the dis=
tasteful code!<br></blockquote><blockquote style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_q=
uote"><div>=C2=A0</div></blockquote><br>That it&#39;s the only place this i=
diom gets used is to me a symptom of what I see as a problem: in two other =
similar cases, enums and aggregate initializers, you don&#39;t use it.<br><=
br>We wouldn&#39;t want to allow it for the comma operator, I would think, =
because otherwise either a new overload (unary postfix operator ,) would be=
 required or a special rule to ignore it would be required.<br><br>For func=
tion calls, it would be awkward, because it kind of looks like another para=
meter is there.=C2=A0 Python does allow this, though.=C2=A0 (Python, howeve=
r, gives the single parameter (x,) different meaning to (x); the comma forc=
es tuple/argument parsing instead of merely a parenthesized expression.)<br=
><br>For function prototypes (including as part of definitions), it could b=
e useful for very long argument lists that are written one per line; this i=
s an uncommon edge case, though.=C2=A0 Similar for template parameters.=C2=
=A0 (What the heck you&#39;re doing with a template parameter list so large=
, I don&#39;t know &gt;.&lt;)<br><br>Regarding being distasteful, it&#39;s =
just a visual preference.=C2=A0 Both are quite readable.=C2=A0 I would get =
a lot more distaste for not encapsulating classes properly or undefined beh=
avior. =3D^-^=3D<br><br>On Monday, July 27, 2015 at 6:22:33 PM UTC-7, Arthu=
r O&#39;Dwyer 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=
">The actual wording change seems to be trivial:<div><a href=3D"https://git=
hub.com/cplusplus/draft/commit/5417003045bad50705847f3d20ff72d78aeec32a" re=
l=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;https://ww=
w.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fcplusplus%2Fdraft%2Fcommit%=
2F5417003045bad50705847f3d20ff72d78aeec32a\46sa\75D\46sntz\0751\46usg\75AFQ=
jCNFsBeyQ09JpN4au_A02ZL3CY3w-cg&#39;;return true;" onclick=3D"this.href=3D&=
#39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fcplusplus%2Fd=
raft%2Fcommit%2F5417003045bad50705847f3d20ff72d78aeec32a\46sa\75D\46sntz\07=
51\46usg\75AFQjCNFsBeyQ09JpN4au_A02ZL3CY3w-cg&#39;;return true;">https://gi=
thub.com/cplusplus/draft/commit/5417003045bad50705847f3d20ff72d78aeec32a</a=
></div><div><br></div><div>I suppose a formal proposal is still required, t=
hough, since otherwise there&#39;d be no way for committee members to regis=
ter opposition?</div><div><br></div><div>=E2=80=93Arthur<br><br></div></div=
></blockquote><div><br>Shouldn&#39;t that have happened before committing t=
o the draft?=C2=A0 Just curious; I&#39;m not sure what the protocol should =
be.<br><br>By the way, I apologize for the double post.=C2=A0 Apparently, G=
oogle&#39;s=20
posting form doesn&#39;t have bounce protection--the two &quot;clicks&quot;=
 were from=20
my thumb on my phone 1/8 second part.<br><br>Melissa<br></div></div></block=
quote></div>

<p></p>

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

------=_Part_315_2053028303.1438087367454--
------=_Part_314_678701276.1438087367454--

.

------=_Part_4170_1624975343.1438088141533
Content-Type: multipart/alternative;
 boundary="----=_Part_4171_208220346.1438088141534"

------=_Part_4171_208220346.1438088141534
Content-Type: text/plain; charset=UTF-8

I find it unproductive to discuss where to allow or disallow trailing comma
based on formatting styles, but otherwise it's a small but genuine problem.
I like how they resolved it in Rust - trailing separators are consistently
allowed in *all *list contexts, thus making any macro or code generation
work simpler + no bikeshedding about every particular case, as a bonus.

On Tuesday, July 28, 2015 at 3:37:18 PM UTC+3, Arthur Tchaikovsky wrote:
>
> I genuinely cannot believe what I'm reading in this discussion.
> Do C++ really has no other *bigger* problems to solve, that we can
> discuss if comma should be allowed at the end of constructor's
> initializer list, because some one has preferences towards it?
> Seriously?
>
> On 7/28/15, Bo Persson <b...@gmb.dk <javascript:>> wrote:
> > On 2015-07-28 08:22, Arthur O'Dwyer wrote:
> >> On Mon, Jul 27, 2015 at 7:45 PM, Richard Smith <ric...@metafoo.co.uk
> <javascript:>
> >> <mailto:ric...@metafoo.co.uk <javascript:>>> wrote:
> >>  > On Mon, Jul 27, 2015 at 7:13 PM, Myriachan <myri...@gmail.com
> <javascript:>
> >> <mailto:myri...@gmail.com <javascript:>>> wrote:
> >>  >>
> >>  >> That it's the only place this idiom gets used is to me a symptom of
> >> what I
> >>  >> see as a problem: in two other similar cases, enums and aggregate
> >>  >> initializers, you don't use it.
> >>
> >> Yep, that's the obvious argument in favor, IMO.
> >>
> >>  >> On Monday, July 27, 2015 at 6:22:33 PM UTC-7, Arthur O'Dwyer wrote:
> >>  >>>
> >>  >>>
> >>
> https://github.com/cplusplus/draft/commit/5417003045bad50705847f3d20ff72d78aeec32a
> >>  >>>
> >>  >>> I suppose a formal proposal is still required, though, since
> >> otherwise
> >>  >>> there'd be no way for committee members to register opposition?
> >>  >>
> >>  >> Shouldn't that have happened before committing to the draft?  Just
> >>  >> curious; I'm not sure what the protocol should be.
> >>  >
> >>  > This change has not been committed to the draft.
> >>  >
> >>  > It looks like github treats all forks of a repository as being part
> >> of the
> >>  > same repository internally, and you can put any of those forks into
> a
> >> URL,
> >>  > even if the named repository doesn't contain the specified commit.
> The
> >>  > commit is actually on the mem_initializer_list_comma branch in the
> >>  > repository Quuxplusone/draft, and not in the standard's repository
> at
> >> all.
> >>
> >> Yes. I was surprised, myself, to notice that I'd posted what looks like
> >> a link into the official repo! Indeed, it /really/ points into my own
> >> fork of the repo. My question still stands, though: would this require
> >> - a whole proposal, with N1234 number and all?
> >> - an informal motion of some sort at Kona?
> >> - a pull request against cplusplus/draft?
> >> (Listed in order of decreasing formality and decreasing likelihood. ;))
> >>
> >
> > This being a language change, the committee would probably like a formal
> > paper discussing the pros and cons. Like if this code
> >
> > my_class(int something)
> >      : m_something(something), m_something_else(nullptr),
> > { }
> >
> > should still be accepted, or if I just forgot the third initializer.
> > Perhaps my phone rang at that point?
> >
> >
> > A pull request by itself is only for "editorial changes", where the
> > editor can accept obvious small fixes for formatting, typos or any
> > misapplied earlier changes.
> >
> >
> >
> > Bo Persson
> >
> >
> > --
> >
> > ---
> > 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-proposal...@isocpp.org <javascript:>.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>
> > Visit this group at
> > http://groups.google.com/a/isocpp.org/group/std-proposals/.
> >
>
>
> --
> Yours sincerely
> Artur Czajkowski
>

--

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

<div dir=3D"ltr">I find it unproductive to discuss where to allow or disall=
ow trailing comma based on formatting styles, but otherwise it&#39;s a smal=
l but genuine problem.<div>I like how they resolved it in Rust - trailing s=
eparators are consistently allowed in <i>all </i>list contexts, thus making=
 any macro or code generation work simpler + no bikeshedding about every pa=
rticular case, as a bonus.<br><br>On Tuesday, July 28, 2015 at 3:37:18 PM U=
TC+3, Arthur Tchaikovsky wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>I genuinely cannot believe what I&#39;m reading in this discussion.
<br>Do C++ really has no other *bigger* problems to solve, that we can
<br>discuss if comma should be allowed at the end of constructor&#39;s
<br>initializer list, because some one has preferences towards it?
<br>Seriously?
<br>
<br>On 7/28/15, Bo Persson &lt;<a href=3D"javascript:" target=3D"_blank" re=
l=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true=
;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">b...@gmb.dk</=
a>&gt; wrote:
<br>&gt; On 2015-07-28 08:22, Arthur O&#39;Dwyer wrote:
<br>&gt;&gt; On Mon, Jul 27, 2015 at 7:45 PM, Richard Smith &lt;<a href=3D"=
javascript:" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D=
&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:=
&#39;;return true;">ric...@metafoo.co.uk</a>
<br>&gt;&gt; &lt;mailto:<a href=3D"javascript:" target=3D"_blank" rel=3D"no=
follow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" oncl=
ick=3D"this.href=3D&#39;javascript:&#39;;return true;">ric...@metafoo.co.uk=
</a>&gt;&gt; wrote:
<br>&gt;&gt; =C2=A0&gt; On Mon, Jul 27, 2015 at 7:13 PM, Myriachan &lt;<a h=
ref=3D"javascript:" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.=
href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;java=
script:&#39;;return true;">myri...@gmail.com</a>
<br>&gt;&gt; &lt;mailto:<a href=3D"javascript:" target=3D"_blank" rel=3D"no=
follow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" oncl=
ick=3D"this.href=3D&#39;javascript:&#39;;return true;">myri...@gmail.com</a=
>&gt;&gt; wrote:
<br>&gt;&gt; =C2=A0&gt;&gt;
<br>&gt;&gt; =C2=A0&gt;&gt; That it&#39;s the only place this idiom gets us=
ed is to me a symptom of
<br>&gt;&gt; what I
<br>&gt;&gt; =C2=A0&gt;&gt; see as a problem: in two other similar cases, e=
nums and aggregate
<br>&gt;&gt; =C2=A0&gt;&gt; initializers, you don&#39;t use it.
<br>&gt;&gt;
<br>&gt;&gt; Yep, that&#39;s the obvious argument in favor, IMO.
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0&gt;&gt; On Monday, July 27, 2015 at 6:22:33 PM UTC-7, A=
rthur O&#39;Dwyer wrote:
<br>&gt;&gt; =C2=A0&gt;&gt;&gt;
<br>&gt;&gt; =C2=A0&gt;&gt;&gt;
<br>&gt;&gt; <a href=3D"https://github.com/cplusplus/draft/commit/541700304=
5bad50705847f3d20ff72d78aeec32a" target=3D"_blank" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fgithu=
b.com%2Fcplusplus%2Fdraft%2Fcommit%2F5417003045bad50705847f3d20ff72d78aeec3=
2a\46sa\75D\46sntz\0751\46usg\75AFQjCNFsBeyQ09JpN4au_A02ZL3CY3w-cg&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\75https=
%3A%2F%2Fgithub.com%2Fcplusplus%2Fdraft%2Fcommit%2F5417003045bad50705847f3d=
20ff72d78aeec32a\46sa\75D\46sntz\0751\46usg\75AFQjCNFsBeyQ09JpN4au_A02ZL3CY=
3w-cg&#39;;return true;">https://github.com/cplusplus/draft/commit/54170030=
45bad50705847f3d20ff72d78aeec32a</a>
<br>&gt;&gt; =C2=A0&gt;&gt;&gt;
<br>&gt;&gt; =C2=A0&gt;&gt;&gt; I suppose a formal proposal is still requir=
ed, though, since
<br>&gt;&gt; otherwise
<br>&gt;&gt; =C2=A0&gt;&gt;&gt; there&#39;d be no way for committee members=
 to register opposition?
<br>&gt;&gt; =C2=A0&gt;&gt;
<br>&gt;&gt; =C2=A0&gt;&gt; Shouldn&#39;t that have happened before committ=
ing to the draft? =C2=A0Just
<br>&gt;&gt; =C2=A0&gt;&gt; curious; I&#39;m not sure what the protocol sho=
uld be.
<br>&gt;&gt; =C2=A0&gt;
<br>&gt;&gt; =C2=A0&gt; This change has not been committed to the draft.
<br>&gt;&gt; =C2=A0&gt;
<br>&gt;&gt; =C2=A0&gt; It looks like github treats all forks of a reposito=
ry as being part
<br>&gt;&gt; of the
<br>&gt;&gt; =C2=A0&gt; same repository internally, and you can put any of =
those forks into a
<br>&gt;&gt; URL,
<br>&gt;&gt; =C2=A0&gt; even if the named repository doesn&#39;t contain th=
e specified commit. The
<br>&gt;&gt; =C2=A0&gt; commit is actually on the mem_initializer_list_comm=
a branch in the
<br>&gt;&gt; =C2=A0&gt; repository Quuxplusone/draft, and not in the standa=
rd&#39;s repository at
<br>&gt;&gt; all.
<br>&gt;&gt;
<br>&gt;&gt; Yes. I was surprised, myself, to notice that I&#39;d posted wh=
at looks like
<br>&gt;&gt; a link into the official repo! Indeed, it /really/ points into=
 my own
<br>&gt;&gt; fork of the repo. My question still stands, though: would this=
 require
<br>&gt;&gt; - a whole proposal, with N1234 number and all?
<br>&gt;&gt; - an informal motion of some sort at Kona?
<br>&gt;&gt; - a pull request against cplusplus/draft?
<br>&gt;&gt; (Listed in order of decreasing formality and decreasing likeli=
hood. ;))
<br>&gt;&gt;
<br>&gt;
<br>&gt; This being a language change, the committee would probably like a =
formal
<br>&gt; paper discussing the pros and cons. Like if this code
<br>&gt;
<br>&gt; my_class(int something)
<br>&gt; =C2=A0 =C2=A0 =C2=A0: m_something(something), m_something_else(nul=
lptr),
<br>&gt; { }
<br>&gt;
<br>&gt; should still be accepted, or if I just forgot the third initialize=
r.
<br>&gt; Perhaps my phone rang at that point?
<br>&gt;
<br>&gt;
<br>&gt; A pull request by itself is only for &quot;editorial changes&quot;=
, where the
<br>&gt; editor can accept obvious small fixes for formatting, typos or any
<br>&gt; misapplied earlier changes.
<br>&gt;
<br>&gt;
<br>&gt;
<br>&gt; Bo Persson
<br>&gt;
<br>&gt;
<br>&gt; --
<br>&gt;
<br>&gt; ---
<br>&gt; You received this message because you are subscribed to the Google=
 Groups
<br>&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an
<br>&gt; email to <a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow=
" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D=
"this.href=3D&#39;javascript:&#39;;return true;">std-proposal...@isocpp.org=
</a>.
<br>&gt; To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#=
39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;=
">std-pr...@isocpp.org</a>.
<br>&gt; Visit this group at
<br>&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;htt=
p://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;return true;" =
onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.org/group/std=
-proposals/&#39;;return true;">http://groups.google.com/a/isocpp.org/group/=
std-proposals/</a>.
<br>&gt;
<br>
<br>
<br>--=20
<br>Yours sincerely
<br>Artur Czajkowski
<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_4171_208220346.1438088141534--
------=_Part_4170_1624975343.1438088141533--

.

On 28 July 2015 at 15:41, David Krauss <potswa@gmail.com> wrote:
> Regardless of the number of messages in this thread, the committee effort should be low. It should be a small proposal, a brief meeting discussion, and a minor change to the normative grammar spec.

And then wait for every implementation on the planet to implement this
change, and
every other tool that desperately tries to grok C++ code. The overall
effort is anything
but low, so the question is whether the benefit is worth the effort.
Thus far the rationale
provided doesn't convince me.

--

---
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_4136_2084164160.1438089877712
Content-Type: multipart/alternative;
 boundary="----=_Part_4137_1951018531.1438089877712"

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

@David Krauss
That's assumption. Can you provide empirical data? Otherwise, assumptions,=
=20
personal preferences, bike sheds etc.

On Tuesday, 28 July 2015 13:41:32 UTC+1, David Krauss wrote:
>
>
> > On 2015=E2=80=9307=E2=80=9328, at 8:37 PM, Arthur Tchaikovsky <atch...@=
gmail.com=20
> <javascript:>> wrote:=20
> >=20
> > I genuinely cannot believe what I'm reading in this discussion.=20
> > Do C++ really has no other *bigger* problems to solve, that we can=20
> > discuss if comma should be allowed at the end of constructor's=20
> > initializer list, because some one has preferences towards it?=20
> > Seriously?=20
>
> Maybe there are a lot of people sharing this preference.=20
>
> Regardless of the number of messages in this thread, the committee effort=
=20
> should be low. It should be a small proposal, a brief meeting discussion,=
=20
> and a minor change to the normative grammar spec.=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_4137_1951018531.1438089877712
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">@David Krauss<br>That&#39;s assumption. Can you provide em=
pirical data? Otherwise, assumptions, personal preferences, bike sheds etc.=
<br><br>On Tuesday, 28 July 2015 13:41:32 UTC+1, David Krauss  wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; On 2015=E2=80=9307=E2=80=9328, at 8:37 PM, Arthur Tchaikovsky &lt;=
<a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;=
javascript:&#39;;return true;">atch...@gmail.com</a>&gt; wrote:
<br>&gt;=20
<br>&gt; I genuinely cannot believe what I&#39;m reading in this discussion=
..
<br>&gt; Do C++ really has no other *bigger* problems to solve, that we can
<br>&gt; discuss if comma should be allowed at the end of constructor&#39;s
<br>&gt; initializer list, because some one has preferences towards it?
<br>&gt; Seriously?
<br>
<br>Maybe there are a lot of people sharing this preference.
<br>
<br>Regardless of the number of messages in this thread, the committee effo=
rt should be low. It should be a small proposal, a brief meeting discussion=
, and a minor change to the normative grammar spec.
<br>
<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 />

------=_Part_4137_1951018531.1438089877712--
------=_Part_4136_2084164160.1438089877712--

.

------=_Part_456_190795677.1438090099164
Content-Type: multipart/alternative;
 boundary="----=_Part_457_1796179509.1438090099164"

------=_Part_457_1796179509.1438090099164
Content-Type: text/plain; charset=UTF-8

The same can be said about every DR resolution - they are usually small,
not very practically significant, but still have to be implemented by
everyone.
Irrespectively to this particular proposal, these kinds of arguments are
usually applied selectively (based on my experience of reading this list)
and look like warding off work.
(Sorry for meta.)

On Tuesday, July 28, 2015 at 4:00:39 PM UTC+3, Ville Voutilainen wrote:
>
> On 28 July 2015 at 15:41, David Krauss <pot...@gmail.com <javascript:>>
> wrote:
> > Regardless of the number of messages in this thread, the committee
> effort should be low. It should be a small proposal, a brief meeting
> discussion, and a minor change to the normative grammar spec.
>
> And then wait for every implementation on the planet to implement this
> change, and
> every other tool that desperately tries to grok C++ code. The overall
> effort is anything
> but low, so the question is whether the benefit is worth the effort.
> Thus far the rationale
> provided doesn't convince me.
>

--

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

<div dir=3D"ltr">The same can be said about every DR resolution - they are =
usually small, not very practically significant, but still have to be imple=
mented by everyone.<div>Irrespectively to this particular proposal, these k=
inds of arguments are usually applied selectively (based on my experience o=
f reading this list) and look like warding off work.=C2=A0</div><div>(Sorry=
 for meta.)<br><br>On Tuesday, July 28, 2015 at 4:00:39 PM UTC+3, Ville Vou=
tilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 28 July 2015=
 at 15:41, David Krauss &lt;<a href=3D"javascript:" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;=
" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">pot...@gmail.c=
om</a>&gt; wrote:
<br>&gt; Regardless of the number of messages in this thread, the committee=
 effort should be low. It should be a small proposal, a brief meeting discu=
ssion, and a minor change to the normative grammar spec.
<br>
<br>And then wait for every implementation on the planet to implement this
<br>change, and
<br>every other tool that desperately tries to grok C++ code. The overall
<br>effort is anything
<br>but low, so the question is whether the benefit is worth the effort.
<br>Thus far the rationale
<br>provided doesn&#39;t convince me.
<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_457_1796179509.1438090099164--
------=_Part_456_190795677.1438090099164--

.

On 28 July 2015 at 16:28, Vadim Petrochenkov
<vadim.petrochenkov@gmail.com> wrote:
> The same can be said about every DR resolution - they are usually small, not
> very practically significant, but still have to be implemented by everyone.

I daresay I disagree with the claim that DR resolutions are usually
not practically
significant, compared to this particular idea.

> Irrespectively to this particular proposal, these kinds of arguments are
> usually applied selectively (based on my experience of reading this list)
> and look like warding off work.
> (Sorry for meta.)

In this case, I'll call it warding off useless nonsense, rather than
warding off work.

--

---
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-07-28 09:00, Ville Voutilainen wrote:
> And then wait for every implementation on the planet to implement
> this change, and every other tool that desperately tries to grok C++
> code.

IMHO that ship has sailed... anyone - besides compiler authors - trying
to parse modern C++ by themselves is just insane. Use clang. Just C++11
is infernally complicated, and as you note, trying to keep up with
changes is near impossible. Much better to use a full compiler to do the
parsing for you and work with the resulting AST than try to write your
own parser.

(Incidentally, I'd be in favor of the change; as others have indicated,
this makes it really obnoxious and unnecessarily difficult to make VCS
edits of initializer lists, and is inconsistent with enums and
aggregates which allow the trailing comma.)

--
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 28 July 2015 at 17:05, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> On 2015-07-28 09:00, Ville Voutilainen wrote:
>> And then wait for every implementation on the planet to implement
>> this change, and every other tool that desperately tries to grok C++
>> code.
>
> IMHO that ship has sailed... anyone - besides compiler authors - trying
> to parse modern C++ by themselves is just insane. Use clang. Just C++11
> is infernally complicated, and as you note, trying to keep up with
> changes is near impossible. Much better to use a full compiler to do the
> parsing for you and work with the resulting AST than try to write your
> own parser.

So let's just break every working parser, good or not, in order to
provide a nice-to-have feature to make 'git/svn/whatever blame' prettier?
I don't find that a convincing argument. Same goes for macros.

> (Incidentally, I'd be in favor of the change; as others have indicated,
> this makes it really obnoxious and unnecessarily difficult to make VCS
> edits of initializer lists, and is inconsistent with enums and
> aggregates which allow the trailing comma.)

I fail to agree with the "obnoxious and unnecessarily difficult" part.
The consistency
argument sounds remotely plausible.

I guess Richard should take the idea to Core, if he thinks it's
viable. I can't imagine
my supporting this idea.

--

---
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-07-28 16:05, Matthew Woehlke wrote:
> On 2015-07-28 09:00, Ville Voutilainen wrote:
>> And then wait for every implementation on the planet to implement
>> this change, and every other tool that desperately tries to grok C++
>> code.
>
> IMHO that ship has sailed... anyone - besides compiler authors - trying
> to parse modern C++ by themselves is just insane. Use clang. Just C++11
> is infernally complicated, and as you note, trying to keep up with
> changes is near impossible. Much better to use a full compiler to do the
> parsing for you and work with the resulting AST than try to write your
> own parser.
>
> (Incidentally, I'd be in favor of the change; as others have indicated,
> this makes it really obnoxious and unnecessarily difficult to make VCS
> edits of initializer lists, and is inconsistent with enums and
> aggregates which allow the trailing comma.)
>

But it IS consistent with other comma separated items, like parameters.

What about

template
<
    class one,
    class two,
    class three,
 >
struct x;

or

void f(int one,
        int two,
        int three,
       );


Just playing the devil's advocate  :-)


Bo Persson


--

---
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-07-28 10:47, Bo Persson wrote:
> On 2015-07-28 16:05, Matthew Woehlke wrote:
>> I'd be in favor of the change; as others have indicated, this makes
>> it really obnoxious and unnecessarily difficult to make VCS edits
>> of initializer lists, and is inconsistent with enums and aggregates
>> which allow the trailing comma.
>
> But it IS consistent with other comma separated items, like parameters.
>
> What about
>
> template
> <
>    class one,
>    class two,
>    class three,
> >
> struct x;

As already noted, it's fairly uncommon to have long template parameter
lists of the sort that would most benefit from such relaxation of the
grammar rules. I think this is less interesting, though I don't see
myself objecting to such a change.

> or
>
> void f(int one,
>        int two,
>        int three,
>       );

I've run into refactoring headaches with parameter lists less often than
initializer lists, but even so, I'd be willing to entertain such a
proposal. (And I'll reiterate something else already pointed out; Python
already allows this.)

Something I think deserves consideration is why e.g. enums and
aggregates support a trailing comma. Someone obviously felt those cases
were worthy; why some but not others?

--
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_547_1577278037.1438096683720
Content-Type: multipart/alternative;
 boundary="----=_Part_548_1365848342.1438096683729"

------=_Part_548_1365848342.1438096683729
Content-Type: text/plain; charset=UTF-8

But why would you even want to write such code? The idea of trailing comma
is at best weird and useless.

On Tuesday, 28 July 2015 16:02:27 UTC+1, Matthew Woehlke wrote:
>
> On 2015-07-28 10:47, Bo Persson wrote:
> > On 2015-07-28 16:05, Matthew Woehlke wrote:
> >> I'd be in favor of the change; as others have indicated, this makes
> >> it really obnoxious and unnecessarily difficult to make VCS edits
> >> of initializer lists, and is inconsistent with enums and aggregates
> >> which allow the trailing comma.
> >
> > But it IS consistent with other comma separated items, like parameters.
> >
> > What about
> >
> > template
> > <
> >    class one,
> >    class two,
> >    class three,
> > >
> > struct x;
>
> As already noted, it's fairly uncommon to have long template parameter
> lists of the sort that would most benefit from such relaxation of the
> grammar rules. I think this is less interesting, though I don't see
> myself objecting to such a change.
>
> > or
> >
> > void f(int one,
> >        int two,
> >        int three,
> >       );
>
> I've run into refactoring headaches with parameter lists less often than
> initializer lists, but even so, I'd be willing to entertain such a
> proposal. (And I'll reiterate something else already pointed out; Python
> already allows this.)
>
> Something I think deserves consideration is why e.g. enums and
> aggregates support a trailing comma. Someone obviously felt those cases
> were worthy; why some but not others?
>
> --
> 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_548_1365848342.1438096683729
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">But why would you even want to write such code? The idea o=
f trailing comma is at best weird and useless.<br><br>On Tuesday, 28 July 2=
015 16:02:27 UTC+1, 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-07-28 10:47, Bo Persson wrote:
<br>&gt; On 2015-07-28 16:05, Matthew Woehlke wrote:
<br>&gt;&gt; I&#39;d be in favor of the change; as others have indicated, t=
his makes
<br>&gt;&gt; it really obnoxious and unnecessarily difficult to make VCS ed=
its
<br>&gt;&gt; of initializer lists, and is inconsistent with enums and aggre=
gates
<br>&gt;&gt; which allow the trailing comma.
<br>&gt;=20
<br>&gt; But it IS consistent with other comma separated items, like parame=
ters.
<br>&gt;=20
<br>&gt; What about
<br>&gt;=20
<br>&gt; template
<br>&gt; &lt;
<br>&gt; =C2=A0 =C2=A0class one,
<br>&gt; =C2=A0 =C2=A0class two,
<br>&gt; =C2=A0 =C2=A0class three,
<br>&gt; &gt;
<br>&gt; struct x;
<br>
<br>As already noted, it&#39;s fairly uncommon to have long template parame=
ter
<br>lists of the sort that would most benefit from such relaxation of the
<br>grammar rules. I think this is less interesting, though I don&#39;t see
<br>myself objecting to such a change.
<br>
<br>&gt; or
<br>&gt;=20
<br>&gt; void f(int one,
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0int two,
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0int three,
<br>&gt; =C2=A0 =C2=A0 =C2=A0 );
<br>
<br>I&#39;ve run into refactoring headaches with parameter lists less often=
 than
<br>initializer lists, but even so, I&#39;d be willing to entertain such a
<br>proposal. (And I&#39;ll reiterate something else already pointed out; P=
ython
<br>already allows this.)
<br>
<br>Something I think deserves consideration is why e.g. enums and
<br>aggregates support a trailing comma. Someone obviously felt those cases
<br>were worthy; why some but not others?
<br>
<br>--=20
<br>Matthew
<br>
<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 />

------=_Part_548_1365848342.1438096683729--
------=_Part_547_1577278037.1438096683720--

.

On 2015-07-28 11:18, Arthur Tchaikovsky wrote:
> But why would you even want to write such code? The idea of trailing comma
> is at best weird and useless.

Because it eliminates a special case for the last item in a list. This
can be critical if you're using macros to generate a list. It also means
that, if you have one item per line, the previous line does not change
when adding a new item, which is important when using a VCS (which
should be the case for any non-trivial code).

So, your "useless" assertion is false. I'd also argue that your "weird"
assertion is dubious, as ending each item-line with a comma, even the
last one, makes for greater consistency. And there may be other
benefits; those are just the ones I can think of offhand.


Consider:

   enum Animals {
     Dog,
  -  Cat
  +  Cat,
  +  Emu
   };

vs.

   enum Animals {
     Dog,
     Cat,
  +  Emu,
   }

Which more clearly conveys the relevant change?

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

.

But this is not C++ problem but Source Control Tools. They need to be
improved not C++ needs to adjust.

On 7/28/15, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> On 2015-07-28 11:18, Arthur Tchaikovsky wrote:
>> But why would you even want to write such code? The idea of trailing comma
>>
>> is at best weird and useless.
>
> Because it eliminates a special case for the last item in a list. This
> can be critical if you're using macros to generate a list. It also means
> that, if you have one item per line, the previous line does not change
> when adding a new item, which is important when using a VCS (which
> should be the case for any non-trivial code).
>
> So, your "useless" assertion is false. I'd also argue that your "weird"
> assertion is dubious, as ending each item-line with a comma, even the
> last one, makes for greater consistency. And there may be other
> benefits; those are just the ones I can think of offhand.
>
>
> Consider:
>
>    enum Animals {
>      Dog,
>   -  Cat
>   +  Cat,
>   +  Emu
>    };
>
> vs.
>
>    enum Animals {
>      Dog,
>      Cat,
>   +  Emu,
>    }
>
> Which more clearly conveys the relevant change?
>
> --
> 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/.
>


--
Yours sincerely
Artur Czajkowski

--

---
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 Tue, Jul 28, 2015 at 1:04 PM, Arthur Tchaikovsky <atch.cpp@gmail.com> wr=
ote:
> But this is not C++ problem but Source Control Tools. They need to be
> improved not C++ needs to adjust.

Real world code uses version control systems which part of their job
is to let people know
which lines have changed. A VCS will not have a way to distinguish
whether to show or not to show
a line as "different" depending it has a last comma or not; it's not a
matter of making VCSs smarter.

>
> On 7/28/15, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>> On 2015-07-28 11:18, Arthur Tchaikovsky wrote:
>>> But why would you even want to write such code? The idea of trailing co=
mma
>>>
>>> is at best weird and useless.
>>
>> Because it eliminates a special case for the last item in a list. This
>> can be critical if you're using macros to generate a list. It also means
>> that, if you have one item per line, the previous line does not change
>> when adding a new item, which is important when using a VCS (which
>> should be the case for any non-trivial code).
>>
>> So, your "useless" assertion is false. I'd also argue that your "weird"
>> assertion is dubious, as ending each item-line with a comma, even the
>> last one, makes for greater consistency. And there may be other
>> benefits; those are just the ones I can think of offhand.
>>
>>
>> Consider:
>>
>>    enum Animals {
>>      Dog,
>>   -  Cat
>>   +  Cat,
>>   +  Emu
>>    };
>>
>> vs.
>>
>>    enum Animals {
>>      Dog,
>>      Cat,
>>   +  Emu,
>>    }
>>
>> Which more clearly conveys the relevant change?
>>
>> --
>> Matthew
>>
>> --
>>
>> ---
>> 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.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>
> --
> Yours sincerely
> Artur Czajkowski
>
> --
>
> ---
> 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-propo=
sals/.



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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_2298_1751001877.1438101515655
Content-Type: text/plain; charset=UTF-8

C++ doesn't live in a vacuum.  Source control exists, and I dare say most C++ users use it.

The change to allow comma at the end of enum lists is a relatively recent one; C++11 I believe.  That change had to go through the same process, the same resistance, etc., and yet it made it.  Minor stuff does get accepted >.<

Melissa

--

---
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_2298_1751001877.1438101515655--

.

Arthur, your second emails prove *exactly* why this is being discussed.

Your first email showed your annoyed reaction to this list discussing a trivial
matter when so many other important things need to be discussed.

And then you fell for the lure of the discussion, went to the dark side and
joined the discussion :-)

On Tuesday 28 July 2015 13:38:15 Arthur Tchaikovsky wrote:
> And it simply look weird having a comma and nothing following it. It
> looks like there is something missing.
>
> On 7/28/15, Arthur Tchaikovsky <atch.cpp@gmail.com> wrote:
> > I genuinely cannot believe what I'm reading in this discussion.
> > Do C++ really has no other *bigger* problems to solve, that we can
> > discuss if comma should be allowed at the end of constructor's
> > initializer list, because some one has preferences towards it?
> > Seriously?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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 Tuesday 28 July 2015 16:00:37 Ville Voutilainen wrote:
> On 28 July 2015 at 15:41, David Krauss <potswa@gmail.com> wrote:
> > Regardless of the number of messages in this thread, the committee effort
> > should be low. It should be a small proposal, a brief meeting discussion,
> > and a minor change to the normative grammar spec.
> And then wait for every implementation on the planet to implement this
> change, and
> every other tool that desperately tries to grok C++ code. The overall
> effort is anything
> but low, so the question is whether the benefit is worth the effort.
> Thus far the rationale
> provided doesn't convince me.

I can answer with two bytes: >>

Besides, comma at the end of enums is permitted. Why not at the end of other
lists?

However, comma at the end of a parameter list?

 foobar(1,
  2,
  3,
  4,
  );

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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_4349_1021395132.1438101838026
Content-Type: multipart/alternative;
 boundary="----=_Part_4350_1396264529.1438101838027"

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

And I repeat:
It is a tool job to do its job properly, not language to adjust.

On Tuesday, 28 July 2015 17:29:11 UTC+1, dgutson wrote:
>
> On Tue, Jul 28, 2015 at 1:04 PM, Arthur Tchaikovsky <atch...@gmail.com=20
> <javascript:>> wrote:=20
> > But this is not C++ problem but Source Control Tools. They need to be=
=20
> > improved not C++ needs to adjust.=20
>
> Real world code uses version control systems which part of their job=20
> is to let people know=20
> which lines have changed. A VCS will not have a way to distinguish=20
> whether to show or not to show=20
> a line as "different" depending it has a last comma or not; it's not a=20
> matter of making VCSs smarter.=20
>
> >=20
> > On 7/28/15, Matthew Woehlke <mwoehlk...@gmail.com <javascript:>> wrote:=
=20
> >> On 2015-07-28 11:18, Arthur Tchaikovsky wrote:=20
> >>> But why would you even want to write such code? The idea of trailing=
=20
> comma=20
> >>>=20
> >>> is at best weird and useless.=20
> >>=20
> >> Because it eliminates a special case for the last item in a list. This=
=20
> >> can be critical if you're using macros to generate a list. It also=20
> means=20
> >> that, if you have one item per line, the previous line does not change=
=20
> >> when adding a new item, which is important when using a VCS (which=20
> >> should be the case for any non-trivial code).=20
> >>=20
> >> So, your "useless" assertion is false. I'd also argue that your "weird=
"=20
> >> assertion is dubious, as ending each item-line with a comma, even the=
=20
> >> last one, makes for greater consistency. And there may be other=20
> >> benefits; those are just the ones I can think of offhand.=20
> >>=20
> >>=20
> >> Consider:=20
> >>=20
> >>    enum Animals {=20
> >>      Dog,=20
> >>   -  Cat=20
> >>   +  Cat,=20
> >>   +  Emu=20
> >>    };=20
> >>=20
> >> vs.=20
> >>=20
> >>    enum Animals {=20
> >>      Dog,=20
> >>      Cat,=20
> >>   +  Emu,=20
> >>    }=20
> >>=20
> >> Which more clearly conveys the relevant change?=20
> >>=20
> >> --=20
> >> Matthew=20
> >>=20
> >> --=20
> >>=20
> >> ---=20
> >> You received this message because you are subscribed to the Google=20
> Groups=20
> >> "ISO C++ Standard - Future Proposals" group.=20
> >> To unsubscribe from this group and stop receiving emails from it, send=
=20
> an=20
> >> email to std-proposal...@isocpp.org <javascript:>.=20
> >> To post to this group, send email to std-pr...@isocpp.org <javascript:=
>.=20
>
> >> Visit this group at=20
> >> http://groups.google.com/a/isocpp.org/group/std-proposals/.=20
> >>=20
> >=20
> >=20
> > --=20
> > Yours sincerely=20
> > Artur Czajkowski=20
> >=20
> > --=20
> >=20
> > ---=20
> > You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.=20
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an email to std-proposal...@isocpp.org <javascript:>.=20
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..=20
>
> > Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.=20
>
>
>
> --=20
> Who=E2=80=99s got the sweetest disposition?=20
> One guess, that=E2=80=99s who?=20
> Who=E2=80=99d never, ever start an argument?=20
> Who never shows a bit of temperament?=20
> Who's never wrong but always right?=20
> Who'd never dream of starting a fight?=20
> Who get stuck with all the bad luck?=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_4350_1396264529.1438101838027
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">And I repeat:<br>It is a tool job to do its job properly, =
not language to adjust.<br><br>On Tuesday, 28 July 2015 17:29:11 UTC+1, dgu=
tson  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tue, Jul 28, 20=
15 at 1:04 PM, Arthur Tchaikovsky &lt;<a href=3D"javascript:" target=3D"_bl=
ank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;retu=
rn true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">atch..=
..@gmail.com</a>&gt; wrote:
<br>&gt; But this is not C++ problem but Source Control Tools. They need to=
 be
<br>&gt; improved not C++ needs to adjust.
<br>
<br>Real world code uses version control systems which part of their job
<br>is to let people know
<br>which lines have changed. A VCS will not have a way to distinguish
<br>whether to show or not to show
<br>a line as &quot;different&quot; depending it has a last comma or not; i=
t&#39;s not a
<br>matter of making VCSs smarter.
<br>
<br>&gt;
<br>&gt; On 7/28/15, Matthew Woehlke &lt;<a href=3D"javascript:" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;r=
eturn true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">mwo=
ehlk...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; On 2015-07-28 11:18, Arthur Tchaikovsky wrote:
<br>&gt;&gt;&gt; But why would you even want to write such code? The idea o=
f trailing comma
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; is at best weird and useless.
<br>&gt;&gt;
<br>&gt;&gt; Because it eliminates a special case for the last item in a li=
st. This
<br>&gt;&gt; can be critical if you&#39;re using macros to generate a list.=
 It also means
<br>&gt;&gt; that, if you have one item per line, the previous line does no=
t change
<br>&gt;&gt; when adding a new item, which is important when using a VCS (w=
hich
<br>&gt;&gt; should be the case for any non-trivial code).
<br>&gt;&gt;
<br>&gt;&gt; So, your &quot;useless&quot; assertion is false. I&#39;d also =
argue that your &quot;weird&quot;
<br>&gt;&gt; assertion is dubious, as ending each item-line with a comma, e=
ven the
<br>&gt;&gt; last one, makes for greater consistency. And there may be othe=
r
<br>&gt;&gt; benefits; those are just the ones I can think of offhand.
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; Consider:
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0enum Animals {
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0Dog,
<br>&gt;&gt; =C2=A0 - =C2=A0Cat
<br>&gt;&gt; =C2=A0 + =C2=A0Cat,
<br>&gt;&gt; =C2=A0 + =C2=A0Emu
<br>&gt;&gt; =C2=A0 =C2=A0};
<br>&gt;&gt;
<br>&gt;&gt; vs.
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0enum Animals {
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0Dog,
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0Cat,
<br>&gt;&gt; =C2=A0 + =C2=A0Emu,
<br>&gt;&gt; =C2=A0 =C2=A0}
<br>&gt;&gt;
<br>&gt;&gt; Which more clearly conveys the relevant change?
<br>&gt;&gt;
<br>&gt;&gt; --
<br>&gt;&gt; Matthew
<br>&gt;&gt;
<br>&gt;&gt; --
<br>&gt;&gt;
<br>&gt;&gt; ---
<br>&gt;&gt; You received this message because you are subscribed to the Go=
ogle Groups
<br>&gt;&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.
<br>&gt;&gt; To unsubscribe from this group and stop receiving emails from =
it, send an
<br>&gt;&gt; email to <a href=3D"javascript:" target=3D"_blank" rel=3D"nofo=
llow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclic=
k=3D"this.href=3D&#39;javascript:&#39;;return true;">std-proposal...@isocpp=
..org</a>.
<br>&gt;&gt; To post to this group, send email to <a href=3D"javascript:" t=
arget=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascrip=
t:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return t=
rue;">std-pr...@isocpp.org</a>.
<br>&gt;&gt; Visit this group at
<br>&gt;&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-pro=
posals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39=
;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.org/group=
/std-proposals/&#39;;return true;">http://groups.google.com/a/isocpp.org/gr=
oup/std-proposals/</a>.
<br>&gt;&gt;
<br>&gt;
<br>&gt;
<br>&gt; --
<br>&gt; Yours sincerely
<br>&gt; Artur Czajkowski
<br>&gt;
<br>&gt; --
<br>&gt;
<br>&gt; ---
<br>&gt; You received this message because you are subscribed to the Google=
 Groups &quot;ISO C++ Standard - Future Proposals&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an email to <a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow"=
 onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"=
this.href=3D&#39;javascript:&#39;;return true;">std-proposal...@isocpp.org<=
/a>.
<br>&gt; To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#=
39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;=
">std-pr...@isocpp.org</a>.
<br>&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.o=
rg/group/std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/=
&#39;;return true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/=
isocpp.org/group/std-proposals/&#39;;return true;">http://groups.google.com=
/a/isocpp.org/group/std-proposals/</a>.
<br>
<br>
<br>
<br>--=20
<br>Who=E2=80=99s got the sweetest disposition?
<br>One guess, that=E2=80=99s who?
<br>Who=E2=80=99d never, ever start an argument?
<br>Who never shows a bit of temperament?
<br>Who&#39;s never wrong but always right?
<br>Who&#39;d never dream of starting a fight?
<br>Who get stuck with all the bad luck?
<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 />

------=_Part_4350_1396264529.1438101838027--
------=_Part_4349_1021395132.1438101838026--

.

------=_Part_4443_1648395764.1438102043343
Content-Type: multipart/alternative;
 boundary="----=_Part_4444_2026921593.1438102043343"

------=_Part_4444_2026921593.1438102043343
Content-Type: text/plain; charset=UTF-8

Nor those tools either. They need to do the job properly not expecting from
language to adjust.

So what were those argument/s in favor of having comma at the end of enum?
I'm really interested to read it.

On Tuesday, 28 July 2015 17:38:35 UTC+1, Myriachan wrote:
>
> C++ doesn't live in a vacuum.  Source control exists, and I dare say most
> C++ users use it.
>
> The change to allow comma at the end of enum lists is a relatively recent
> one; C++11 I believe.  That change had to go through the same process, the
> same resistance, etc., and yet it made it.  Minor stuff does get accepted
> >.<
>
> Melissa
>
>

--

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

<div dir=3D"ltr">Nor those tools either. They need to do the job properly n=
ot expecting from language to adjust.<br><br>So what were those argument/s =
in favor of having comma at the end of enum? I&#39;m really interested to r=
ead it.<br><br>On Tuesday, 28 July 2015 17:38:35 UTC+1, Myriachan  wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">C++ doesn&#39;t live in a vacuum=
.. =C2=A0Source control exists, and I dare say most C++ users use it.<p>The =
change to allow comma at the end of enum lists is a relatively recent one; =
C++11 I believe. =C2=A0That change had to go through the same process, the =
same resistance, etc., and yet it made it. =C2=A0Minor stuff does get accep=
ted &gt;.&lt;</p><p>Melissa</p><p></p></blockquote></div>

<p></p>

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

------=_Part_4444_2026921593.1438102043343--
------=_Part_4443_1648395764.1438102043343--

.

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

>
> And I repeat:
>
> It is a tool job to do its job properly, not language to adjust.
>
>
C++ is also a tool, so this argument holds no weight for me.



On Tue, Jul 28, 2015 at 11:43 AM, Arthur Tchaikovsky <atch.cpp@gmail.com>
wrote:

> And I repeat:
> It is a tool job to do its job properly, not language to adjust.
>
> On Tuesday, 28 July 2015 17:29:11 UTC+1, dgutson wrote:
>>
>> On Tue, Jul 28, 2015 at 1:04 PM, Arthur Tchaikovsky <atch...@gmail.com>
>> wrote:
>> > But this is not C++ problem but Source Control Tools. They need to be
>> > improved not C++ needs to adjust.
>>
>> Real world code uses version control systems which part of their job
>> is to let people know
>> which lines have changed. A VCS will not have a way to distinguish
>> whether to show or not to show
>> a line as "different" depending it has a last comma or not; it's not a
>> matter of making VCSs smarter.
>>
>> >
>> > On 7/28/15, Matthew Woehlke <mwoehlk...@gmail.com> wrote:
>> >> On 2015-07-28 11:18, Arthur Tchaikovsky wrote:
>> >>> But why would you even want to write such code? The idea of trailing
>> comma
>> >>>
>> >>> is at best weird and useless.
>> >>
>> >> Because it eliminates a special case for the last item in a list. Thi=
s
>> >> can be critical if you're using macros to generate a list. It also
>> means
>> >> that, if you have one item per line, the previous line does not chang=
e
>> >> when adding a new item, which is important when using a VCS (which
>> >> should be the case for any non-trivial code).
>> >>
>> >> So, your "useless" assertion is false. I'd also argue that your
>> "weird"
>> >> assertion is dubious, as ending each item-line with a comma, even the
>> >> last one, makes for greater consistency. And there may be other
>> >> benefits; those are just the ones I can think of offhand.
>> >>
>> >>
>> >> Consider:
>> >>
>> >>    enum Animals {
>> >>      Dog,
>> >>   -  Cat
>> >>   +  Cat,
>> >>   +  Emu
>> >>    };
>> >>
>> >> vs.
>> >>
>> >>    enum Animals {
>> >>      Dog,
>> >>      Cat,
>> >>   +  Emu,
>> >>    }
>> >>
>> >> Which more clearly conveys the relevant change?
>> >>
>> >> --
>> >> 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, sen=
d
>> an
>> >> email to std-proposal...@isocpp.org.
>> >> To post to this group, send email to std-pr...@isocpp.org.
>> >> Visit this group at
>> >> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>> >>
>> >
>> >
>> > --
>> > Yours sincerely
>> > Artur Czajkowski
>> >
>> > --
>> >
>> > ---
>> > 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-proposal...@isocpp.org.
>> > To post to this group, send email to std-pr...@isocpp.org.
>> > Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>>
>>
>> --
>> Who=E2=80=99s got the sweetest disposition?
>> One guess, that=E2=80=99s who?
>> Who=E2=80=99d never, ever start an argument?
>> Who never shows a bit of temperament?
>> Who's never wrong but always right?
>> Who'd never dream of starting a fight?
>> Who get stuck with all the bad luck?
>>
>  --
>
> ---
> 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/.

--001a11408d96e9f4a9051bf245f9
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"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">And I repeat:</blockqu=
ote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex">It is a tool job to do its job properly, not language =
to adjust.</blockquote></blockquote><div><br></div><div>C++ is also a tool,=
 so this argument holds no weight for me.</div><div><br></div><div>=C2=A0</=
div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue,=
 Jul 28, 2015 at 11:43 AM, Arthur Tchaikovsky <span dir=3D"ltr">&lt;<a href=
=3D"mailto:atch.cpp@gmail.com" target=3D"_blank">atch.cpp@gmail.com</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"><div dir=3D"ltr">And I rep=
eat:<br>It is a tool job to do its job properly, not language to adjust.<br=
><br>On Tuesday, 28 July 2015 17:29:11 UTC+1, dgutson  wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><span class=3D"">On Tue, Jul 28, 2015 at 1:04 PM,=
 Arthur Tchaikovsky &lt;<a rel=3D"nofollow">atch...@gmail.com</a>&gt; wrote=
:
<br>&gt; But this is not C++ problem but Source Control Tools. They need to=
 be
<br>&gt; improved not C++ needs to adjust.
<br>
<br>Real world code uses version control systems which part of their job
<br>is to let people know
<br>which lines have changed. A VCS will not have a way to distinguish
<br>whether to show or not to show
<br>a line as &quot;different&quot; depending it has a last comma or not; i=
t&#39;s not a
<br>matter of making VCSs smarter.
<br>
<br>&gt;
<br></span><div><div class=3D"h5">&gt; On 7/28/15, Matthew Woehlke &lt;<a r=
el=3D"nofollow">mwoehlk...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; On 2015-07-28 11:18, Arthur Tchaikovsky wrote:
<br>&gt;&gt;&gt; But why would you even want to write such code? The idea o=
f trailing comma
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; is at best weird and useless.
<br>&gt;&gt;
<br>&gt;&gt; Because it eliminates a special case for the last item in a li=
st. This
<br>&gt;&gt; can be critical if you&#39;re using macros to generate a list.=
 It also means
<br>&gt;&gt; that, if you have one item per line, the previous line does no=
t change
<br>&gt;&gt; when adding a new item, which is important when using a VCS (w=
hich
<br>&gt;&gt; should be the case for any non-trivial code).
<br>&gt;&gt;
<br>&gt;&gt; So, your &quot;useless&quot; assertion is false. I&#39;d also =
argue that your &quot;weird&quot;
<br>&gt;&gt; assertion is dubious, as ending each item-line with a comma, e=
ven the
<br>&gt;&gt; last one, makes for greater consistency. And there may be othe=
r
<br>&gt;&gt; benefits; those are just the ones I can think of offhand.
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; Consider:
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0enum Animals {
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0Dog,
<br>&gt;&gt; =C2=A0 - =C2=A0Cat
<br>&gt;&gt; =C2=A0 + =C2=A0Cat,
<br>&gt;&gt; =C2=A0 + =C2=A0Emu
<br>&gt;&gt; =C2=A0 =C2=A0};
<br>&gt;&gt;
<br>&gt;&gt; vs.
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0enum Animals {
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0Dog,
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0Cat,
<br>&gt;&gt; =C2=A0 + =C2=A0Emu,
<br>&gt;&gt; =C2=A0 =C2=A0}
<br>&gt;&gt;
<br>&gt;&gt; Which more clearly conveys the relevant change?
<br>&gt;&gt;
<br>&gt;&gt; --
<br>&gt;&gt; Matthew
<br>&gt;&gt;
<br>&gt;&gt; --
<br>&gt;&gt;
<br>&gt;&gt; ---
<br>&gt;&gt; You received this message because you are subscribed to the Go=
ogle Groups
<br>&gt;&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.
<br>&gt;&gt; To unsubscribe from this group and stop receiving emails from =
it, send an
<br></div></div>&gt;&gt; email to <a rel=3D"nofollow">std-proposal...@isocp=
p.org</a>.
<br>&gt;&gt; To post to this group, send email to <a rel=3D"nofollow">std-p=
r...@isocpp.org</a>.
<br>&gt;&gt; Visit this group at
<br>&gt;&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-pro=
posals/" rel=3D"nofollow" target=3D"_blank">http://groups.google.com/a/isoc=
pp.org/group/std-proposals/</a>.
<br><span class=3D"">&gt;&gt;
<br>&gt;
<br>&gt;
<br>&gt; --
<br>&gt; Yours sincerely
<br>&gt; Artur Czajkowski
<br>&gt;
<br>&gt; --
<br>&gt;
<br>&gt; ---
<br>&gt; You received this message because you are subscribed to the Google=
 Groups &quot;ISO C++ Standard - Future Proposals&quot; group.
<br></span>&gt; To unsubscribe from this group and stop receiving emails fr=
om it, send an email to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.
<br>&gt; To post to this group, send email to <a rel=3D"nofollow">std-pr...=
@isocpp.org</a>.
<br>&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.o=
rg/group/std-proposals/" rel=3D"nofollow" target=3D"_blank">http://groups.g=
oogle.com/a/isocpp.org/group/std-proposals/</a>.
<br><span class=3D"">
<br>
<br>
<br>--=20
<br>Who=E2=80=99s got the sweetest disposition?
<br>One guess, that=E2=80=99s who?
<br>Who=E2=80=99d never, ever start an argument?
<br>Who never shows a bit of temperament?
<br>Who&#39;s never wrong but always right?
<br>Who&#39;d never dream of starting a fight?
<br>Who get stuck with all the bad luck?
<br></span></blockquote></div><span class=3D"">

<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></span>
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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</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 />

--001a11408d96e9f4a9051bf245f9--

.

------=_Part_4320_722522904.1438102748387
Content-Type: multipart/alternative;
 boundary="----=_Part_4321_1528847646.1438102748387"

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

It is a tool but for different purpose. VCS are tools and their job is (one=
=20
of many) to properly show changes. This is not C++ job to adjust to those=
=20
tools, because in this scenario C++ is not a tool but a subject to which=20
tool is applied. Surely you will not try to invent better form of plank in=
=20
order to be able to hit nails more precisely? It's a hammer's job to do it.=
=20
Not planks. Both are tools, but in different scenarios. I'm a son, but also=
=20
a father. Different situations, different roles assumed.

On Tuesday, 28 July 2015 17:50:55 UTC+1, Brent Friedman wrote:
>
> And I repeat:
>>
>> It is a tool job to do its job properly, not language to adjust.
>>
>>
> C++ is also a tool, so this argument holds no weight for me.
>
> =20
>
> On Tue, Jul 28, 2015 at 11:43 AM, Arthur Tchaikovsky <atch...@gmail.com=
=20
> <javascript:>> wrote:
>
>> And I repeat:
>> It is a tool job to do its job properly, not language to adjust.
>>
>> On Tuesday, 28 July 2015 17:29:11 UTC+1, dgutson wrote:
>>>
>>> On Tue, Jul 28, 2015 at 1:04 PM, Arthur Tchaikovsky <atch...@gmail.com>=
=20
>>> wrote:=20
>>> > But this is not C++ problem but Source Control Tools. They need to be=
=20
>>> > improved not C++ needs to adjust.=20
>>>
>>> Real world code uses version control systems which part of their job=20
>>> is to let people know=20
>>> which lines have changed. A VCS will not have a way to distinguish=20
>>> whether to show or not to show=20
>>> a line as "different" depending it has a last comma or not; it's not a=
=20
>>> matter of making VCSs smarter.=20
>>>
>>> >=20
>>> > On 7/28/15, Matthew Woehlke <mwoehlk...@gmail.com> wrote:=20
>>> >> On 2015-07-28 11:18, Arthur Tchaikovsky wrote:=20
>>> >>> But why would you even want to write such code? The idea of trailin=
g=20
>>> comma=20
>>> >>>=20
>>> >>> is at best weird and useless.=20
>>> >>=20
>>> >> Because it eliminates a special case for the last item in a list.=20
>>> This=20
>>> >> can be critical if you're using macros to generate a list. It also=
=20
>>> means=20
>>> >> that, if you have one item per line, the previous line does not=20
>>> change=20
>>> >> when adding a new item, which is important when using a VCS (which=
=20
>>> >> should be the case for any non-trivial code).=20
>>> >>=20
>>> >> So, your "useless" assertion is false. I'd also argue that your=20
>>> "weird"=20
>>> >> assertion is dubious, as ending each item-line with a comma, even th=
e=20
>>> >> last one, makes for greater consistency. And there may be other=20
>>> >> benefits; those are just the ones I can think of offhand.=20
>>> >>=20
>>> >>=20
>>> >> Consider:=20
>>> >>=20
>>> >>    enum Animals {=20
>>> >>      Dog,=20
>>> >>   -  Cat=20
>>> >>   +  Cat,=20
>>> >>   +  Emu=20
>>> >>    };=20
>>> >>=20
>>> >> vs.=20
>>> >>=20
>>> >>    enum Animals {=20
>>> >>      Dog,=20
>>> >>      Cat,=20
>>> >>   +  Emu,=20
>>> >>    }=20
>>> >>=20
>>> >> Which more clearly conveys the relevant change?=20
>>> >>=20
>>> >> --=20
>>> >> Matthew=20
>>> >>=20
>>> >> --=20
>>> >>=20
>>> >> ---=20
>>> >> You received this message because you are subscribed to the Google=
=20
>>> Groups=20
>>> >> "ISO C++ Standard - Future Proposals" group.=20
>>> >> To unsubscribe from this group and stop receiving emails from it,=20
>>> send an=20
>>> >> email to std-proposal...@isocpp.org.=20
>>> >> To post to this group, send email to std-pr...@isocpp.org.=20
>>> >> Visit this group at=20
>>> >> http://groups.google.com/a/isocpp.org/group/std-proposals/.=20
>>> >>=20
>>> >=20
>>> >=20
>>> > --=20
>>> > Yours sincerely=20
>>> > Artur Czajkowski=20
>>> >=20
>>> > --=20
>>> >=20
>>> > ---=20
>>> > You received this message because you are subscribed to the Google=20
>>> Groups "ISO C++ Standard - Future Proposals" group.=20
>>> > To unsubscribe from this group and stop receiving emails from it, sen=
d=20
>>> an email to std-proposal...@isocpp.org.=20
>>> > To post to this group, send email to std-pr...@isocpp.org.=20
>>> > Visit this group at=20
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.=20
>>>
>>>
>>>
>>> --=20
>>> Who=E2=80=99s got the sweetest disposition?=20
>>> One guess, that=E2=80=99s who?=20
>>> Who=E2=80=99d never, ever start an argument?=20
>>> Who never shows a bit of temperament?=20
>>> Who's never wrong but always right?=20
>>> Who'd never dream of starting a fight?=20
>>> Who get stuck with all the bad luck?=20
>>>
>>  --=20
>>
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--=20

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

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

<div dir=3D"ltr">It is a tool but for different purpose. VCS are tools and =
their job is (one of many) to properly show changes. This is not C++ job to=
 adjust to those tools, because in this scenario C++ is not a tool but a su=
bject to which tool is applied. Surely you will not try to invent better fo=
rm of plank in order to be able to hit nails more precisely? It&#39;s a ham=
mer&#39;s job to do it. Not planks. Both are tools, but in different scenar=
ios. I&#39;m a son, but also a father. Different situations, different role=
s assumed.<br><br>On Tuesday, 28 July 2015 17:50:55 UTC+1, Brent Friedman  =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-=
left:1ex"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex">And I repeat:</blockquote><blockquote class=3D"g=
mail_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">It is=
 a tool job to do its job properly, not language to adjust.</blockquote></b=
lockquote><div><br></div><div>C++ is also a tool, so this argument holds no=
 weight for me.</div><div><br></div><div>=C2=A0</div></div><div><br><div cl=
ass=3D"gmail_quote">On Tue, Jul 28, 2015 at 11:43 AM, Arthur Tchaikovsky <s=
pan dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=
=3D"this.href=3D&#39;javascript:&#39;;return true;">atch...@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">And I r=
epeat:<br>It is a tool job to do its job properly, not language to adjust.<=
br><br>On Tuesday, 28 July 2015 17:29:11 UTC+1, dgutson  wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex"><span>On Tue, Jul 28, 2015 at 1:04 PM, Arthur T=
chaikovsky &lt;<a rel=3D"nofollow">atch...@gmail.com</a>&gt; wrote:
<br>&gt; But this is not C++ problem but Source Control Tools. They need to=
 be
<br>&gt; improved not C++ needs to adjust.
<br>
<br>Real world code uses version control systems which part of their job
<br>is to let people know
<br>which lines have changed. A VCS will not have a way to distinguish
<br>whether to show or not to show
<br>a line as &quot;different&quot; depending it has a last comma or not; i=
t&#39;s not a
<br>matter of making VCSs smarter.
<br>
<br>&gt;
<br></span><div><div>&gt; On 7/28/15, Matthew Woehlke &lt;<a rel=3D"nofollo=
w">mwoehlk...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; On 2015-07-28 11:18, Arthur Tchaikovsky wrote:
<br>&gt;&gt;&gt; But why would you even want to write such code? The idea o=
f trailing comma
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; is at best weird and useless.
<br>&gt;&gt;
<br>&gt;&gt; Because it eliminates a special case for the last item in a li=
st. This
<br>&gt;&gt; can be critical if you&#39;re using macros to generate a list.=
 It also means
<br>&gt;&gt; that, if you have one item per line, the previous line does no=
t change
<br>&gt;&gt; when adding a new item, which is important when using a VCS (w=
hich
<br>&gt;&gt; should be the case for any non-trivial code).
<br>&gt;&gt;
<br>&gt;&gt; So, your &quot;useless&quot; assertion is false. I&#39;d also =
argue that your &quot;weird&quot;
<br>&gt;&gt; assertion is dubious, as ending each item-line with a comma, e=
ven the
<br>&gt;&gt; last one, makes for greater consistency. And there may be othe=
r
<br>&gt;&gt; benefits; those are just the ones I can think of offhand.
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; Consider:
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0enum Animals {
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0Dog,
<br>&gt;&gt; =C2=A0 - =C2=A0Cat
<br>&gt;&gt; =C2=A0 + =C2=A0Cat,
<br>&gt;&gt; =C2=A0 + =C2=A0Emu
<br>&gt;&gt; =C2=A0 =C2=A0};
<br>&gt;&gt;
<br>&gt;&gt; vs.
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0enum Animals {
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0Dog,
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0Cat,
<br>&gt;&gt; =C2=A0 + =C2=A0Emu,
<br>&gt;&gt; =C2=A0 =C2=A0}
<br>&gt;&gt;
<br>&gt;&gt; Which more clearly conveys the relevant change?
<br>&gt;&gt;
<br>&gt;&gt; --
<br>&gt;&gt; Matthew
<br>&gt;&gt;
<br>&gt;&gt; --
<br>&gt;&gt;
<br>&gt;&gt; ---
<br>&gt;&gt; You received this message because you are subscribed to the Go=
ogle Groups
<br>&gt;&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.
<br>&gt;&gt; To unsubscribe from this group and stop receiving emails from =
it, send an
<br></div></div>&gt;&gt; email to <a rel=3D"nofollow">std-proposal...@isocp=
p.org</a>.
<br>&gt;&gt; To post to this group, send email to <a rel=3D"nofollow">std-p=
r...@isocpp.org</a>.
<br>&gt;&gt; Visit this group at
<br>&gt;&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-pro=
posals/" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39=
;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.org/group=
/std-proposals/&#39;;return true;">http://groups.google.com/a/isocpp.org/gr=
oup/std-proposals/</a>.
<br><span>&gt;&gt;
<br>&gt;
<br>&gt;
<br>&gt; --
<br>&gt; Yours sincerely
<br>&gt; Artur Czajkowski
<br>&gt;
<br>&gt; --
<br>&gt;
<br>&gt; ---
<br>&gt; You received this message because you are subscribed to the Google=
 Groups &quot;ISO C++ Standard - Future Proposals&quot; group.
<br></span>&gt; To unsubscribe from this group and stop receiving emails fr=
om it, send an email to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.
<br>&gt; To post to this group, send email to <a rel=3D"nofollow">std-pr...=
@isocpp.org</a>.
<br>&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.o=
rg/group/std-proposals/" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"=
this.href=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/=
&#39;;return true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/=
isocpp.org/group/std-proposals/&#39;;return true;">http://groups.google.com=
/a/isocpp.org/group/std-proposals/</a>.
<br><span>
<br>
<br>
<br>--=20
<br>Who=E2=80=99s got the sweetest disposition?
<br>One guess, that=E2=80=99s who?
<br>Who=E2=80=99d never, ever start an argument?
<br>Who never shows a bit of temperament?
<br>Who&#39;s never wrong but always right?
<br>Who&#39;d never dream of starting a fight?
<br>Who get stuck with all the bad luck?
<br></span></blockquote></div><span>

<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></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" onmoused=
own=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">std-pr.=
...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.or=
g/group/std-proposals/&#39;;return true;">http://groups.google.com/a/isocpp=
..org/group/std-proposals/</a>.<br>
</blockquote></div><br></div>
</blockquote></div>

<p></p>

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

------=_Part_4321_1528847646.1438102748387--
------=_Part_4320_722522904.1438102748387--

.

------=_Part_650_1863148941.1438103018540
Content-Type: multipart/alternative;
 boundary="----=_Part_651_617766732.1438103018540"

------=_Part_651_617766732.1438103018540
Content-Type: text/plain; charset=UTF-8

Another argument against? Comma logically separates things and that's how
most people I believe understand its role. Comma at end of logical *entity*
is:
a) weird
b) useless
c) illogical

from C++ standpoint.

On Tuesday, 28 July 2015 17:38:35 UTC+1, Myriachan wrote:
>
> C++ doesn't live in a vacuum.  Source control exists, and I dare say most
> C++ users use it.
>
> The change to allow comma at the end of enum lists is a relatively recent
> one; C++11 I believe.  That change had to go through the same process, the
> same resistance, etc., and yet it made it.  Minor stuff does get accepted
> >.<
>
> Melissa
>
>

--

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

<div dir=3D"ltr">Another argument against? Comma logically separates things=
 and that&#39;s how most people I believe understand its role. Comma at end=
 of logical *entity* is:<br>a) weird<br>b) useless<br>c) illogical<br><br>f=
rom C++ standpoint. <br><br>On Tuesday, 28 July 2015 17:38:35 UTC+1, Myriac=
han  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">C++ doesn&#39;t liv=
e in a vacuum. =C2=A0Source control exists, and I dare say most C++ users u=
se it.<p>The change to allow comma at the end of enum lists is a relatively=
 recent one; C++11 I believe. =C2=A0That change had to go through the same =
process, the same resistance, etc., and yet it made it. =C2=A0Minor stuff d=
oes get accepted &gt;.&lt;</p><p>Melissa</p><p></p></blockquote></div>

<p></p>

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

------=_Part_651_617766732.1438103018540--
------=_Part_650_1863148941.1438103018540--

.

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

>
> Surely you will not try to invent better form of plank in order to be able
> to hit nails more precisely?


"Plank manufacturers" absolutely alter how they construct wood planks to
make hammering less error prone. You cut the plank in such a way [along the
grain] that the wood will grip the nail better. You prefer types of wood
less likely to splinter or warp under pressure.

However, I think it's more useful to remain on the topic of C++ rather than
discussing the generally unrelated discipline of carpentry.

On Tue, Jul 28, 2015 at 12:03 PM, Arthur Tchaikovsky <atch.cpp@gmail.com>
wrote:

> Another argument against? Comma logically separates things and that's how
> most people I believe understand its role. Comma at end of logical *entity*
> is:
> a) weird
> b) useless
> c) illogical
>
> from C++ standpoint.
>
> On Tuesday, 28 July 2015 17:38:35 UTC+1, Myriachan wrote:
>>
>> C++ doesn't live in a vacuum.  Source control exists, and I dare say most
>> C++ users use it.
>>
>> The change to allow comma at the end of enum lists is a relatively recent
>> one; C++11 I believe.  That change had to go through the same process, the
>> same resistance, etc., and yet it made it.  Minor stuff does get accepted
>> >.<
>>
>> Melissa
>>
>>  --
>
> ---
> 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/.

--089e01177373f7b3c5051bf31cd4
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.8000001907349=
px">Surely you will not try to invent better form of plank in order to be a=
ble to hit nails more precisely?=C2=A0</span></blockquote><div><br></div><d=
iv>&quot;Plank manufacturers&quot; absolutely alter how they construct wood=
 planks to make hammering less error prone. You cut the plank in such a way=
 [along the grain] that the wood will grip the nail better. You prefer type=
s of wood less likely to splinter or warp under pressure.</div><div><br></d=
iv><div>However, I think it&#39;s more useful to remain on the topic of C++=
 rather than discussing the generally unrelated discipline of carpentry.</d=
iv></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, =
Jul 28, 2015 at 12:03 PM, Arthur Tchaikovsky <span dir=3D"ltr">&lt;<a href=
=3D"mailto:atch.cpp@gmail.com" target=3D"_blank">atch.cpp@gmail.com</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"><div dir=3D"ltr">Another a=
rgument against? Comma logically separates things and that&#39;s how most p=
eople I believe understand its role. Comma at end of logical *entity* is:<b=
r>a) weird<br>b) useless<br>c) illogical<br><br>from C++ standpoint. <br><s=
pan class=3D""><br>On Tuesday, 28 July 2015 17:38:35 UTC+1, Myriachan  wrot=
e:</span><span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">C++ doesn=
&#39;t live in a vacuum.=C2=A0 Source control exists, and I dare say most C=
++ users use it.<p>The change to allow comma at the end of enum lists is a =
relatively recent one; C++11 I believe.=C2=A0 That change had to go through=
 the same process, the same resistance, etc., and yet it made it.=C2=A0 Min=
or stuff does get accepted &gt;.&lt;</p><p>Melissa</p><p></p></blockquote><=
/span></div><span class=3D"">

<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></span>
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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</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 />

--089e01177373f7b3c5051bf31cd4--

.

------=_Part_4617_2077900391.1438105980434
Content-Type: multipart/alternative;
 boundary="----=_Part_4618_126664134.1438105980434"

------=_Part_4618_126664134.1438105980434
Content-Type: text/plain; charset=UTF-8

Exactly, that's why I repeat:
It is tool that parses C++ to do a proper job, not C++ job to adjust to
that tool.

On Tuesday, 28 July 2015 18:51:02 UTC+1, Brent Friedman wrote:
>
> Surely you will not try to invent better form of plank in order to be able
>> to hit nails more precisely?
>
>
> "Plank manufacturers" absolutely alter how they construct wood planks to
> make hammering less error prone. You cut the plank in such a way [along the
> grain] that the wood will grip the nail better. You prefer types of wood
> less likely to splinter or warp under pressure.
>
> However, I think it's more useful to remain on the topic of C++ rather
> than discussing the generally unrelated discipline of carpentry.
>
> On Tue, Jul 28, 2015 at 12:03 PM, Arthur Tchaikovsky <atch...@gmail.com
> <javascript:>> wrote:
>
>> Another argument against? Comma logically separates things and that's how
>> most people I believe understand its role. Comma at end of logical *entity*
>> is:
>> a) weird
>> b) useless
>> c) illogical
>>
>> from C++ standpoint.
>>
>> On Tuesday, 28 July 2015 17:38:35 UTC+1, Myriachan wrote:
>>>
>>> C++ doesn't live in a vacuum.  Source control exists, and I dare say
>>> most C++ users use it.
>>>
>>> The change to allow comma at the end of enum lists is a relatively
>>> recent one; C++11 I believe.  That change had to go through the same
>>> process, the same resistance, etc., and yet it made it.  Minor stuff does
>>> get accepted >.<
>>>
>>> Melissa
>>>
>>>  --
>>
>> ---
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> 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/.

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

<div dir=3D"ltr">Exactly, that&#39;s why I repeat:<br>It is tool that parse=
s C++ to do a proper job, not C++ job to adjust to that tool.<br><br>On Tue=
sday, 28 July 2015 18:51:02 UTC+1, Brent Friedman  wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-col=
or:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style=
=3D"font-size:12.8000001907349px">Surely you will not try to invent better =
form of plank in order to be able to hit nails more precisely?=C2=A0</span>=
</blockquote><div><br></div><div>&quot;Plank manufacturers&quot; absolutely=
 alter how they construct wood planks to make hammering less error prone. Y=
ou cut the plank in such a way [along the grain] that the wood will grip th=
e nail better. You prefer types of wood less likely to splinter or warp und=
er pressure.</div><div><br></div><div>However, I think it&#39;s more useful=
 to remain on the topic of C++ rather than discussing the generally unrelat=
ed discipline of carpentry.</div></div><div><br><div class=3D"gmail_quote">=
On Tue, Jul 28, 2015 at 12:03 PM, Arthur Tchaikovsky <span dir=3D"ltr">&lt;=
<a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;=
javascript:&#39;;return true;">atch...@gmail.com</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"><div dir=3D"ltr">Another argument against? Co=
mma logically separates things and that&#39;s how most people I believe und=
erstand its role. Comma at end of logical *entity* is:<br>a) weird<br>b) us=
eless<br>c) illogical<br><br>from C++ standpoint. <br><span><br>On Tuesday,=
 28 July 2015 17:38:35 UTC+1, Myriachan  wrote:</span><span><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex">C++ doesn&#39;t live in a vacuum.=C2=A0 Source con=
trol exists, and I dare say most C++ users use it.<p>The change to allow co=
mma at the end of enum lists is a relatively recent one; C++11 I believe.=
=C2=A0 That change had to go through the same process, the same resistance,=
 etc., and yet it made it.=C2=A0 Minor stuff does get accepted &gt;.&lt;</p=
><p>Melissa</p><p></p></blockquote></span></div><span>

<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></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" onmoused=
own=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">std-pr.=
...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.or=
g/group/std-proposals/&#39;;return true;">http://groups.google.com/a/isocpp=
..org/group/std-proposals/</a>.<br>
</blockquote></div><br></div>
</blockquote></div>

<p></p>

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

------=_Part_4618_126664134.1438105980434--
------=_Part_4617_2077900391.1438105980434--

.

On 2015-07-28 12:04, Arthur Tchaikovsky wrote:
> But this is not C++ problem but Source Control Tools. They need to be
> improved not C++ needs to adjust.

<satire>
POSIX is a terrible API for file system manipulation. Therefore, rather
than providing standard interfaces in C++ to perform I/O operations, we
should insist that POSIX change to conform to what C++ thinks it The One
True Way to implement file systems and disk I/O.
</satire>

You are not going to change every generic textual comparison
tool/library in existence (and there are a LOT of them, most based on
the Unified Diff standard which is at issue here). As such, assertions
that doing so is the "proper" course of action are out of touch with
reality.

For that matter, I'll reiterate Ville's argument, inverted; it's much
more effort to change text comparison tools than to change C++ parsers,
if only because there are so very many more of them.

--
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 Tuesday 28 July 2015 09:59:08 Arthur Tchaikovsky wrote:
> It is a tool but for different purpose. VCS are tools and their job is (one
> of many) to properly show changes. This is not C++ job to adjust to those
> tools, because in this scenario C++ is not a tool but a subject to which
> tool is applied.

In an ideal world, the VCS tool would have a parser for every single language
under the Sun and would interpret when a change is meaningful or not.

in the real world, none of them do. Supporting every single language is just
not feasible. Heuristics may or may not be enough, and they may or may not be
misleading too. For example, in most languages, leading whitespace changes are
no-ops, so they could be discarded from view. But not in all languages.

> Surely you will not try to invent better form of plank in
> order to be able to hit nails more precisely? It's a hammer's job to do it.
> Not planks.

Unless your plank is made of a material that is too hard, in which case you
must replace it. That's similar here: we have to adapt to the real world.

(And don't call me Shirley - https://www.youtube.com/watch?v=ixljWVyPby0)

> Both are tools, but in different scenarios. I'm a son, but also
> a father. Different situations, different roles assumed.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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 Tuesday 28 July 2015 10:53:00 Arthur Tchaikovsky wrote:
> It is tool that parses C++ to do a proper job, not C++ job to adjust to
> that tool.

True. But which tool are we talking about that parses C++?

VCS tools don't.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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 28 July 2015 at 19:42, Thiago Macieira <thiago@macieira.org> wrote:
>> And then wait for every implementation on the planet to implement this
>> change, and
>> every other tool that desperately tries to grok C++ code. The overall
>> effort is anything
>> but low, so the question is whether the benefit is worth the effort.
>> Thus far the rationale
>> provided doesn't convince me.
> I can answer with two bytes: >>

I fail to see how that's even remotely similar to what we're discussing here.

> Besides, comma at the end of enums is permitted. Why not at the end of other
> lists?

If we want to allow a trailing comma in a ctor-initializer list, what about the
base-specifier list?

struct X :
A,
B,
C,
{};

--

---
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_4684_131466362.1438122877375
Content-Type: multipart/alternative;
 boundary="----=_Part_4685_98741415.1438122877375"

------=_Part_4685_98741415.1438122877375
Content-Type: text/plain; charset=UTF-8

I would be for such a change, for the simple reason that it makes it easier
to generate code.
If I'm not mistaken, that's *the* reason why trailing commas are already
allowed in many contexts.

And let's be honest, that's not one or two tools: we all needed to generate
code at some point, be it from macros or from another tool.

Not having to special-case stuff allows to write generation tools more
easily and that's a huge benefit offered by trailing comma.

--

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

<div dir=3D"ltr">I would be for such a change, for the simple reason that i=
t makes it easier to generate code.<br>If I&#39;m not mistaken, that&#39;s =
*the* reason why trailing commas are already allowed in many contexts.<br><=
br>And let&#39;s be honest, that&#39;s not one or two tools: we all needed =
to generate code at some point, be it from macros or from another tool.<br>=
<br>Not having to special-case stuff allows to write generation tools more =
easily and that&#39;s a huge benefit offered by trailing comma.<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 />

------=_Part_4685_98741415.1438122877375--
------=_Part_4684_131466362.1438122877375--

.

> On 2015=E2=80=9307=E2=80=9328, at 9:00 PM, Ville Voutilainen <ville.vouti=
lainen@gmail.com> wrote:
>=20
> On 28 July 2015 at 15:41, David Krauss <potswa@gmail.com> wrote:
>> Regardless of the number of messages in this thread, the committee effor=
t should be low. It should be a small proposal, a brief meeting discussion,=
 and a minor change to the normative grammar spec.
>=20
> And then wait for every implementation on the planet to implement this
> change, and
> every other tool that desperately tries to grok C++ code. The overall
> effort is anything
> but low, so the question is whether the benefit is worth the effort.
> Thus far the rationale
> provided doesn't convince me.

Compilers are labor-saving devices. Implementation work is well spent if it=
 saves time for users. What we have in this thread is customers agreeing th=
at they=E2=80=99re wasting time because this C++ grammar quirk chokes other=
 tools in the chain. The customer is usually right, unless there=E2=80=99s =
an argument that the feature could be dangerous.

Constructor initializers are a lot like statements, so they should have sim=
ilar punctuation. They map 1:1 to nonstatic member declarations, which typi=
cally have dedicated lines. If you were to write the initializations as ass=
ignments in the function body, you wouldn=E2=80=99t even think of running t=
he statements together on one line. Mem-initializers do the same job. That=
=E2=80=99s why they=E2=80=99re like enumerator declarations and aggregate i=
nitializers, and unlike function arguments. Base classes also often get lis=
ted line by line, but multiple inheritance is uncommon.

In a perfect world, we=E2=80=99d have some way to terminate member initiali=
zers with semicolons, yet evaluate them in the order of their declarations.=
 The syntax is already a compromise, and this tweak to let commas act more =
like semicolons seems quite appropriate.

--=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_15_991207278.1438139011210
Content-Type: multipart/alternative;
 boundary="----=_Part_16_1496247894.1438139011210"

------=_Part_16_1496247894.1438139011210
Content-Type: text/plain; charset=UTF-8

+1000. This inconsistency has always annoyed me as well.

On Monday, July 27, 2015 at 3:02:06 PM UTC-7, Myriachan wrote:
>
> To fix a minor annoyance for a long time, I think that the initializer
> list following a constructor prototype should allow a trailing comma with
> nothing after it.  This also makes initializer lists consistent with enums
> (C++11) and aggregate initializers (C++03?).  The purpose is to assist when
> editing, and helping when using "svn blame" or the equivalent for your
> version control.
>
> Yes, I have seen the workaround of putting commas on the next line, but
> this doesn't match some coding styles.
>
> class dword_table
> {
> public:
>     dword_table(std::size_t count)
>     try
>     :   m_array(new std::uint32_t[count]),
>         m_count(count),
>     {
>     }
>     catch (std::bad_alloc)
>     {
>         std::fprintf(stderr, "out of memory allocating %zu dwords", count);
>         throw;
>     }
>     ...
> };
>
> Melissa
>
>

--

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

<div dir=3D"ltr">+1000. This inconsistency has always annoyed me as well. <=
br><br>On Monday, July 27, 2015 at 3:02:06 PM UTC-7, Myriachan wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">To fix a minor annoyance for a long =
time, I think that the initializer list following a constructor prototype s=
hould allow a trailing comma with nothing after it. =C2=A0This also makes i=
nitializer lists consistent with enums (C++11) and aggregate initializers (=
C++03?). =C2=A0The purpose is to assist when editing, and helping when usin=
g &quot;svn blame&quot; or the equivalent for your version control.<p>Yes, =
I have seen the workaround of putting commas on the next line, but this doe=
sn&#39;t match some coding styles.</p><p>class dword_table<br>{<br>public:<=
br>=C2=A0 =C2=A0 dword_table(std::size_t count)<br>=C2=A0 =C2=A0 try<br>=C2=
=A0 =C2=A0 : =C2=A0 m_array(new std::uint32_t[count]),<br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 m_count(count),<br>=C2=A0 =C2=A0 {<br>=C2=A0 =C2=A0 }<br>=C2=A0 =
=C2=A0 catch (std::bad_alloc)<br>=C2=A0 =C2=A0 {<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 std::fprintf(stderr, &quot;out of memory allocating %zu dwords&quot;=
, count);<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 throw;<br>=C2=A0 =C2=A0 }<br>=C2=
=A0 =C2=A0 ...<br>};</p><p>Melissa</p><p></p><p></p></blockquote></div>

<p></p>

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

------=_Part_16_1496247894.1438139011210--
------=_Part_15_991207278.1438139011210--

.

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

El 28/7/2015 18:37, "Ville Voutilainen" <ville.voutilainen@gmail.com>
escribi=C3=B3:
>
> On 28 July 2015 at 19:42, Thiago Macieira <thiago@macieira.org> wrote:
> >> And then wait for every implementation on the planet to implement this
> >> change, and
> >> every other tool that desperately tries to grok C++ code. The overall
> >> effort is anything
> >> but low, so the question is whether the benefit is worth the effort.
> >> Thus far the rationale
> >> provided doesn't convince me.
> > I can answer with two bytes: >>
>
> I fail to see how that's even remotely similar to what we're discussing
here.
>
> > Besides, comma at the end of enums is permitted. Why not at the end of
other
> > lists?
>
> If we want to allow a trailing comma in a ctor-initializer list, what
about the
> base-specifier list?
>
> struct X :
> A,
> B,
> C,
> {};

I couldn't strongly argue your point, but to mention 2 things:
1) frequency of change (base-specifier list versus members initializer list=
)
2) usual layout:allowing a trailing comma is better suited for things that
are usually vertically listed (such as enums and members initialization)
rather than horizontally listed (base classes list, function arguments,
template arguments). Let's keep in mind that VCS are line-oriented.

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

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

<p dir=3D"ltr"><br>
El 28/7/2015 18:37, &quot;Ville Voutilainen&quot; &lt;<a href=3D"mailto:vil=
le.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; escribi=C3=B3=
:<br>
&gt;<br>
&gt; On 28 July 2015 at 19:42, Thiago Macieira &lt;<a href=3D"mailto:thiago=
@macieira.org">thiago@macieira.org</a>&gt; wrote:<br>
&gt; &gt;&gt; And then wait for every implementation on the planet to imple=
ment this<br>
&gt; &gt;&gt; change, and<br>
&gt; &gt;&gt; every other tool that desperately tries to grok C++ code. The=
 overall<br>
&gt; &gt;&gt; effort is anything<br>
&gt; &gt;&gt; but low, so the question is whether the benefit is worth the =
effort.<br>
&gt; &gt;&gt; Thus far the rationale<br>
&gt; &gt;&gt; provided doesn&#39;t convince me.<br>
&gt; &gt; I can answer with two bytes: &gt;&gt;<br>
&gt;<br>
&gt; I fail to see how that&#39;s even remotely similar to what we&#39;re d=
iscussing here.<br>
&gt;<br>
&gt; &gt; Besides, comma at the end of enums is permitted. Why not at the e=
nd of other<br>
&gt; &gt; lists?<br>
&gt;<br>
&gt; If we want to allow a trailing comma in a ctor-initializer list, what =
about the<br>
&gt; base-specifier list?<br>
&gt;<br>
&gt; struct X :<br>
&gt; A,<br>
&gt; B,<br>
&gt; C,<br>
&gt; {};</p>
<p dir=3D"ltr">I couldn&#39;t strongly argue your point, but to mention 2 t=
hings:<br>
1) frequency of change (base-specifier list versus members initializer list=
)<br>
2) usual layout:allowing a trailing comma is better suited for things that =
are usually vertically listed (such as enums and members initialization) ra=
ther than horizontally listed (base classes list, function arguments, templ=
ate arguments). Let&#39;s keep in mind that VCS are line-oriented.</p>
<p dir=3D"ltr">&gt;<br>
&gt; --<br>
&gt;<br>
&gt; ---<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>

<p></p>

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

--001a113ef45aceb122051bfb38f1--

.

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

On 2015-07-29 05:03, Jared Grubb wrote:
> +1000. This inconsistency has always annoyed me as well.
same here, both in manual code maintenance and with code generators

>
> On Monday, July 27, 2015 at 3:02:06 PM UTC-7, Myriachan wrote:
>
>     To fix a minor annoyance for a long time, I think that the
>     initializer list following a constructor prototype should allow a
>     trailing comma with nothing after it.  This also makes initializer
>     lists consistent with enums (C++11) and aggregate initializers
>     (C++03?).  The purpose is to assist when editing, and helping when
>     using "svn blame" or the equivalent for your version control.
>
>     Yes, I have seen the workaround of putting commas on the next
>     line, but this doesn't match some coding styles.
>
>     class dword_table
>     {
>     public:
>         dword_table(std::size_t count)
>         try
>         :   m_array(new std::uint32_t[count]),
>             m_count(count),
>         {
>         }
>         catch (std::bad_alloc)
>         {
>             std::fprintf(stderr, "out of memory allocating %zu
>     dwords", count);
>             throw;
>         }
>         ...
>     };
>
>     Melissa
>
> --
>
> ---
> 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
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto: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/.

--------------080802070908020404000600
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">
    <div class=3D"moz-cite-prefix">On 2015-07-29 05:03, Jared Grubb wrote:<=
br>
    </div>
    <blockquote
      cite=3D"mid:5dbae5c1-995e-4e21-921e-3909a46bcd85@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">+1000. This inconsistency has always annoyed me as
        well. <br>
      </div>
    </blockquote>
    same here, both in manual code maintenance and with code generators<br>
    <br>
    <blockquote
      cite=3D"mid:5dbae5c1-995e-4e21-921e-3909a46bcd85@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        On Monday, July 27, 2015 at 3:02:06 PM UTC-7, Myriachan wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">To fix a
          minor annoyance for a long time, I think that the initializer
          list following a constructor prototype should allow a trailing
          comma with nothing after it. =C2=A0This also makes initializer
          lists consistent with enums (C++11) and aggregate initializers
          (C++03?). =C2=A0The purpose is to assist when editing, and helpin=
g
          when using "svn blame" or the equivalent for your version
          control.
          <p>Yes, I have seen the workaround of putting commas on the
            next line, but this doesn't match some coding styles.</p>
          <p>class dword_table<br>
            {<br>
            public:<br>
            =C2=A0 =C2=A0 dword_table(std::size_t count)<br>
            =C2=A0 =C2=A0 try<br>
            =C2=A0 =C2=A0 : =C2=A0 m_array(new std::uint32_t[count]),<br>
            =C2=A0 =C2=A0 =C2=A0 =C2=A0 m_count(count),<br>
            =C2=A0 =C2=A0 {<br>
            =C2=A0 =C2=A0 }<br>
            =C2=A0 =C2=A0 catch (std::bad_alloc)<br>
            =C2=A0 =C2=A0 {<br>
            =C2=A0 =C2=A0 =C2=A0 =C2=A0 std::fprintf(stderr, "out of memory=
 allocating %zu
            dwords", count);<br>
            =C2=A0 =C2=A0 =C2=A0 =C2=A0 throw;<br>
            =C2=A0 =C2=A0 }<br>
            =C2=A0 =C2=A0 ...<br>
            };</p>
          <p>Melissa</p>
        </blockquote>
      </div>
      -- <br>
      <br>
      --- <br>
      You received this message because you are subscribed to the Google
      Groups "ISO C++ Standard - Future Proposals" group.<br>
      To unsubscribe from this group and stop receiving emails from it,
      send an email to <a moz-do-not-send=3D"true"
        href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
      To post to this group, send email to <a moz-do-not-send=3D"true"
        href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
      Visit this group at <a moz-do-not-send=3D"true"
        href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
    </blockquote>
    <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 />

--------------080802070908020404000600--

.

On 29 July 2015 at 05:03, David Krauss <potswa@gmail.com> wrote:
> Compilers are labor-saving devices. Implementation work is well spent if =
it saves time for users. What we have in this thread is customers agreeing =
that they=E2=80=99re wasting time because this C++ grammar quirk chokes oth=
er tools in the chain. The customer is usually right, unless there=E2=80=99=
s an argument that the feature could be dangerous.

Dearest Customers,

I have implemented the proposed change for gcc, see
https://github.com/villevoutilainen/gcc/commit/3e7dc8cc67ef5a3c302ff15c90b0=
c7cbc56760e9
if you want to play with it.

Should some of you write a proposal for this change, and should the
committee accept the
change, I would be more than happy to submit this patch for inclusion into =
gcc.

Disclaimer: Kindly do not take this as endorsement of the feature. I
remain unconvinced
of the merits of the proposed feature, although I have no plans to
expend energy to
sink it if the committee is willing to adopt it.

P.S. For people concerned about my "warding off work", feel free to
have a tasty stew
of crow.

--=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_3129_408755385.1438166068084
Content-Type: multipart/alternative;
 boundary="----=_Part_3130_646369212.1438166068084"

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

Hi Ville,=20
So in the same spirit, why can't we have (in the sake of consistency)=20
similar construct allowed:

class X: public: A,B,C; protected D,E,F
{
public:
A a;
B b;
C c;
protected:
D d;
E e;
F f;
};

The point ^^^ here is that we are inheriting in similar manner to=20
classifying access level of members of a class, that is, we are stating=20
only once the desired inheritance level, not every time as we are obliged=
=20
to do now, unless we inheriting privately.
This change is:
a) Non breaking existing code
b) Makes class declaration more uniform

On Wednesday, 29 July 2015 10:08:19 UTC+1, Ville Voutilainen wrote:
>
> On 29 July 2015 at 05:03, David Krauss <pot...@gmail.com <javascript:>>=
=20
> wrote:=20
> > Compilers are labor-saving devices. Implementation work is well spent i=
f=20
> it saves time for users. What we have in this thread is customers agreein=
g=20
> that they=E2=80=99re wasting time because this C++ grammar quirk chokes o=
ther tools=20
> in the chain. The customer is usually right, unless there=E2=80=99s an ar=
gument=20
> that the feature could be dangerous.=20
>
> Dearest Customers,=20
>
> I have implemented the proposed change for gcc, see=20
>
> https://github.com/villevoutilainen/gcc/commit/3e7dc8cc67ef5a3c302ff15c90=
b0c7cbc56760e9=20
> if you want to play with it.=20
>
> Should some of you write a proposal for this change, and should the=20
> committee accept the=20
> change, I would be more than happy to submit this patch for inclusion int=
o=20
> gcc.=20
>
> Disclaimer: Kindly do not take this as endorsement of the feature. I=20
> remain unconvinced=20
> of the merits of the proposed feature, although I have no plans to=20
> expend energy to=20
> sink it if the committee is willing to adopt it.=20
>
> P.S. For people concerned about my "warding off work", feel free to=20
> have a tasty stew=20
> of crow.=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_3130_646369212.1438166068084
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Ville, <br>So in the same spirit, why can&#39;t we have=
 (in the sake of consistency) similar construct allowed:<br><br>class X: pu=
blic: A,B,C; protected D,E,F<br>{<br>public:<br>A a;<br>B b;<br>C c;<br>pro=
tected:<br>D d;<br>E e;<br>F f;<br>};<br><br>The point ^^^ here is that we =
are inheriting in similar manner to classifying access level of members of =
a class, that is, we are stating only once the desired inheritance level, n=
ot every time as we are obliged to do now, unless we inheriting privately.<=
br>This change is:<br>a) Non breaking existing code<br>b) Makes class decla=
ration more uniform<br><br>On Wednesday, 29 July 2015 10:08:19 UTC+1, Ville=
 Voutilainen  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 29 July=
 2015 at 05:03, David Krauss &lt;<a href=3D"javascript:" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tr=
ue;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">pot...@gmai=
l.com</a>&gt; wrote:
<br>&gt; Compilers are labor-saving devices. Implementation work is well sp=
ent if it saves time for users. What we have in this thread is customers ag=
reeing that they=E2=80=99re wasting time because this C++ grammar quirk cho=
kes other tools in the chain. The customer is usually right, unless there=
=E2=80=99s an argument that the feature could be dangerous.
<br>
<br>Dearest Customers,
<br>
<br>I have implemented the proposed change for gcc, see
<br><a href=3D"https://github.com/villevoutilainen/gcc/commit/3e7dc8cc67ef5=
a3c302ff15c90b0c7cbc56760e9" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.co=
m%2Fvillevoutilainen%2Fgcc%2Fcommit%2F3e7dc8cc67ef5a3c302ff15c90b0c7cbc5676=
0e9\46sa\75D\46sntz\0751\46usg\75AFQjCNHEvWgz8oV9ZB9UwJfGGp5S5nvIUg&#39;;re=
turn true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\75http=
s%3A%2F%2Fgithub.com%2Fvillevoutilainen%2Fgcc%2Fcommit%2F3e7dc8cc67ef5a3c30=
2ff15c90b0c7cbc56760e9\46sa\75D\46sntz\0751\46usg\75AFQjCNHEvWgz8oV9ZB9UwJf=
GGp5S5nvIUg&#39;;return true;">https://github.com/villevoutilainen/gcc/comm=
it/3e7dc8cc67ef5a3c302ff15c90b0c7cbc56760e9</a>
<br>if you want to play with it.
<br>
<br>Should some of you write a proposal for this change, and should the
<br>committee accept the
<br>change, I would be more than happy to submit this patch for inclusion i=
nto gcc.
<br>
<br>Disclaimer: Kindly do not take this as endorsement of the feature. I
<br>remain unconvinced
<br>of the merits of the proposed feature, although I have no plans to
<br>expend energy to
<br>sink it if the committee is willing to adopt it.
<br>
<br>P.S. For people concerned about my &quot;warding off work&quot;, feel f=
ree to
<br>have a tasty stew
<br>of crow.
<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 />

------=_Part_3130_646369212.1438166068084--
------=_Part_3129_408755385.1438166068084--

.

On 29 July 2015 at 13:34, Arthur Tchaikovsky <atch.cpp@gmail.com> wrote:
> Hi Ville,
> So in the same spirit, why can't we have (in the sake of consistency)
> similar construct allowed:
> class X: public: A,B,C; protected D,E,F

That is not "in the same spirit", and I fail to see the consistency argument.
That idea has very little to do with a trailing comma in any list, and
its motivation
would seem completely different.

> {
> public:
> A a;
> B b;
> C c;
> protected:
> D d;
> E e;
> F f;
> };
>
> The point ^^^ here is that we are inheriting in similar manner to
> classifying access level of members of a class, that is, we are stating only
> once the desired inheritance level, not every time as we are obliged to do
> now, unless we inheriting privately.
> This change is:
> a) Non breaking existing code
> b) Makes class declaration more uniform


But as has been mentioned, multiple base classes are much rarer than multiple
non-static data members, so the motivation for such a thing seems weak.

--

---
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_5341_1690944533.1438178771465
Content-Type: multipart/alternative;
 boundary="----=_Part_5342_886708895.1438178771466"

------=_Part_5342_886708895.1438178771466
Content-Type: text/plain; charset=UTF-8

It is in the same spirit that is: *make things uniform*.
The consistency argument is:
if in declaration of a class we can:

public:
A a;
B b;

Why can't we do the same whilst declaring what classes we are inheriting
from:
class X: public: A,B,C;<-- here A,B,C would be publicly inherited
{
};


On Wednesday, 29 July 2015 13:43:19 UTC+1, Ville Voutilainen wrote:
>
> On 29 July 2015 at 13:34, Arthur Tchaikovsky <atch...@gmail.com
> <javascript:>> wrote:
> > Hi Ville,
> > So in the same spirit, why can't we have (in the sake of consistency)
> > similar construct allowed:
> > class X: public: A,B,C; protected D,E,F
>
> That is not "in the same spirit", and I fail to see the consistency
> argument.
> That idea has very little to do with a trailing comma in any list, and
> its motivation
> would seem completely different.
>
> > {
> > public:
> > A a;
> > B b;
> > C c;
> > protected:
> > D d;
> > E e;
> > F f;
> > };
> >
> > The point ^^^ here is that we are inheriting in similar manner to
> > classifying access level of members of a class, that is, we are stating
> only
> > once the desired inheritance level, not every time as we are obliged to
> do
> > now, unless we inheriting privately.
> > This change is:
> > a) Non breaking existing code
> > b) Makes class declaration more uniform
>
>
> But as has been mentioned, multiple base classes are much rarer than
> multiple
> non-static data members, so the motivation for such a thing seems weak.
>

--

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

<div dir=3D"ltr">It is in the same spirit that is: *make things uniform*.<b=
r>The consistency argument is:<br>if in declaration of a class we can:<br><=
br>public:<br>A a;<br>B b;<br><br>Why can&#39;t we do the same whilst decla=
ring what classes we are inheriting from:<br>class X: public: A,B,C;&lt;-- =
here A,B,C would be publicly inherited<br>{<br>};<br><br><br>On Wednesday, =
29 July 2015 13:43:19 UTC+1, Ville Voutilainen  wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;">On 29 July 2015 at 13:34, Arthur Tchaikovsky &lt;<a=
 href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;">atch...@gmail.com</a>&gt; wrote:
<br>&gt; Hi Ville,
<br>&gt; So in the same spirit, why can&#39;t we have (in the sake of consi=
stency)
<br>&gt; similar construct allowed:
<br>&gt; class X: public: A,B,C; protected D,E,F
<br>
<br>That is not &quot;in the same spirit&quot;, and I fail to see the consi=
stency argument.
<br>That idea has very little to do with a trailing comma in any list, and
<br>its motivation
<br>would seem completely different.
<br>
<br>&gt; {
<br>&gt; public:
<br>&gt; A a;
<br>&gt; B b;
<br>&gt; C c;
<br>&gt; protected:
<br>&gt; D d;
<br>&gt; E e;
<br>&gt; F f;
<br>&gt; };
<br>&gt;
<br>&gt; The point ^^^ here is that we are inheriting in similar manner to
<br>&gt; classifying access level of members of a class, that is, we are st=
ating only
<br>&gt; once the desired inheritance level, not every time as we are oblig=
ed to do
<br>&gt; now, unless we inheriting privately.
<br>&gt; This change is:
<br>&gt; a) Non breaking existing code
<br>&gt; b) Makes class declaration more uniform
<br>
<br>
<br>But as has been mentioned, multiple base classes are much rarer than mu=
ltiple
<br>non-static data members, so the motivation for such a thing seems weak.
<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 />

------=_Part_5342_886708895.1438178771466--
------=_Part_5341_1690944533.1438178771465--

.

On 2015-07-28 17:37, Ville Voutilainen wrote:
> On 28 July 2015 at 19:42, Thiago Macieira wrote:
>> Besides, comma at the end of enums is permitted. Why not at the end of other
>> lists?
>
> If we want to allow a trailing comma in a ctor-initializer list, what about the
> base-specifier list?

Again, I'd consider this a harmless addition. (So, "yes", but a weak "yes".)

--
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 29 July 2015 at 18:42, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> On 2015-07-28 17:37, Ville Voutilainen wrote:
>> On 28 July 2015 at 19:42, Thiago Macieira wrote:
>>> Besides, comma at the end of enums is permitted. Why not at the end of other
>>> lists?
>>
>> If we want to allow a trailing comma in a ctor-initializer list, what about the
>> base-specifier list?
>
> Again, I'd consider this a harmless addition. (So, "yes", but a weak "yes".)


Well, let's see what people end up proposing. I have implementation experience
for the mem-initializer-list case, but I have no time to play with
other hypothetical
changes. I think the base-specifier list has much weaker motivation than the
mem-initializer-list.

--

---
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-07-28 22:03, David Krauss wrote:
> If you were to write the initializations as assignments in the
> function body, you wouldn=E2=80=99t even think of running the statements
> together on one line.

Devil's advocate: I've not only thought about it, I've done so :-).
(Usually the assignments are related, e.g. elements in an array.)

Example:

  this->bg [0] =3D 128; this->bg [1] =3D 128; this->bg [2] =3D 128;
  this->fg1[0] =3D 255; this->fg1[1] =3D 255; this->fg1[2] =3D   0;
  this->fg2[0] =3D  64; this->fg2[1] =3D  64; this->fg2[2] =3D 255;

I've also written stuff like:

  this->a =3D this->b =3D this->c =3D value;

In fairness, neither are *common*, but they do happen :-).

> Mem-initializers [... are] like enumerator declarations and aggregate
> initializers, and unlike function arguments. Base classes also often
> get listed line by line, but multiple inheritance is uncommon.

Actually, in all three cases (okay, less sure about one-per-line base
classes than the other two) I've written both run-on and one-per-line.
Likewise member initializers. And when I say "both", I even mean within
the same code base (i.e. following same coding style). Frequently the
choice depends on the number and/or individual length of the items being
written.

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

.

On 2015-07-29 11:45, Ville Voutilainen wrote:
> On 29 July 2015 at 18:42, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>> On 2015-07-28 17:37, Ville Voutilainen wrote:
>>> On 28 July 2015 at 19:42, Thiago Macieira wrote:
>>>> Besides, comma at the end of enums is permitted. Why not at the end of other
>>>> lists?
>>>
>>> If we want to allow a trailing comma in a ctor-initializer list, what about the
>>> base-specifier list?
>>
>> Again, I'd consider this a harmless addition. (So, "yes", but a weak "yes".)
>
> Well, let's see what people end up proposing. I have implementation experience
> for the mem-initializer-list case, but I have no time to play with
> other hypothetical
> changes. I think the base-specifier list has much weaker motivation than the
> mem-initializer-list.

Agreed; what I mean is I don't feel a particular need to propose it, but
don't have any philosophical objection to it.

--
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_3635_1469210644.1438215117492
Content-Type: multipart/alternative;
 boundary="----=_Part_3636_1065272510.1438215117492"

------=_Part_3636_1065272510.1438215117492
Content-Type: text/plain; charset=UTF-8

On Wednesday, July 29, 2015 at 8:45:53 AM UTC-7, Ville Voutilainen wrote:
>
> On 29 July 2015 at 18:42, Matthew Woehlke <mwoehlk...@gmail.com
> <javascript:>> wrote:
> > On 2015-07-28 17:37, Ville Voutilainen wrote:
> >> On 28 July 2015 at 19:42, Thiago Macieira wrote:
> >>> Besides, comma at the end of enums is permitted. Why not at the end of
> other
> >>> lists?
> >>
> >> If we want to allow a trailing comma in a ctor-initializer list, what
> about the
> >> base-specifier list?
> >
> > Again, I'd consider this a harmless addition. (So, "yes", but a weak
> "yes".)
>
>
> Well, let's see what people end up proposing. I have implementation
> experience
> for the mem-initializer-list case, but I have no time to play with
> other hypothetical
> changes. I think the base-specifier list has much weaker motivation than
> the
> mem-initializer-list.
>

Making the base class list behave this way would break existing code.  For
example:

struct Base1 { ... };
struct Base2
{
    virtual ~Base2() { }
    void DoStuff() { ... }
};
struct Derived : private Base1, Base2 { ... };

int main()
{
    Base2 *meow = new Derived();
    meow->DoStuff();
    delete meow;
    return 0;
}


I noticed the semicolon in Arthur's example; using that to distinguish the
old way versus the new way resolves this problem, but making the semicolon
have that sort of meaning feels crazy.

Melissa

--

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

On Wednesday, July 29, 2015 at 8:45:53 AM UTC-7, Ville Voutilainen wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">On 29 July 2015 at 18:42, Matthe=
w Woehlke &lt;<a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" on=
mousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"thi=
s.href=3D&#39;javascript:&#39;;return true;">mwoehlk...@gmail.com</a>&gt; w=
rote:
<br>&gt; On 2015-07-28 17:37, Ville Voutilainen wrote:
<br>&gt;&gt; On 28 July 2015 at 19:42, Thiago Macieira wrote:
<br>&gt;&gt;&gt; Besides, comma at the end of enums is permitted. Why not a=
t the end of other
<br>&gt;&gt;&gt; lists?
<br>&gt;&gt;
<br>&gt;&gt; If we want to allow a trailing comma in a ctor-initializer lis=
t, what about the
<br>&gt;&gt; base-specifier list?
<br>&gt;
<br>&gt; Again, I&#39;d consider this a harmless addition. (So, &quot;yes&q=
uot;, but a weak &quot;yes&quot;.)
<br>
<br>
<br>Well, let&#39;s see what people end up proposing. I have implementation=
 experience
<br>for the mem-initializer-list case, but I have no time to play with
<br>other hypothetical
<br>changes. I think the base-specifier list has much weaker motivation tha=
n the
<br>mem-initializer-list.
<br></blockquote><div><br>Making the base class list behave this way would =
break existing code.=C2=A0 For example:<br><br><div class=3D"prettyprint" s=
tyle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 1=
87); 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">struct</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Base1</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">...</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=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">struct</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Base2</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">virtual</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
~</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Base2</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">DoStuff</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">...</span><span style=3D"col=
or: #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: #660;" class=3D"st=
yled-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">struct</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Derived</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">private</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">Base1</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettif=
y">Base2</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">...</span><span style=3D"col=
or: #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><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> main</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">()</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>=C2=A0 =
=C2=A0 </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Bas=
e2</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">meow </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">new</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">Derived</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 =C2=A0 meow</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">-&gt;</span><span style=3D"color: #606;" class=3D"styled-by-p=
rettify">DoStuff</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">delete</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> meow</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">ret=
urn</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">}</span></div></code></div><br><br>I not=
iced the semicolon in Arthur&#39;s example; using that to distinguish the o=
ld way versus the new way resolves this problem, but making the semicolon h=
ave that sort of meaning feels crazy.<br><br>Melissa<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 />

------=_Part_3636_1065272510.1438215117492--
------=_Part_3635_1469210644.1438215117492--

.

On 30 July 2015 at 03:11, Myriachan <myriachan@gmail.com> wrote:
>> Well, let's see what people end up proposing. I have implementation
>> experience
>> for the mem-initializer-list case, but I have no time to play with
>> other hypothetical
>> changes. I think the base-specifier list has much weaker motivation than
>> the
>> mem-initializer-list.
> Making the base class list behave this way would break existing code.  For
> example:
> struct Derived : private Base1, Base2 { ... };

But I wasn't talking about any such change, I know it's a breaking
change. What I referred
to was allowing a trailing comma in the base-specifier, thus:
struct Derived : private Base1, Base2, { ... };
quite like allowing it in a mem-initializer-list, but as I said, the
motivation for something
like that is much weaker.

--

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

.

--Apple-Mail=_D14170E7-754D-4A94-A377-176E1CBC05FE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9307=E2=80=9329, at 5:08 PM, Ville Voutilainen <ville.vouti=
lainen@gmail.com> wrote:
>=20
> P.S. For people concerned about my "warding off work", feel free to
> have a tasty stew
> of crow.

Anyone who ever said that must be nuts. You seem to be on a roll with GCC l=
ately.

If nobody else steps up, I=E2=80=99ll write the proposal. I=E2=80=99ll be s=
ure to include some pictures of diffs.

Base specifiers don=E2=80=99t seem to be part of this package.

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

--Apple-Mail=_D14170E7-754D-4A94-A377-176E1CBC05FE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9307=
=E2=80=9329, at 5:08 PM, Ville Voutilainen &lt;<a href=3D"mailto:ville.vout=
ilainen@gmail.com" class=3D"">ville.voutilainen@gmail.com</a>&gt; wrote:</d=
iv><br class=3D"Apple-interchange-newline"><div class=3D""><span style=3D"f=
ont-family: Helvetica; font-size: 12px; font-style: normal; font-variant: n=
ormal; font-weight: normal; letter-spacing: normal; line-height: normal; or=
phans: auto; text-align: start; text-indent: 0px; text-transform: none; whi=
te-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-widt=
h: 0px; float: none; display: inline !important;" class=3D"">P.S. For peopl=
e concerned about my "warding off work", feel free to</span><br style=3D"fo=
nt-family: Helvetica; font-size: 12px; font-style: normal; font-variant: no=
rmal; font-weight: normal; letter-spacing: normal; line-height: normal; orp=
hans: auto; text-align: start; text-indent: 0px; text-transform: none; whit=
e-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width=
: 0px;" class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; letter-spaci=
ng: normal; line-height: normal; orphans: auto; text-align: start; text-ind=
ent: 0px; text-transform: none; white-space: normal; widows: auto; word-spa=
cing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !im=
portant;" class=3D"">have a tasty stew</span><br style=3D"font-family: Helv=
etica; font-size: 12px; font-style: normal; font-variant: normal; font-weig=
ht: normal; letter-spacing: normal; line-height: normal; orphans: auto; tex=
t-align: start; text-indent: 0px; text-transform: none; white-space: normal=
; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=
=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-style: n=
ormal; font-variant: normal; font-weight: normal; letter-spacing: normal; l=
ine-height: normal; orphans: auto; text-align: start; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -w=
ebkit-text-stroke-width: 0px; float: none; display: inline !important;" cla=
ss=3D"">of crow.</span><br style=3D"font-family: Helvetica; font-size: 12px=
; font-style: normal; font-variant: normal; font-weight: normal; letter-spa=
cing: normal; line-height: normal; orphans: auto; text-align: start; text-i=
ndent: 0px; text-transform: none; white-space: normal; widows: auto; word-s=
pacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""></div></blockquote=
></div><br class=3D""><div class=3D"">Anyone who ever said that must be nut=
s. You seem to be on a roll with GCC lately.</div><div class=3D""><br class=
=3D""></div><div class=3D"">If nobody else steps up, I=E2=80=99ll write the=
 proposal. I=E2=80=99ll be sure to include some pictures of diffs.</div><di=
v class=3D""><br class=3D""></div><div class=3D"">Base specifiers don=E2=80=
=99t seem to be part of this package.</div><div class=3D""><br class=3D""><=
/div></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 />

--Apple-Mail=_D14170E7-754D-4A94-A377-176E1CBC05FE--

.

------=_Part_962_2035573657.1438286477055
Content-Type: multipart/alternative;
 boundary="----=_Part_963_1085022475.1438286477055"

------=_Part_963_1085022475.1438286477055
Content-Type: text/plain; charset=UTF-8

On Wednesday, July 29, 2015 at 8:11:57 PM UTC-4, Myriachan wrote:
>
> Making the base class list behave this way would break existing code.  For
> example:
>
> struct Base1 { ... };
> struct Base2
> {
>     virtual ~Base2() { }
>     void DoStuff() { ... }
> };
> struct Derived : private Base1, Base2 { ... };
>
> int main()
> {
>     Base2 *meow = new Derived();
>     meow->DoStuff();
>     delete meow;
>     return 0;
> }
>
>
> I noticed the semicolon in Arthur's example; using that to distinguish the
> old way versus the new way resolves this problem, but making the semicolon
> have that sort of meaning feels crazy.
>

There was also a colon after the public

class X: public: A,B,C;<-- here A,B,C would be publicly inherited

--

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

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

On Wednesday, July 29, 2015 at 8:11:57 PM UTC-4, Myriachan wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">Making the base class list behave this w=
ay would break existing code.=C2=A0 For example:<br><br><div style=3D"backg=
round-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:sol=
id;border-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#=
008">struct</span><span style=3D"color:#000"> </span><span style=3D"color:#=
606">Base1</span><span style=3D"color:#000"> </span><span style=3D"color:#6=
60">{</span><span style=3D"color:#000"> </span><span style=3D"color:#660">.=
...</span><span style=3D"color:#000"> </span><span style=3D"color:#660">};</=
span><span style=3D"color:#000"><br></span><span style=3D"color:#008">struc=
t</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Base2=
</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">{</=
span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"col=
or:#008">virtual</span><span style=3D"color:#000"> </span><span style=3D"co=
lor:#660">~</span><span style=3D"color:#606">Base2</span><span style=3D"col=
or:#660">()</span><span style=3D"color:#000"> </span><span style=3D"color:#=
660">{</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
}</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"=
color:#008">void</span><span style=3D"color:#000"> </span><span style=3D"co=
lor:#606">DoStuff</span><span style=3D"color:#660">()</span><span style=3D"=
color:#000"> </span><span style=3D"color:#660">{</span><span style=3D"color=
:#000"> </span><span style=3D"color:#660">...</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#660">}</span><span style=3D"color:#000"><=
br></span><span style=3D"color:#660">};</span><span style=3D"color:#000"><b=
r></span><span style=3D"color:#008">struct</span><span style=3D"color:#000"=
> </span><span style=3D"color:#606">Derived</span><span style=3D"color:#000=
"> </span><span style=3D"color:#660">:</span><span style=3D"color:#000"> </=
span><span style=3D"color:#008">private</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#606">Base1</span><span style=3D"color:#660">,</=
span><span style=3D"color:#000"> </span><span style=3D"color:#606">Base2</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#660">{</span><=
span style=3D"color:#000"> </span><span style=3D"color:#660">...</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#660">};</span><span st=
yle=3D"color:#000"><br><br></span><span style=3D"color:#008">int</span><spa=
n style=3D"color:#000"> main</span><span style=3D"color:#660">()</span><spa=
n style=3D"color:#000"><br></span><span style=3D"color:#660">{</span><span =
style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#606">Ba=
se2</span><span style=3D"color:#000"> </span><span style=3D"color:#660">*</=
span><span style=3D"color:#000">meow </span><span style=3D"color:#660">=3D<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#008">new</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#606">Derived</s=
pan><span style=3D"color:#660">();</span><span style=3D"color:#000"><br>=C2=
=A0 =C2=A0 meow</span><span style=3D"color:#660">-&gt;</span><span style=3D=
"color:#606">DoStuff</span><span style=3D"color:#660">();</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">delete<=
/span><span style=3D"color:#000"> meow</span><span style=3D"color:#660">;</=
span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"col=
or:#008">return</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#066">0</span><span style=3D"color:#660">;</span><span style=3D"color:#0=
00"><br></span><span style=3D"color:#660">}</span></div></code></div><br><b=
r>I noticed the semicolon in Arthur&#39;s example; using that to distinguis=
h the old way versus the new way resolves this problem, but making the semi=
colon have that sort of meaning feels crazy.<br></blockquote><div><br></div=
><div>There was also a colon after the public</div><div><br></div><div>clas=
s X: public: A,B,C;&lt;-- here A,B,C would be publicly inherited<br></div><=
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 />

------=_Part_963_1085022475.1438286477055--
------=_Part_962_2035573657.1438286477055--

.

------=_Part_23_1352490713.1438299957984
Content-Type: multipart/alternative;
 boundary="----=_Part_24_1321252254.1438299957985"

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

On Wednesday, July 29, 2015 at 11:57:51 PM UTC-7, David Krauss wrote:
>
>
> Anyone who ever said that must be nuts. You seem to be on a roll with GCC=
=20
> lately.
>
> If nobody else steps up, I=E2=80=99ll write the proposal. I=E2=80=99ll be=
 sure to include=20
> some pictures of diffs.
>
> Base specifiers don=E2=80=99t seem to be part of this package.
>
>
I'd be willing to write it if I knew the right format, and where to find=20
diffs of this type without searching forever in open-source projects =3D^-^=
=3D

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

<div dir=3D"ltr">On Wednesday, July 29, 2015 at 11:57:51 PM UTC-7, David Kr=
auss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-=
wrap:break-word"><br><div>Anyone who ever said that must be nuts. You seem =
to be on a roll with GCC lately.</div><div><br></div><div>If nobody else st=
eps up, I=E2=80=99ll write the proposal. I=E2=80=99ll be sure to include so=
me pictures of diffs.</div><div><br></div><div>Base specifiers don=E2=80=99=
t seem to be part of this package.</div><div><br></div></div></blockquote><=
div><br>I&#39;d be willing to write it if I knew the right format, and wher=
e to find diffs of this type without searching forever in open-source proje=
cts =3D^-^=3D<br><br>Melissa <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_24_1321252254.1438299957985--
------=_Part_23_1352490713.1438299957984--

.

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

On Wed, Jul 29, 2015 at 11:57 PM, David Krauss <potswa@gmail.com> wrote:

>
> On 2015=E2=80=9307=E2=80=9329, at 5:08 PM, Ville Voutilainen <ville.vouti=
lainen@gmail.com>
> wrote:
>
> P.S. For people concerned about my "warding off work", feel free to
> have a tasty stew
> of crow.
>
>
> Anyone who ever said that must be nuts. You seem to be on a roll with GCC
> lately.
>
> If nobody else steps up, I=E2=80=99ll write the proposal. I=E2=80=99ll be=
 sure to include
> some pictures of diffs.
>
> Base specifiers don=E2=80=99t seem to be part of this package.
>

FWIW, I'd be opposed to this proposal if it suggests changing
mem-initializers but not base-specifiers. If we want to allow optional
commas after comma-separated lists, we should allow that consistently,
especially between constructs that deliberately have similar grammar
productions.

(Take a look at the implementation of any class that implements multiple MS
COM interfaces for a motivating example for allowing trailing commas in
base specifiers.)

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

--bcaec52d52dd46f8d4051c209dc4
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, Jul 29, 2015 at 11:57 PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D=
"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-wor=
d"><span class=3D""><br><div><blockquote type=3D"cite"><div>On 2015=E2=80=
=9307=E2=80=9329, at 5:08 PM, Ville Voutilainen &lt;<a href=3D"mailto:ville=
..voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com</a>&g=
t; wrote:</div><br><div><span style=3D"font-family:Helvetica;font-size:12px=
;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:no=
rmal;line-height:normal;text-align:start;text-indent:0px;text-transform:non=
e;white-space:normal;word-spacing:0px;float:none;display:inline!important">=
P.S. For people concerned about my &quot;warding off work&quot;, feel free =
to</span><br style=3D"font-family:Helvetica;font-size:12px;font-style:norma=
l;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:=
normal;text-align:start;text-indent:0px;text-transform:none;white-space:nor=
mal;word-spacing:0px"><span style=3D"font-family:Helvetica;font-size:12px;f=
ont-style:normal;font-variant:normal;font-weight:normal;letter-spacing:norm=
al;line-height:normal;text-align:start;text-indent:0px;text-transform:none;=
white-space:normal;word-spacing:0px;float:none;display:inline!important">ha=
ve a tasty stew</span><br style=3D"font-family:Helvetica;font-size:12px;fon=
t-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal=
;line-height:normal;text-align:start;text-indent:0px;text-transform:none;wh=
ite-space:normal;word-spacing:0px"><span style=3D"font-family:Helvetica;fon=
t-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter=
-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-tr=
ansform:none;white-space:normal;word-spacing:0px;float:none;display:inline!=
important">of crow.</span><br style=3D"font-family:Helvetica;font-size:12px=
;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:no=
rmal;line-height:normal;text-align:start;text-indent:0px;text-transform:non=
e;white-space:normal;word-spacing:0px"></div></blockquote></div><br></span>=
<div>Anyone who ever said that must be nuts. You seem to be on a roll with =
GCC lately.</div><div><br></div><div>If nobody else steps up, I=E2=80=99ll =
write the proposal. I=E2=80=99ll be sure to include some pictures of diffs.=
</div><div><br></div><div>Base specifiers don=E2=80=99t seem to be part of =
this package.</div></div></blockquote><div><br></div><div>FWIW, I&#39;d be =
opposed to this proposal if it suggests changing mem-initializers but not b=
ase-specifiers. If we want to allow optional commas after comma-separated l=
ists, we should allow that consistently, especially between constructs that=
 deliberately have similar grammar productions.</div><div><br></div><div>(T=
ake a look at the implementation of any class that implements multiple MS C=
OM interfaces for a motivating example for allowing trailing commas in base=
 specifiers.)</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 />

--bcaec52d52dd46f8d4051c209dc4--

.

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

Richard's comment seems eminently reasonable to me.
https://github.com/cplusplus/draft/compare/master...Quuxplusone:mem_initial=
izer_list_comma

I wish it were easy to come up with a black-and-white separation between
these kinds of changes and the slippery slope that leads to flamewars over
whether to permit

    using id =3D std::tuple<
        int,
        double,  // trailing comma is currently disallowed here
    >;

    auto f =3D [
        alpha=3Dstd::move(alpha),
        beta=3Dstd::move(beta),  // and here
    ](
        int x,
        int y,  // and here
    ) {
    };
    auto x =3D f(
        1,
        2,  // and here
    );

In practice the rule seems to be, "Wait for consensus to form in favor of
trailing-comma in a specific construct, and then add just that one
trailing-comma production to the grammar."  But actually I can't think of
any real reason for anyone to object to trailing-comma in all of the above
cases.

Let's not start a flamewar right now, but *just as a recreational puzzle,*
can anyone come up with a situation in which C++ currently uses comma as a
separator (not the comma-operator) and where permitting "trailing comma" in
that situation would lead to grammatical ambiguity?

=E2=80=93Arthur



On Thu, Jul 30, 2015 at 5:08 PM, Richard Smith <richard@metafoo.co.uk>
wrote:

> On Wed, Jul 29, 2015 at 11:57 PM, David Krauss <potswa@gmail.com> wrote:
>
>>
>> On 2015=E2=80=9307=E2=80=9329, at 5:08 PM, Ville Voutilainen <ville.vout=
ilainen@gmail.com>
>> wrote:
>>
>> P.S. For people concerned about my "warding off work", feel free to
>> have a tasty stew
>> of crow.
>>
>>
>> Anyone who ever said that must be nuts. You seem to be on a roll with GC=
C
>> lately.
>>
>> If nobody else steps up, I=E2=80=99ll write the proposal. I=E2=80=99ll b=
e sure to include
>> some pictures of diffs.
>>
>> Base specifiers don=E2=80=99t seem to be part of this package.
>>
>
> FWIW, I'd be opposed to this proposal if it suggests changing
> mem-initializers but not base-specifiers. If we want to allow optional
> commas after comma-separated lists, we should allow that consistently,
> especially between constructs that deliberately have similar grammar
> productions.
>
> (Take a look at the implementation of any class that implements multiple
> MS COM interfaces for a motivating example for allowing trailing commas i=
n
> base specifiers.)
>
> --
>
> ---
> 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/I8N_75J9ZB8/=
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/.

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

<div dir=3D"ltr"><div>Richard&#39;s comment seems eminently reasonable to m=
e.</div><a href=3D"https://github.com/cplusplus/draft/compare/master...Quux=
plusone:mem_initializer_list_comma">https://github.com/cplusplus/draft/comp=
are/master...Quuxplusone:mem_initializer_list_comma<br></a><div><br></div><=
div>I wish it were easy to come up with a black-and-white separation betwee=
n these kinds of changes and the slippery slope that leads to flamewars ove=
r whether to permit</div><div><br></div><div><font face=3D"monospace, monos=
pace">=C2=A0 =C2=A0 using id =3D std::tuple&lt;</font></div><div><font face=
=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int,</font></div><div=
><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 double, =
=C2=A0// trailing comma is currently disallowed here</font></div><div><font=
 face=3D"monospace, monospace">=C2=A0 =C2=A0 &gt;;</font></div><div><font f=
ace=3D"monospace, monospace"><br></font></div><div><font face=3D"monospace,=
 monospace">=C2=A0 =C2=A0 auto f =3D [</font></div><div><font face=3D"monos=
pace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 alpha=3Dstd::move(alpha),</fon=
t></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 beta=3Dstd::move(beta), =C2=A0// and here</font></div><div><font face=
=3D"monospace, monospace">=C2=A0 =C2=A0 ](</font></div><div><font face=3D"m=
onospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int x,</font></div><div><f=
ont face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int y, =C2=A0=
// and here</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=
=A0 ) {</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =
};</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 auto =
x =3D f(</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 1,</font></div><div><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 2, =C2=A0// and here</font></div><div><font face=
=3D"monospace, monospace">=C2=A0 =C2=A0 );</font></div><div><br></div><div>=
In practice the rule seems to be, &quot;Wait for consensus to form in favor=
 of trailing-comma in a specific construct, and then add just that one trai=
ling-comma production to the grammar.&quot; =C2=A0But actually I can&#39;t =
think of any real reason for anyone to object to trailing-comma in all of t=
he above cases.</div><div><br></div><div>Let&#39;s not start a flamewar rig=
ht now, but <b><i>just as a recreational puzzle,</i></b> can anyone come up=
 with a situation in which C++ currently uses comma as a separator (not the=
 comma-operator) and where permitting &quot;trailing comma&quot; in that si=
tuation would lead to grammatical ambiguity?</div><div><br></div><div>=E2=
=80=93Arthur</div><div><br></div><div><br></div></div><div class=3D"gmail_e=
xtra"><br><div class=3D"gmail_quote">On Thu, Jul 30, 2015 at 5:08 PM, Richa=
rd Smith <span dir=3D"ltr">&lt;<a href=3D"mailto:richard@metafoo.co.uk" tar=
get=3D"_blank">richard@metafoo.co.uk</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D=
"gmail_quote"><span class=3D"">On Wed, Jul 29, 2015 at 11:57 PM, David Krau=
ss <span dir=3D"ltr">&lt;<a href=3D"mailto:potswa@gmail.com" target=3D"_bla=
nk">potswa@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div style=3D"word-wrap:break-word"><span><br><div><blockquote type=3D"ci=
te"><div>On 2015=E2=80=9307=E2=80=9329, at 5:08 PM, Ville Voutilainen &lt;<=
a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.vouti=
lainen@gmail.com</a>&gt; wrote:</div><br><div><span style=3D"font-family:He=
lvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:no=
rmal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:=
0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;disp=
lay:inline!important">P.S. For people concerned about my &quot;warding off =
work&quot;, feel free to</span><br style=3D"font-family:Helvetica;font-size=
:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spaci=
ng:normal;line-height:normal;text-align:start;text-indent:0px;text-transfor=
m:none;white-space:normal;word-spacing:0px"><span style=3D"font-family:Helv=
etica;font-size:12px;font-style:normal;font-variant:normal;font-weight:norm=
al;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0p=
x;text-transform:none;white-space:normal;word-spacing:0px;float:none;displa=
y:inline!important">have a tasty stew</span><br style=3D"font-family:Helvet=
ica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal=
;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;=
text-transform:none;white-space:normal;word-spacing:0px"><span style=3D"fon=
t-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;fon=
t-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;t=
ext-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;floa=
t:none;display:inline!important">of crow.</span><br style=3D"font-family:He=
lvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:no=
rmal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:=
0px;text-transform:none;white-space:normal;word-spacing:0px"></div></blockq=
uote></div><br></span><div>Anyone who ever said that must be nuts. You seem=
 to be on a roll with GCC lately.</div><div><br></div><div>If nobody else s=
teps up, I=E2=80=99ll write the proposal. I=E2=80=99ll be sure to include s=
ome pictures of diffs.</div><div><br></div><div>Base specifiers don=E2=80=
=99t seem to be part of this package.</div></div></blockquote><div><br></di=
v></span><div>FWIW, I&#39;d be opposed to this proposal if it suggests chan=
ging mem-initializers but not base-specifiers. If we want to allow optional=
 commas after comma-separated lists, we should allow that consistently, esp=
ecially between constructs that deliberately have similar grammar productio=
ns.</div><div><br></div><div>(Take a look at the implementation of any clas=
s that implements multiple MS COM interfaces for a motivating example for a=
llowing trailing commas in base specifiers.)</div></div></div></div><div cl=
ass=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <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/I8N_75J9ZB8/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/I8N_75J9ZB8=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a11c26a6a5306c1051c217886--

.

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

I can understand the usefulness of trailing commas to simplify management
tasks. It is an illogical and weird thing. I won't oppose it, but I really
hope those who champion it really think it's the best solution to the
problems they're having. From the outside (not suffering from the basic
problem), it really seems like an awkward thing to accept. I'd be much more
confortable if we looked for something that makes more sense, even if the
pragmatic argument isn't of the unreasonable kind. It makes me feel
uncomfortable to push for something that, essentially, makes no sense in
order to alleviate what (so far) seems like tooling issues...

2015-07-30 21:09 GMT-04:00 Arthur O'Dwyer <arthur.j.odwyer@gmail.com>:

> Richard's comment seems eminently reasonable to me.
>
> https://github.com/cplusplus/draft/compare/master...Quuxplusone:mem_initi=
alizer_list_comma
>
> I wish it were easy to come up with a black-and-white separation between
> these kinds of changes and the slippery slope that leads to flamewars ove=
r
> whether to permit
>
>     using id =3D std::tuple<
>         int,
>         double,  // trailing comma is currently disallowed here
>     >;
>
>     auto f =3D [
>         alpha=3Dstd::move(alpha),
>         beta=3Dstd::move(beta),  // and here
>     ](
>         int x,
>         int y,  // and here
>     ) {
>     };
>     auto x =3D f(
>         1,
>         2,  // and here
>     );
>
> In practice the rule seems to be, "Wait for consensus to form in favor of
> trailing-comma in a specific construct, and then add just that one
> trailing-comma production to the grammar."  But actually I can't think of
> any real reason for anyone to object to trailing-comma in all of the abov=
e
> cases.
>
> Let's not start a flamewar right now, but *just as a recreational puzzle,=
*
> can anyone come up with a situation in which C++ currently uses comma as =
a
> separator (not the comma-operator) and where permitting "trailing comma" =
in
> that situation would lead to grammatical ambiguity?
>
> =E2=80=93Arthur
>
>
>
> On Thu, Jul 30, 2015 at 5:08 PM, Richard Smith <richard@metafoo.co.uk>
> wrote:
>
>> On Wed, Jul 29, 2015 at 11:57 PM, David Krauss <potswa@gmail.com> wrote:
>>
>>>
>>> On 2015=E2=80=9307=E2=80=9329, at 5:08 PM, Ville Voutilainen <
>>> ville.voutilainen@gmail.com> wrote:
>>>
>>> P.S. For people concerned about my "warding off work", feel free to
>>> have a tasty stew
>>> of crow.
>>>
>>>
>>> Anyone who ever said that must be nuts. You seem to be on a roll with
>>> GCC lately.
>>>
>>> If nobody else steps up, I=E2=80=99ll write the proposal. I=E2=80=99ll =
be sure to
>>> include some pictures of diffs.
>>>
>>> Base specifiers don=E2=80=99t seem to be part of this package.
>>>
>>
>> FWIW, I'd be opposed to this proposal if it suggests changing
>> mem-initializers but not base-specifiers. If we want to allow optional
>> commas after comma-separated lists, we should allow that consistently,
>> especially between constructs that deliberately have similar grammar
>> productions.
>>
>> (Take a look at the implementation of any class that implements multiple
>> MS COM interfaces for a motivating example for allowing trailing commas =
in
>> base specifiers.)
>>
>> --
>>
>> ---
>> 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/I8N_75J9ZB8=
/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/.
>>
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr">I can understand the usefulness of trailing commas to simp=
lify management tasks. It is an illogical and weird thing. I won&#39;t oppo=
se it, but I really hope those who champion it really think it&#39;s the be=
st solution to the problems they&#39;re having. From the outside (not suffe=
ring from the basic problem), it really seems like an awkward thing to acce=
pt. I&#39;d be much more confortable if we looked for something that makes =
more sense, even if the pragmatic argument isn&#39;t of the unreasonable ki=
nd. It makes me feel uncomfortable to push for something that, essentially,=
 makes no sense in order to alleviate what (so far) seems like tooling issu=
es...<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">20=
15-07-30 21:09 GMT-04:00 Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a href=
=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gma=
il.com</a>&gt;</span>:<br><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>Richard&#39;s comment seems eminently reasonable to me.</div><a href=3D=
"https://github.com/cplusplus/draft/compare/master...Quuxplusone:mem_initia=
lizer_list_comma" target=3D"_blank">https://github.com/cplusplus/draft/comp=
are/master...Quuxplusone:mem_initializer_list_comma<br></a><div><br></div><=
div>I wish it were easy to come up with a black-and-white separation betwee=
n these kinds of changes and the slippery slope that leads to flamewars ove=
r whether to permit</div><div><br></div><div><font face=3D"monospace, monos=
pace">=C2=A0 =C2=A0 using id =3D std::tuple&lt;</font></div><div><font face=
=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int,</font></div><div=
><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 double, =
=C2=A0// trailing comma is currently disallowed here</font></div><div><font=
 face=3D"monospace, monospace">=C2=A0 =C2=A0 &gt;;</font></div><div><font f=
ace=3D"monospace, monospace"><br></font></div><div><font face=3D"monospace,=
 monospace">=C2=A0 =C2=A0 auto f =3D [</font></div><div><font face=3D"monos=
pace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 alpha=3Dstd::move(alpha),</fon=
t></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 beta=3Dstd::move(beta), =C2=A0// and here</font></div><div><font face=
=3D"monospace, monospace">=C2=A0 =C2=A0 ](</font></div><div><font face=3D"m=
onospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int x,</font></div><div><f=
ont face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int y, =C2=A0=
// and here</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=
=A0 ) {</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =
};</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 auto =
x =3D f(</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 1,</font></div><div><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 2, =C2=A0// and here</font></div><div><font face=
=3D"monospace, monospace">=C2=A0 =C2=A0 );</font></div><div><br></div><div>=
In practice the rule seems to be, &quot;Wait for consensus to form in favor=
 of trailing-comma in a specific construct, and then add just that one trai=
ling-comma production to the grammar.&quot; =C2=A0But actually I can&#39;t =
think of any real reason for anyone to object to trailing-comma in all of t=
he above cases.</div><div><br></div><div>Let&#39;s not start a flamewar rig=
ht now, but <b><i>just as a recreational puzzle,</i></b> can anyone come up=
 with a situation in which C++ currently uses comma as a separator (not the=
 comma-operator) and where permitting &quot;trailing comma&quot; in that si=
tuation would lead to grammatical ambiguity?</div><div><br></div><div>=E2=
=80=93Arthur</div><div><br></div><div><br></div></div><div class=3D"gmail_e=
xtra"><br><div class=3D"gmail_quote"><span class=3D"">On Thu, Jul 30, 2015 =
at 5:08 PM, Richard Smith <span dir=3D"ltr">&lt;<a href=3D"mailto:richard@m=
etafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>&gt;</span> wrote:=
<br></span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><span class=3D""><div dir=3D"ltr"=
><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span>On Wed, Jul 29=
, 2015 at 11:57 PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"mailto:po=
tswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><span><=
br><div><blockquote type=3D"cite"><div>On 2015=E2=80=9307=E2=80=9329, at 5:=
08 PM, Ville Voutilainen &lt;<a href=3D"mailto:ville.voutilainen@gmail.com"=
 target=3D"_blank">ville.voutilainen@gmail.com</a>&gt; wrote:</div><br><div=
><span style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font=
-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal=
;text-align:start;text-indent:0px;text-transform:none;white-space:normal;wo=
rd-spacing:0px;float:none;display:inline!important">P.S. For people concern=
ed about my &quot;warding off work&quot;, feel free to</span><br style=3D"f=
ont-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;f=
ont-weight:normal;letter-spacing:normal;line-height:normal;text-align:start=
;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><=
span style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-v=
ariant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;t=
ext-align:start;text-indent:0px;text-transform:none;white-space:normal;word=
-spacing:0px;float:none;display:inline!important">have a tasty stew</span><=
br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-var=
iant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;tex=
t-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px"><span style=3D"font-family:Helvetica;font-size:12px;font-style:=
normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-he=
ight:normal;text-align:start;text-indent:0px;text-transform:none;white-spac=
e:normal;word-spacing:0px;float:none;display:inline!important">of crow.</sp=
an><br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font=
-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal=
;text-align:start;text-indent:0px;text-transform:none;white-space:normal;wo=
rd-spacing:0px"></div></blockquote></div><br></span><div>Anyone who ever sa=
id that must be nuts. You seem to be on a roll with GCC lately.</div><div><=
br></div><div>If nobody else steps up, I=E2=80=99ll write the proposal. I=
=E2=80=99ll be sure to include some pictures of diffs.</div><div><br></div>=
<div>Base specifiers don=E2=80=99t seem to be part of this package.</div></=
div></blockquote><div><br></div></span><div>FWIW, I&#39;d be opposed to thi=
s proposal if it suggests changing mem-initializers but not base-specifiers=
.. If we want to allow optional commas after comma-separated lists, we shoul=
d allow that consistently, especially between constructs that deliberately =
have similar grammar productions.</div><div><br></div><div>(Take a look at =
the implementation of any class that implements multiple MS COM interfaces =
for a motivating example for allowing trailing commas in base specifiers.)<=
/div></div></div></div></span><div><div><span class=3D"HOEnZb"><font color=
=3D"#888888">

<p></p>

-- <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/I8N_75J9ZB8/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/I8N_75J9ZB8=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.</font></span><span class=3D""><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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</span></div></div></blockquote></div><br></div><div class=3D"HOEnZb"><div =
class=3D"h5">

<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" 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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a11346d9c09630b051c21f53d--

.

--Apple-Mail=_9F824D32-ABA8-433E-8786-5C5C60450011
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9307=E2=80=9331, at 9:09 AM, Arthur O'Dwyer <arthur.j.odwye=
r@gmail.com> wrote:
>=20
> In practice the rule seems to be, "Wait for consensus to form in favor of=
 trailing-comma in a specific construct, and then add just that one trailin=
g-comma production to the grammar."  But actually I can't think of any real=
 reason for anyone to object to trailing-comma in all of the above cases.

You=E2=80=99re already implicitly acknowledging it, but the only alternativ=
e is to wait for consensus to form in favor of adding trailing-comma in all=
 contexts.

Maybe taking the one case is a half-measure, but it doesn=E2=80=99t impede =
future progress. What will be the half-measure=E2=80=99s ultimate effect to=
ward allowing all the cases? The demand will increase (folks come to expect=
 more convenience) or decrease (the actual need has been satisfied). Either=
 way is fine in the end, but if we take the smaller proposal as a hostage t=
o negotiate for something bigger, the likely outcome is nothing, ever.

The slippery slope doesn=E2=80=99t end with commas, either. How about lists=
 of Boolean conditions; should trailing && and || operators get ignored too=
? It would just be ordinary postfix expression syntax.

Sure, there are plenty of cases where template or function arguments get li=
sted line by line, but those tend to verge on either EDSL territory or lang=
uage abuse. Likewise with any kind of statement that runs for many lines: I=
f you=E2=80=99re doing it all the time, you=E2=80=99re already accepting a =
loss of readability. It=E2=80=99s far less common than merely having severa=
l nonstatic members and several constructors that initialize them.

As for the cases with declarations (parameter lists and capture lists), the=
 better style is to write a one-line comment for each name, and put the lis=
t below that.

> Let's not start a flamewar right now, but just as a recreational puzzle, =
can anyone come up with a situation in which C++ currently uses comma as a =
separator (not the comma-operator) and where permitting "trailing comma" in=
 that situation would lead to grammatical ambiguity?

I don=E2=80=99t suppose the preprocessor counts :v) .

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

--Apple-Mail=_9F824D32-ABA8-433E-8786-5C5C60450011
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9307=
=E2=80=9331, at 9:09 AM, Arthur O'Dwyer &lt;<a href=3D"mailto:arthur.j.odwy=
er@gmail.com" class=3D"">arthur.j.odwyer@gmail.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div style=3D"font-fami=
ly: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; f=
ont-weight: normal; letter-spacing: normal; line-height: normal; orphans: a=
uto; text-align: start; text-indent: 0px; text-transform: none; white-space=
: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"=
 class=3D"">In practice the rule seems to be, "Wait for consensus to form i=
n favor of trailing-comma in a specific construct, and then add just that o=
ne trailing-comma production to the grammar." &nbsp;But actually I can't th=
ink of any real reason for anyone to object to trailing-comma in all of the=
 above cases.</div><div style=3D"font-family: Helvetica; font-size: 12px; f=
ont-style: normal; font-variant: normal; font-weight: normal; letter-spacin=
g: normal; line-height: normal; orphans: auto; text-align: start; text-inde=
nt: 0px; text-transform: none; white-space: normal; widows: auto; word-spac=
ing: 0px; -webkit-text-stroke-width: 0px;" class=3D""></div></div></blockqu=
ote><div><br class=3D""></div><div>You=E2=80=99re already implicitly acknow=
ledging it, but the only alternative is to wait for consensus to form in fa=
vor of adding trailing-comma in all contexts.</div><div><br class=3D""></di=
v><div>Maybe taking the one case is a half-measure, but it doesn=E2=80=99t =
impede future progress. What will be the half-measure=E2=80=99s ultimate ef=
fect toward allowing all the cases? The demand will increase (folks come to=
 expect more convenience) or decrease (the actual need has been satisfied).=
 Either way is fine in the end, but if we take the smaller proposal as a ho=
stage to negotiate for something bigger, the likely outcome is nothing, eve=
r.</div><div><br class=3D""></div><div>The slippery slope doesn=E2=80=99t e=
nd with commas, either. How about lists of Boolean conditions; should trail=
ing&nbsp;<font face=3D"Courier" class=3D"">&amp;&amp;</font> and <font face=
=3D"Courier" class=3D"">||</font> operators get ignored too? It would just =
be ordinary postfix expression syntax.</div><div><br class=3D""></div><div>=
Sure, there are plenty of cases where template or function arguments get li=
sted line by line, but those tend to verge on either EDSL territory or lang=
uage abuse. Likewise with any kind of statement that runs for many lines: I=
f you=E2=80=99re doing it all the time, you=E2=80=99re already accepting a =
loss of readability. It=E2=80=99s far less common than merely having severa=
l nonstatic members and several constructors that initialize them.</div><di=
v><br class=3D""></div><div>As for the cases with declarations (parameter l=
ists and capture lists), the better style is to write a one-line comment fo=
r each name, and put the list below that.</div><br class=3D""><blockquote t=
ype=3D"cite" class=3D""><div class=3D""><div style=3D"font-family: Helvetic=
a; font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; orphans: auto; text-al=
ign: start; text-indent: 0px; text-transform: none; white-space: normal; wi=
dows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D"">=
Let's not start a flamewar right now, but<span class=3D"Apple-converted-spa=
ce">&nbsp;</span><b class=3D""><i class=3D"">just as a recreational puzzle,=
</i></b><span class=3D"Apple-converted-space">&nbsp;</span>can anyone come =
up with a situation in which C++ currently uses comma as a separator (not t=
he comma-operator) and where permitting "trailing comma" in that situation =
would lead to grammatical ambiguity?</div></div></blockquote><br class=3D""=
></div><div>I don=E2=80=99t suppose the preprocessor counts :v) .</div><br =
class=3D""></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 />

--Apple-Mail=_9F824D32-ABA8-433E-8786-5C5C60450011--

.

On Thu, Jul 30, 2015 at 06:09:21PM -0700, Arthur O'Dwyer wrote:
> Richard's comment seems eminently reasonable to me.
> https://github.com/cplusplus/draft/compare/master...Quuxplusone:mem_initializer_list_comma
>
> I wish it were easy to come up with a black-and-white separation between
> these kinds of changes and the slippery slope that leads to flamewars over
> whether to permit
>
>     auto x = f(
>         1,
>         2,  // and here
>     );
>
> In practice the rule seems to be, "Wait for consensus to form in favor of
> trailing-comma in a specific construct, and then add just that one
> trailing-comma production to the grammar."  But actually I can't think of
> any real reason for anyone to object to trailing-comma in all of the above
> cases.
>
> Let's not start a flamewar right now, but *just as a recreational puzzle,*
> can anyone come up with a situation in which C++ currently uses comma as a
> separator (not the comma-operator) and where permitting "trailing comma" in
> that situation would lead to grammatical ambiguity?

In another thread there was a suggestion that

f(a, , c) should use the default argument for the second parameter to f.

If we at the same time says that trailing commas in functions might be
ignored then that would make the overload resolution rules more complicated.

Consider:

int g(short a, int = 0);
int g(long a);

....

int x = g(17,);

Today g(17) is ambiguous.
With the empty parameter means default rule g(17,) would be well defined.
With the ignore comma rule g(17,) would be ambigous.

In conclusion I think ignored commas in function arguments prevents other
possibilities.

/MF

--

---
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 31.07.2015 um 07:11 schrieb Magnus Fromreide:
> On Thu, Jul 30, 2015 at 06:09:21PM -0700, Arthur O'Dwyer wrote:
>> Richard's comment seems eminently reasonable to me.
>> https://github.com/cplusplus/draft/compare/master...Quuxplusone:mem_initializer_list_comma
>>
>> I wish it were easy to come up with a black-and-white separation between
>> these kinds of changes and the slippery slope that leads to flamewars over
>> whether to permit
>>
>>      auto x = f(
>>          1,
>>          2,  // and here
>>      );
>>
>> In practice the rule seems to be, "Wait for consensus to form in favor of
>> trailing-comma in a specific construct, and then add just that one
>> trailing-comma production to the grammar."  But actually I can't think of
>> any real reason for anyone to object to trailing-comma in all of the above
>> cases.
>>
>> Let's not start a flamewar right now, but *just as a recreational puzzle,*
>> can anyone come up with a situation in which C++ currently uses comma as a
>> separator (not the comma-operator) and where permitting "trailing comma" in
>> that situation would lead to grammatical ambiguity?
> In another thread there was a suggestion that
>
> f(a, , c) should use the default argument for the second parameter to f.
>
> If we at the same time says that trailing commas in functions might be
> ignored then that would make the overload resolution rules more complicated.
>
> Consider:
>
> int g(short a, int = 0);
> int g(long a);
>
> ...
>
> int x = g(17,);
>
> Today g(17) is ambiguous.
> With the empty parameter means default rule g(17,) would be well defined.
> With the ignore comma rule g(17,) would be ambigous.
>
> In conclusion I think ignored commas in function arguments prevents other
> possibilities.
>
> /MF
>
g(17, default)
Problem solved?
This proposal isn't about ignoring arbitrary commas, only the last one
in a comma-separated list where the commas are not the comma-operator.
The suggestion you're quoting here is in my oppinion waaaaay too subtle
and is very prone to accidental copy/paste errors.

--

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

.