Topic: Omitting multiple access specifiers in base-specifier
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 29 Jul 2015 17:17:15 +0300
Raw View
On 29 July 2015 at 17:06, Arthur Tchaikovsky <atch.cpp@gmail.com> wrote:
> It is in the same spirit that is: *make things uniform*.
We make things uniform when it makes sense, not because uniformity
is always automatically good.
> 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
> {
> };
What for? To make it easier to use multiple bases with different accesses?
Not being able to do that tersely doesn't sound like bug to me, that sounds like
a feature.
>
>
> 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> 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/.
.
Author: Arthur Tchaikovsky <atch.cpp@gmail.com>
Date: Wed, 29 Jul 2015 08:36:45 -0700 (PDT)
Raw View
------=_Part_5703_1300145522.1438184205613
Content-Type: multipart/alternative;
boundary="----=_Part_5704_1691679868.1438184205613"
------=_Part_5704_1691679868.1438184205613
Content-Type: text/plain; charset=UTF-8
I tend to disagree with that statement. Uniformity (in programming
language) is always good. It means, one thing less to remember in this
correct example.
And surely it does make sense to have identical syntax for declaring how we
are inheriting from and how we encapsulate members? Why would that doesn't
make sense? And why would that be a feature as you call it?
To reverse this scenario and show how bad it looks at the moment, how would
you feel if we would have to do this each time we declare member:
class X
{
public:
A a;
public:
B b;
public:
C c;
};
Surely there is something wrong with the above approach isn't it? If the
answer to the question is yes, then the way we are inheriting at the moment
is exactly the same example and should be modernized so we specify
inheritance modifier only once, not each time.
On Wednesday, 29 July 2015 15:17:16 UTC+1, Ville Voutilainen wrote:
>
> On 29 July 2015 at 17:06, Arthur Tchaikovsky <atch...@gmail.com
> <javascript:>> wrote:
> > It is in the same spirit that is: *make things uniform*.
>
> We make things uniform when it makes sense, not because uniformity
> is always automatically good.
>
> > 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
> > {
> > };
>
> What for? To make it easier to use multiple bases with different accesses?
> Not being able to do that tersely doesn't sound like bug to me, that
> sounds like
> a feature.
>
> >
> >
> > 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>
> 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_5704_1691679868.1438184205613
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I tend to disagree with that statement. Uniformity (in pro=
gramming language) is always good. It means, one thing less to remember in =
this correct example.<br>And surely it does make sense to have identical sy=
ntax for declaring how we are inheriting from and how we encapsulate member=
s? Why would that doesn't make sense? And why would that be a feature a=
s you call it?<br>To reverse this scenario and show how bad it looks at the=
moment, how would you feel if we would have to do this each time we declar=
e member:<br><br>class X<br>{<br>public:<br>A a;<br>public:<br>B b;<br>publ=
ic:<br>C c;<br>};<br><br>Surely there is something wrong with the above app=
roach isn't it? If the answer to the question is yes, then the way we a=
re inheriting at the moment is exactly the same example and should be moder=
nized so we specify inheritance modifier only once, not each time.<br><br>O=
n Wednesday, 29 July 2015 15:17:16 UTC+1, Ville Voutilainen wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">On 29 July 2015 at 17:06, Arthur Tchai=
kovsky <<a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" onmou=
sedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.h=
ref=3D'javascript:';return true;">atch...@gmail.com</a>> wrote:
<br>> It is in the same spirit that is: *make things uniform*.
<br>
<br>We make things uniform when it makes sense, not because uniformity
<br>is always automatically good.
<br>
<br>> 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't we do the same whilst declaring what classes we are =
inheriting
<br>> from:
<br>> class X: public: A,B,C;<-- here A,B,C would be publicly inherit=
ed
<br>> {
<br>> };
<br>
<br>What for? To make it easier to use multiple bases with different access=
es?
<br>Not being able to do that tersely doesn't sound like bug to me, tha=
t sounds like
<br>a feature.
<br>
<br>>
<br>>
<br>> On Wednesday, 29 July 2015 13:43:19 UTC+1, Ville Voutilainen wrote=
:
<br>>>
<br>>> On 29 July 2015 at 13:34, Arthur Tchaikovsky <<a>atch...@gm=
ail.com</a>> wrote:
<br>>> > Hi Ville,
<br>>> > So in the same spirit, why can't we have (in the sake=
of consistency)
<br>>> > similar construct allowed:
<br>>> > class X: public: A,B,C; protected D,E,F
<br>>>
<br>>> That is not "in the same spirit", and I fail to see =
the consistency
<br>>> argument.
<br>>> That idea has very little to do with a trailing comma in any l=
ist, and
<br>>> its motivation
<br>>> would seem completely different.
<br>>>
<br>>> > {
<br>>> > public:
<br>>> > A a;
<br>>> > B b;
<br>>> > C c;
<br>>> > protected:
<br>>> > D d;
<br>>> > E e;
<br>>> > F f;
<br>>> > };
<br>>> >
<br>>> > The point ^^^ here is that we are inheriting in similar m=
anner to
<br>>> > classifying access level of members of a class, that is, =
we are stating
<br>>> > only
<br>>> > once the desired inheritance level, not every time as we =
are obliged to
<br>>> > do
<br>>> > now, unless we inheriting privately.
<br>>> > This change is:
<br>>> > a) Non breaking existing code
<br>>> > b) Makes class declaration more uniform
<br>>>
<br>>>
<br>>> But as has been mentioned, multiple base classes are much rare=
r than
<br>>> multiple
<br>>> non-static data members, so the motivation for such a thing se=
ems 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" 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_5704_1691679868.1438184205613--
------=_Part_5703_1300145522.1438184205613--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 29 Jul 2015 18:40:58 +0300
Raw View
On 29 July 2015 at 18:36, Arthur Tchaikovsky <atch.cpp@gmail.com> wrote:
> I tend to disagree with that statement. Uniformity (in programming language)
> is always good. It means, one thing less to remember in this correct
Unless it's false uniformity, which is the case here.
> And surely it does make sense to have identical syntax for declaring how we
> are inheriting from and how we encapsulate members? Why would that doesn't
How so? Base classes and members are different in many ways, including
how frequently they are used.
> To reverse this scenario and show how bad it looks at the moment, how would
> you feel if we would have to do this each time we declare member:
>
> class X
> {
> public:
> A a;
> public:
> B b;
> public:
> C c;
> };
>
> Surely there is something wrong with the above approach isn't it? If the
Is there? Various other languages do it that way. C++ doesn't, so "how would you
feel" is a hypothetical question. I don't have to write member declarations that
way, and I see no problems in having to repeat access specifiers for
base classes,
compared to the cost of providing a fairly pointless shortcut for them.
> answer to the question is yes, then the way we are inheriting at the moment
> is exactly the same example and should be modernized so we specify
> inheritance modifier only once, not each time.
I fail to see the point of such an exercise.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 29 Jul 2015 11:45:14 -0400
Raw View
--001a11340b0608eba4051c05798c
Content-Type: text/plain; charset=UTF-8
You can argue whether it is uniform or not, but I don't think it matters:
1. multiple inheritance isn't that common, and multiple inheritance with
differing access is less so. Therefore is it worth committee time?
2. maybe I'm just old and my eyes are failing, but I don't like it when a
single character changes that much meaning;
class X : public A, B, C
{
};
class X : public: A, B, C
{
};
I guess maybe the semi-colon you put at the end helps, although I also find
that semi-colon superfluous (and also easy to miss).
Overall, it just doesn't seem worth it to me.
On Wed, Jul 29, 2015 at 11:36 AM, Arthur Tchaikovsky <atch.cpp@gmail.com>
wrote:
> I tend to disagree with that statement. Uniformity (in programming
> language) is always good. It means, one thing less to remember in this
> correct example.
> And surely it does make sense to have identical syntax for declaring how
> we are inheriting from and how we encapsulate members? Why would that
> doesn't make sense? And why would that be a feature as you call it?
> To reverse this scenario and show how bad it looks at the moment, how
> would you feel if we would have to do this each time we declare member:
>
> class X
> {
> public:
> A a;
> public:
> B b;
> public:
> C c;
> };
>
> Surely there is something wrong with the above approach isn't it? If the
> answer to the question is yes, then the way we are inheriting at the moment
> is exactly the same example and should be modernized so we specify
> inheritance modifier only once, not each time.
>
> On Wednesday, 29 July 2015 15:17:16 UTC+1, Ville Voutilainen wrote:
>
>> On 29 July 2015 at 17:06, Arthur Tchaikovsky <atch...@gmail.com> wrote:
>> > It is in the same spirit that is: *make things uniform*.
>>
>> We make things uniform when it makes sense, not because uniformity
>> is always automatically good.
>>
>> > 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
>> > {
>> > };
>>
>> What for? To make it easier to use multiple bases with different
>> accesses?
>> Not being able to do that tersely doesn't sound like bug to me, that
>> sounds like
>> a feature.
>>
>> >
>> >
>> > 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>
>> 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/.
>
--
---
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/.
--001a11340b0608eba4051c05798c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div><div>You can argue whether it is =
uniform or not, but I don't think it matters:<br><br></div>1. multiple =
inheritance isn't that common, and multiple inheritance with differing =
access is less so. Therefore is it worth committee time?<br></div>2. maybe =
I'm just old and my eyes are failing, but I don't like it when a si=
ngle character changes that much meaning;<br><br></div>class X : public A, =
B, C<br>{<br>};<br><br></div>class X : public: A, B, C<br>{<br>};<br><br></=
div>I guess maybe the semi-colon you put at the end helps, although I also =
find that semi-colon superfluous (and also easy to miss).<br><br></div>Over=
all, it just doesn't seem worth it to me.<br>=C2=A0<br></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Jul 29, 2015 at 11:=
36 AM, Arthur Tchaikovsky <span dir=3D"ltr"><<a href=3D"mailto:atch.cpp@=
gmail.com" target=3D"_blank">atch.cpp@gmail.com</a>></span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr">I tend to disagree with that =
statement. Uniformity (in programming language) is always good. It means, o=
ne thing less to remember in this correct example.<br>And surely it does ma=
ke sense to have identical syntax for declaring how we are inheriting from =
and how we encapsulate members? Why would that doesn't make sense? And =
why would that be a feature as you call it?<br>To reverse this scenario and=
show how bad it looks at the moment, how would you feel if we would have t=
o do this each time we declare member:<br><br>class X<br>{<br>public:<br>A =
a;<br>public:<br>B b;<br>public:<br>C c;<br>};<br><br>Surely there is somet=
hing wrong with the above approach isn't it? If the answer to the quest=
ion is yes, then the way we are inheriting at the moment is exactly the sam=
e example and should be modernized so we specify inheritance modifier only =
once, not each time.<br><br>On Wednesday, 29 July 2015 15:17:16 UTC+1, Vill=
e Voutilainen wrote:<div><div class=3D"h5"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">On 29 July 2015 at 17:06, Arthur Tchaikovsky <<a rel=3D"nofollo=
w">atch...@gmail.com</a>> wrote:
<br>> It is in the same spirit that is: *make things uniform*.
<br>
<br>We make things uniform when it makes sense, not because uniformity
<br>is always automatically good.
<br>
<br>> 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't we do the same whilst declaring what classes we are =
inheriting
<br>> from:
<br>> class X: public: A,B,C;<-- here A,B,C would be publicly inherit=
ed
<br>> {
<br>> };
<br>
<br>What for? To make it easier to use multiple bases with different access=
es?
<br>Not being able to do that tersely doesn't sound like bug to me, tha=
t sounds like
<br>a feature.
<br>
<br>>
<br>>
<br>> On Wednesday, 29 July 2015 13:43:19 UTC+1, Ville Voutilainen wrote=
:
<br>>>
<br>>> On 29 July 2015 at 13:34, Arthur Tchaikovsky <<a>atch...@gm=
ail.com</a>> wrote:
<br>>> > Hi Ville,
<br>>> > So in the same spirit, why can't we have (in the sake=
of consistency)
<br>>> > similar construct allowed:
<br>>> > class X: public: A,B,C; protected D,E,F
<br>>>
<br>>> That is not "in the same spirit", and I fail to see =
the consistency
<br>>> argument.
<br>>> That idea has very little to do with a trailing comma in any l=
ist, and
<br>>> its motivation
<br>>> would seem completely different.
<br>>>
<br>>> > {
<br>>> > public:
<br>>> > A a;
<br>>> > B b;
<br>>> > C c;
<br>>> > protected:
<br>>> > D d;
<br>>> > E e;
<br>>> > F f;
<br>>> > };
<br>>> >
<br>>> > The point ^^^ here is that we are inheriting in similar m=
anner to
<br>>> > classifying access level of members of a class, that is, =
we are stating
<br>>> > only
<br>>> > once the desired inheritance level, not every time as we =
are obliged to
<br>>> > do
<br>>> > now, unless we inheriting privately.
<br>>> > This change is:
<br>>> > a) Non breaking existing code
<br>>> > b) Makes class declaration more uniform
<br>>>
<br>>>
<br>>> But as has been mentioned, multiple base classes are much rare=
r than
<br>>> multiple
<br>>> non-static data members, so the motivation for such a thing se=
ems weak.
<br></blockquote></div></div></div><div><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" group.<br></div></div>
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" 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 />
--001a11340b0608eba4051c05798c--
.
Author: Arthur Tchaikovsky <atch.cpp@gmail.com>
Date: Wed, 29 Jul 2015 08:47:14 -0700 (PDT)
Raw View
------=_Part_576_532689384.1438184834302
Content-Type: multipart/alternative;
boundary="----=_Part_577_931744115.1438184834303"
------=_Part_577_931744115.1438184834303
Content-Type: text/plain; charset=UTF-8
No, it is not false uniformity as you stating it. If the way of inheriting
is identical to the way of encapsulating members, this is uniform way of
doing things. There is no other way to see it.
And if you still saying that it is false uniformity, could you please
expand on that?
On Wednesday, 29 July 2015 16:40:59 UTC+1, Ville Voutilainen wrote:
>
> On 29 July 2015 at 18:36, Arthur Tchaikovsky <atch...@gmail.com
> <javascript:>> wrote:
> > I tend to disagree with that statement. Uniformity (in programming
> language)
> > is always good. It means, one thing less to remember in this correct
>
> Unless it's false uniformity, which is the case here.
> > And surely it does make sense to have identical syntax for declaring how
> we
> > are inheriting from and how we encapsulate members? Why would that
> doesn't
>
> How so? Base classes and members are different in many ways, including
> how frequently they are used.
>
> > To reverse this scenario and show how bad it looks at the moment, how
> would
> > you feel if we would have to do this each time we declare member:
> >
> > class X
> > {
> > public:
> > A a;
> > public:
> > B b;
> > public:
> > C c;
> > };
> >
> > Surely there is something wrong with the above approach isn't it? If the
>
> Is there? Various other languages do it that way. C++ doesn't, so "how
> would you
> feel" is a hypothetical question. I don't have to write member
> declarations that
> way, and I see no problems in having to repeat access specifiers for
> base classes,
> compared to the cost of providing a fairly pointless shortcut for them.
>
> > answer to the question is yes, then the way we are inheriting at the
> moment
> > is exactly the same example and should be modernized so we specify
> > inheritance modifier only once, not each time.
>
> I fail to see the point of such an exercise.
>
--
---
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_577_931744115.1438184834303
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">No, it is not false uniformity as you stating it. If the w=
ay of inheriting is identical to the way of encapsulating members, this is =
uniform way of doing things. There is no other way to see it.<br>And if you=
still saying that it is false uniformity, could you please expand on that?=
<br><br>On Wednesday, 29 July 2015 16:40:59 UTC+1, Ville Voutilainen wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">On 29 July 2015 at 18:36, Art=
hur Tchaikovsky <<a href=3D"javascript:" target=3D"_blank" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">atch...@gmail.com</a>&g=
t; wrote:
<br>> I tend to disagree with that statement. Uniformity (in programming=
language)
<br>> is always good. It means, one thing less to remember in this corre=
ct
<br>
<br>Unless it's false uniformity, which is the case here.
<br>> And surely it does make sense to have identical syntax for declari=
ng how we
<br>> are inheriting from and how we encapsulate members? Why would that=
doesn't
<br>
<br>How so? Base classes and members are different in many ways, including
<br>how frequently they are used.
<br>
<br>> To reverse this scenario and show how bad it looks at the moment, =
how would
<br>> you feel if we would have to do this each time we declare member:
<br>>
<br>> class X
<br>> {
<br>> public:
<br>> A a;
<br>> public:
<br>> B b;
<br>> public:
<br>> C c;
<br>> };
<br>>
<br>> Surely there is something wrong with the above approach isn't =
it? If the
<br>
<br>Is there? Various other languages do it that way. C++ doesn't, so &=
quot;how would you
<br>feel" is a hypothetical question. I don't have to write member=
declarations that
<br>way, and I see no problems in having to repeat access specifiers for
<br>base classes,
<br>compared to the cost of providing a fairly pointless shortcut for them.
<br>
<br>> answer to the question is yes, then the way we are inheriting at t=
he moment
<br>> is exactly the same example and should be modernized so we specify
<br>> inheritance modifier only once, not each time.
<br>
<br>I fail to see the point of such an exercise.
<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" 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_577_931744115.1438184834303--
------=_Part_576_532689384.1438184834302--
.
Author: Arthur Tchaikovsky <atch.cpp@gmail.com>
Date: Wed, 29 Jul 2015 08:58:54 -0700 (PDT)
Raw View
------=_Part_3414_263714685.1438185534155
Content-Type: multipart/alternative;
boundary="----=_Part_3415_2100124725.1438185534155"
------=_Part_3415_2100124725.1438185534155
Content-Type: text/plain; charset=UTF-8
Well, apart from the fact that it would bring C++ one step closer of having
more uniform syntax, which is good right? It would also make things neater,
without breaking any existing code, which is good right?
And I am really very sorry for your poor eyes' state, but this cannot be an
argument. If that was the case, why type font like this is even aIIowed to
exist? Did you spot the way l misspelled allowed?
I'm sorry, but either we do want to make C++ cleaner and easier to learn or
not and we just doing semi baked attempts like so called *uniform*
initialization, which need I remind you, not only removed problem of
initialization in C++, but on top of that it introduced one more way of
initializing. How perverted is this?
On Wednesday, 29 July 2015 16:45:16 UTC+1, Tony V E wrote:
>
> You can argue whether it is uniform or not, but I don't think it matters:
>
> 1. multiple inheritance isn't that common, and multiple inheritance with
> differing access is less so. Therefore is it worth committee time?
> 2. maybe I'm just old and my eyes are failing, but I don't like it when a
> single character changes that much meaning;
>
> class X : public A, B, C
> {
> };
>
> class X : public: A, B, C
> {
> };
>
> I guess maybe the semi-colon you put at the end helps, although I also
> find that semi-colon superfluous (and also easy to miss).
>
> Overall, it just doesn't seem worth it to me.
>
>
> On Wed, Jul 29, 2015 at 11:36 AM, Arthur Tchaikovsky <atch...@gmail.com
> <javascript:>> wrote:
>
>> I tend to disagree with that statement. Uniformity (in programming
>> language) is always good. It means, one thing less to remember in this
>> correct example.
>> And surely it does make sense to have identical syntax for declaring how
>> we are inheriting from and how we encapsulate members? Why would that
>> doesn't make sense? And why would that be a feature as you call it?
>> To reverse this scenario and show how bad it looks at the moment, how
>> would you feel if we would have to do this each time we declare member:
>>
>> class X
>> {
>> public:
>> A a;
>> public:
>> B b;
>> public:
>> C c;
>> };
>>
>> Surely there is something wrong with the above approach isn't it? If the
>> answer to the question is yes, then the way we are inheriting at the moment
>> is exactly the same example and should be modernized so we specify
>> inheritance modifier only once, not each time.
>>
>> On Wednesday, 29 July 2015 15:17:16 UTC+1, Ville Voutilainen wrote:
>>
>>> On 29 July 2015 at 17:06, Arthur Tchaikovsky <atch...@gmail.com> wrote:
>>> > It is in the same spirit that is: *make things uniform*.
>>>
>>> We make things uniform when it makes sense, not because uniformity
>>> is always automatically good.
>>>
>>> > 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
>>> > {
>>> > };
>>>
>>> What for? To make it easier to use multiple bases with different
>>> accesses?
>>> Not being able to do that tersely doesn't sound like bug to me, that
>>> sounds like
>>> a feature.
>>>
>>> >
>>> >
>>> > 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>
>>> 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-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_3415_2100124725.1438185534155
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Well, apart from the fact that it would bring C++ one step=
closer of having more uniform syntax, which is good right? It would also m=
ake things neater, without breaking any existing code, which is good right?=
<br><br>And I am really very sorry for your poor eyes' state, but this =
cannot be an argument. If that was the case, why type font like this is eve=
n aIIowed to exist? Did you spot the way l misspelled allowed?<br>I'm s=
orry, but either we do want to make C++ cleaner and easier to learn or not =
and we just doing semi baked attempts like so called *uniform* initializati=
on, which need I remind you, not only removed problem of initialization in =
C++, but on top of that it introduced one more way of initializing. How per=
verted is this?<br><br>On Wednesday, 29 July 2015 16:45:16 UTC+1, Tony V E =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><=
div><div><div><div><div>You can argue whether it is uniform or not, but I d=
on't think it matters:<br><br></div>1. multiple inheritance isn't t=
hat common, and multiple inheritance with differing access is less so. Ther=
efore is it worth committee time?<br></div>2. maybe I'm just old and my=
eyes are failing, but I don't like it when a single character changes =
that much meaning;<br><br></div>class X : public A, B, C<br>{<br>};<br><br>=
</div>class X : public: A, B, C<br>{<br>};<br><br></div>I guess maybe the s=
emi-colon you put at the end helps, although I also find that semi-colon su=
perfluous (and also easy to miss).<br><br></div>Overall, it just doesn'=
t seem worth it to me.<br>=C2=A0<br></div><div><br><div class=3D"gmail_quot=
e">On Wed, Jul 29, 2015 at 11:36 AM, Arthur Tchaikovsky <span dir=3D"ltr">&=
lt;<a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">atch...@gmail.com</a>></span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I tend to disagree with=
that statement. Uniformity (in programming language) is always good. It me=
ans, one thing less to remember in this correct example.<br>And surely it d=
oes make sense to have identical syntax for declaring how we are inheriting=
from and how we encapsulate members? Why would that doesn't make sense=
? And why would that be a feature as you call it?<br>To reverse this scenar=
io and show how bad it looks at the moment, how would you feel if we would =
have to do this each time we declare member:<br><br>class X<br>{<br>public:=
<br>A a;<br>public:<br>B b;<br>public:<br>C c;<br>};<br><br>Surely there is=
something wrong with the above approach isn't it? If the answer to the=
question is yes, then the way we are inheriting at the moment is exactly t=
he same example and should be modernized so we specify inheritance modifier=
only once, not each time.<br><br>On Wednesday, 29 July 2015 15:17:16 UTC+1=
, Ville Voutilainen wrote:<div><div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
">On 29 July 2015 at 17:06, Arthur Tchaikovsky <<a rel=3D"nofollow">atch=
....@gmail.com</a>> wrote:
<br>> It is in the same spirit that is: *make things uniform*.
<br>
<br>We make things uniform when it makes sense, not because uniformity
<br>is always automatically good.
<br>
<br>> 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't we do the same whilst declaring what classes we are =
inheriting
<br>> from:
<br>> class X: public: A,B,C;<-- here A,B,C would be publicly inherit=
ed
<br>> {
<br>> };
<br>
<br>What for? To make it easier to use multiple bases with different access=
es?
<br>Not being able to do that tersely doesn't sound like bug to me, tha=
t sounds like
<br>a feature.
<br>
<br>>
<br>>
<br>> On Wednesday, 29 July 2015 13:43:19 UTC+1, Ville Voutilainen wrote=
:
<br>>>
<br>>> On 29 July 2015 at 13:34, Arthur Tchaikovsky <<a>atch...@gm=
ail.com</a>> wrote:
<br>>> > Hi Ville,
<br>>> > So in the same spirit, why can't we have (in the sake=
of consistency)
<br>>> > similar construct allowed:
<br>>> > class X: public: A,B,C; protected D,E,F
<br>>>
<br>>> That is not "in the same spirit", and I fail to see =
the consistency
<br>>> argument.
<br>>> That idea has very little to do with a trailing comma in any l=
ist, and
<br>>> its motivation
<br>>> would seem completely different.
<br>>>
<br>>> > {
<br>>> > public:
<br>>> > A a;
<br>>> > B b;
<br>>> > C c;
<br>>> > protected:
<br>>> > D d;
<br>>> > E e;
<br>>> > F f;
<br>>> > };
<br>>> >
<br>>> > The point ^^^ here is that we are inheriting in similar m=
anner to
<br>>> > classifying access level of members of a class, that is, =
we are stating
<br>>> > only
<br>>> > once the desired inheritance level, not every time as we =
are obliged to
<br>>> > do
<br>>> > now, unless we inheriting privately.
<br>>> > This change is:
<br>>> > a) Non breaking existing code
<br>>> > b) Makes class declaration more uniform
<br>>>
<br>>>
<br>>> But as has been mentioned, multiple base classes are much rare=
r than
<br>>> multiple
<br>>> non-static data members, so the motivation for such a thing se=
ems weak.
<br></blockquote></div></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" group.<br></div></div>
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'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';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'javascript:';retur=
n true;" onclick=3D"this.href=3D'javascript:';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'http://groups.google.com/a/isocpp.org/group/std-proposals/';ret=
urn true;" onclick=3D"this.href=3D'http://groups.google.com/a/isocpp.or=
g/group/std-proposals/';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" 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_3415_2100124725.1438185534155--
------=_Part_3414_263714685.1438185534155--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Wed, 29 Jul 2015 13:35:43 -0300
Raw View
On Wed, Jul 29, 2015 at 11:17 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 29 July 2015 at 17:06, Arthur Tchaikovsky <atch.cpp@gmail.com> wrote:
>> It is in the same spirit that is: *make things uniform*.
>
> We make things uniform when it makes sense, not because uniformity
> is always automatically good.
I'd like to bring the old questions for the proposal criteria:
* WHAT is the problem you are trying to solve?
* WHY this is a problem, and who is affected?
* How is people working around this problem?
* What's the REAL BENEFIT of the solution?
Unless I see convincing answers, I consider this a useless single-guy capri=
ce.
>
>> 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
>> {
>> };
>
> What for? To make it easier to use multiple bases with different accesses=
?
> Not being able to do that tersely doesn't sound like bug to me, that soun=
ds like
> a feature.
>
>>
>>
>> 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> 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 stati=
ng
>>> > 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-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/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 29 Jul 2015 19:50:54 +0300
Raw View
On 29 July 2015 at 19:35, dgutson . <danielgutson@gmail.com> wrote:
> Unless I see convincing answers, I consider this a useless single-guy caprice.
Also, this is yet another rinse-and-repeat of a discussion that lead to nowhere
the last time:
https://groups.google.com/a/isocpp.org/d/msg/std-discussion/nd0OFYBxvP0/TPmsQfck2MEJ
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 29 Jul 2015 13:05:16 -0400
Raw View
On 2015-07-29 11:58, Arthur Tchaikovsky wrote:
> And I am really very sorry for your poor eyes' state, but this cannot be an
> argument.
I disagree, and encourage you to read
https://en.wikipedia.org/wiki/Code_golf (and in particular, inspect some
samples) before making an argument that easy readability should not be a
concern.
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Arthur Tchaikovsky <atch.cpp@gmail.com>
Date: Wed, 29 Jul 2015 10:18:21 -0700 (PDT)
Raw View
------=_Part_650_1550504188.1438190301499
Content-Type: multipart/alternative;
boundary="----=_Part_651_588356090.1438190301500"
------=_Part_651_588356090.1438190301500
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
* WHAT is the problem you are trying to solve?=20
The problem is that at the moment we have two different way of doing same=
=20
things, that is specifying access, different to a class member and=20
different to a base class.
* WHY this is a problem, and who is affected?=20
The problem is that as lots of things in C++ it is non-uniform and so=20
following introduces yet another thing to learn.
* How is people working around this problem?=20
They simply use the existing rules
* What's the REAL BENEFIT of the solution?=20
I believe that the real long-term benefit of it is that in the future C++=
=20
would have nice, uniform syntax and would be much easier to learn.
On Wednesday, 29 July 2015 17:35:44 UTC+1, dgutson wrote:
>
> On Wed, Jul 29, 2015 at 11:17 AM, Ville Voutilainen=20
> <ville.vo...@gmail.com <javascript:>> wrote:=20
> > On 29 July 2015 at 17:06, Arthur Tchaikovsky <atch...@gmail.com=20
> <javascript:>> wrote:=20
> >> It is in the same spirit that is: *make things uniform*.=20
> >=20
> > We make things uniform when it makes sense, not because uniformity=20
> > is always automatically good.=20
>
> I'd like to bring the old questions for the proposal criteria:=20
>
> * WHAT is the problem you are trying to solve?=20
> * WHY this is a problem, and who is affected?=20
> * How is people working around this problem?=20
> * What's the REAL BENEFIT of the solution?=20
>
> Unless I see convincing answers, I consider this a useless single-guy=20
> caprice.=20
>
> >=20
> >> The consistency argument is:=20
> >> if in declaration of a class we can:=20
> >>=20
> >> public:=20
> >> A a;=20
> >> B b;=20
> >>=20
> >> Why can't we do the same whilst declaring what classes we are=20
> inheriting=20
> >> from:=20
> >> class X: public: A,B,C;<-- here A,B,C would be publicly inherited=20
> >> {=20
> >> };=20
> >=20
> > What for? To make it easier to use multiple bases with different=20
> accesses?=20
> > Not being able to do that tersely doesn't sound like bug to me, that=20
> sounds like=20
> > a feature.=20
> >=20
> >>=20
> >>=20
> >> On Wednesday, 29 July 2015 13:43:19 UTC+1, Ville Voutilainen wrote:=20
> >>>=20
> >>> On 29 July 2015 at 13:34, Arthur Tchaikovsky <atch...@gmail.com>=20
> wrote:=20
> >>> > Hi Ville,=20
> >>> > So in the same spirit, why can't we have (in the sake of=20
> consistency)=20
> >>> > similar construct allowed:=20
> >>> > class X: public: A,B,C; protected D,E,F=20
> >>>=20
> >>> That is not "in the same spirit", and I fail to see the consistency=
=20
> >>> argument.=20
> >>> That idea has very little to do with a trailing comma in any list, an=
d=20
> >>> its motivation=20
> >>> would seem completely different.=20
> >>>=20
> >>> > {=20
> >>> > public:=20
> >>> > A a;=20
> >>> > B b;=20
> >>> > C c;=20
> >>> > protected:=20
> >>> > D d;=20
> >>> > E e;=20
> >>> > F f;=20
> >>> > };=20
> >>> >=20
> >>> > 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=20
> stating=20
> >>> > only=20
> >>> > once the desired inheritance level, not every time as we are oblige=
d=20
> to=20
> >>> > do=20
> >>> > now, unless we inheriting privately.=20
> >>> > This change is:=20
> >>> > a) Non breaking existing code=20
> >>> > b) Makes class declaration more uniform=20
> >>>=20
> >>>=20
> >>> But as has been mentioned, multiple base classes are much rarer than=
=20
> >>> multiple=20
> >>> non-static data members, so the motivation for such a thing seems=20
> weak.=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_651_588356090.1438190301500
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">* WHAT is the problem you are trying to solve?
<br>The problem is that at the moment we have two different way of doing sa=
me things, that is specifying access, different to a class member and diffe=
rent to a base class.<br>* WHY this is a problem, and who is affected?
<br>The problem is that as lots of things in C++ it is non-uniform and so f=
ollowing introduces yet another thing to learn.<br>* How is people working =
around this problem?
<br>They simply use the existing rules<br>* What's the REAL BENEFIT of =
the solution?
<br>I believe that the real long-term benefit of it is that in the future C=
++ would have nice, uniform syntax and would be much easier to learn.<br><b=
r>On Wednesday, 29 July 2015 17:35:44 UTC+1, dgutson wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">On Wed, Jul 29, 2015 at 11:17 AM, Ville Vouti=
lainen
<br><<a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" onmoused=
own=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">ville.vo...@gmail.com</a>> wrote:
<br>> On 29 July 2015 at 17:06, Arthur Tchaikovsky <<a href=3D"javasc=
ript:" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'j=
avascript:';return true;" onclick=3D"this.href=3D'javascript:';=
return true;">atch...@gmail.com</a>> wrote:
<br>>> It is in the same spirit that is: *make things uniform*.
<br>>
<br>> We make things uniform when it makes sense, not because uniformity
<br>> is always automatically good.
<br>
<br>I'd like to bring the old questions for the proposal criteria:
<br>
<br>* WHAT is the problem you are trying to solve?
<br>* WHY this is a problem, and who is affected?
<br>* How is people working around this problem?
<br>* What's the REAL BENEFIT of the solution?
<br>
<br>Unless I see convincing answers, I consider this a useless single-guy c=
aprice.
<br>
<br>>
<br>>> 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't we do the same whilst declaring what classes we =
are inheriting
<br>>> from:
<br>>> class X: public: A,B,C;<-- here A,B,C would be publicly inh=
erited
<br>>> {
<br>>> };
<br>>
<br>> What for? To make it easier to use multiple bases with different a=
ccesses?
<br>> Not being able to do that tersely doesn't sound like bug to me=
, that sounds like
<br>> a feature.
<br>>
<br>>>
<br>>>
<br>>> On Wednesday, 29 July 2015 13:43:19 UTC+1, Ville Voutilainen w=
rote:
<br>>>>
<br>>>> On 29 July 2015 at 13:34, Arthur Tchaikovsky <<a>atch..=
..@gmail.com</a>> wrote:
<br>>>> > Hi Ville,
<br>>>> > So in the same spirit, why can't we have (in the =
sake of consistency)
<br>>>> > similar construct allowed:
<br>>>> > class X: public: A,B,C; protected D,E,F
<br>>>>
<br>>>> That is not "in the same spirit", and I fail to =
see the consistency
<br>>>> argument.
<br>>>> That idea has very little to do with a trailing comma in a=
ny list, and
<br>>>> its motivation
<br>>>> would seem completely different.
<br>>>>
<br>>>> > {
<br>>>> > public:
<br>>>> > A a;
<br>>>> > B b;
<br>>>> > C c;
<br>>>> > protected:
<br>>>> > D d;
<br>>>> > E e;
<br>>>> > F f;
<br>>>> > };
<br>>>> >
<br>>>> > The point ^^^ here is that we are inheriting in simil=
ar manner to
<br>>>> > classifying access level of members of a class, that =
is, we are stating
<br>>>> > only
<br>>>> > once the desired inheritance level, not every time as=
we are obliged to
<br>>>> > do
<br>>>> > now, unless we inheriting privately.
<br>>>> > This change is:
<br>>>> > a) Non breaking existing code
<br>>>> > b) Makes class declaration more uniform
<br>>>>
<br>>>>
<br>>>> But as has been mentioned, multiple base classes are much =
rarer than
<br>>>> multiple
<br>>>> non-static data members, so the motivation for such a thin=
g seems weak.
<br>>
<br>> --
<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 href=3D"javascript:" target=3D"_blank" rel=3D"nofollow"=
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"=
this.href=3D'javascript:';return true;">std-proposal...@isocpp.org<=
/a>.
<br>> To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&#=
39;;return true;" onclick=3D"this.href=3D'javascript:';return true;=
">std-pr...@isocpp.org</a>.
<br>> 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'http://groups.google.com/a/isocpp.org/group/std-proposals/=
';return true;" onclick=3D"this.href=3D'http://groups.google.com/a/=
isocpp.org/group/std-proposals/';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's never wrong but always right?
<br>Who'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" 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_588356090.1438190301500--
------=_Part_650_1550504188.1438190301499--
.
Author: Arthur Tchaikovsky <atch.cpp@gmail.com>
Date: Wed, 29 Jul 2015 10:24:37 -0700 (PDT)
Raw View
------=_Part_5445_876563070.1438190677963
Content-Type: multipart/alternative;
boundary="----=_Part_5446_2023653751.1438190677964"
------=_Part_5446_2023653751.1438190677964
Content-Type: text/plain; charset=UTF-8
Easy readability should be a *great* concern, but you totally missed my
point, because I was referring to poor eyesight. And I'm sorry to say but
poor eyesight must not be an argument for not using commas, semicolons,
braces that are only tad different to brackets etc.
On Wednesday, 29 July 2015 18:05:28 UTC+1, Matthew Woehlke wrote:
>
> On 2015-07-29 11:58, Arthur Tchaikovsky wrote:
> > And I am really very sorry for your poor eyes' state, but this cannot be
> an
> > argument.
>
> I disagree, and encourage you to read
> https://en.wikipedia.org/wiki/Code_golf (and in particular, inspect some
> samples) before making an argument that easy readability should not be a
> concern.
>
> --
> 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_5446_2023653751.1438190677964
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Easy readability should be a *great* concern, but you tota=
lly missed my point, because I was referring to poor eyesight. And I'm =
sorry to say but poor eyesight must not be an argument for not using commas=
, semicolons, braces that are only tad different to brackets etc.<br><br>On=
Wednesday, 29 July 2015 18:05:28 UTC+1, Matthew Woehlke wrote:<blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">On 2015-07-29 11:58, Arthur Tchaikovsky w=
rote:
<br>> And I am really very sorry for your poor eyes' state, but this=
cannot be an=20
<br>> argument.
<br>
<br>I disagree, and encourage you to read
<br><a href=3D"https://en.wikipedia.org/wiki/Code_golf" target=3D"_blank" r=
el=3D"nofollow" onmousedown=3D"this.href=3D'https://www.google.com/url?=
q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCode_golf\46sa\75D\46sntz\0751\=
46usg\75AFQjCNEI6U8VP0Bx0-DrrCuhBVJSvvZ8JQ';return true;" onclick=3D"th=
is.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.or=
g%2Fwiki%2FCode_golf\46sa\75D\46sntz\0751\46usg\75AFQjCNEI6U8VP0Bx0-DrrCuhB=
VJSvvZ8JQ';return true;">https://en.wikipedia.org/wiki/Code_golf</a> (a=
nd in particular, inspect some
<br>samples) before making an argument that easy readability should not be =
a
<br>concern.
<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" 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_5446_2023653751.1438190677964--
------=_Part_5445_876563070.1438190677963--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 29 Jul 2015 13:38:16 -0400
Raw View
On 2015-07-29 13:24, Arthur Tchaikovsky wrote:
> Easy readability should be a *great* concern, but you totally missed my
> point, because I was referring to poor eyesight.
No, I didn't; I fail to see the distinction. The latter merely increases
sensitivity to the former.
> And I'm sorry to say but poor eyesight must not be an argument for
> not using commas, semicolons, braces that are only tad different to
> brackets etc.
(Also, I hope you realize that such comments are rather poor taste...)
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Arthur Tchaikovsky <atch.cpp@gmail.com>
Date: Thu, 30 Jul 2015 03:10:58 -0700 (PDT)
Raw View
------=_Part_6181_1994930033.1438251058137
Content-Type: multipart/alternative;
boundary="----=_Part_6182_312907069.1438251058137"
------=_Part_6182_312907069.1438251058137
Content-Type: text/plain; charset=UTF-8
If you fail to see the distinction between code being readable and poor
eyesight then am afraid there is nothing I can do about it.
On Wednesday, 29 July 2015 18:38:32 UTC+1, Matthew Woehlke wrote:
>
> On 2015-07-29 13:24, Arthur Tchaikovsky wrote:
> > Easy readability should be a *great* concern, but you totally missed my
> > point, because I was referring to poor eyesight.
>
> No, I didn't; I fail to see the distinction. The latter merely increases
> sensitivity to the former.
>
> > And I'm sorry to say but poor eyesight must not be an argument for
> > not using commas, semicolons, braces that are only tad different to
> > brackets etc.
>
> (Also, I hope you realize that such comments are rather poor taste...)
>
> --
> 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_6182_312907069.1438251058137
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">If you fail to see the distinction between code being read=
able and poor eyesight then am afraid there is nothing I can do about it.<b=
r><br>On Wednesday, 29 July 2015 18:38:32 UTC+1, Matthew Woehlke wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">On 2015-07-29 13:24, Arthur Tchai=
kovsky wrote:
<br>> Easy readability should be a *great* concern, but you totally miss=
ed my=20
<br>> point, because I was referring to poor eyesight.
<br>
<br>No, I didn't; I fail to see the distinction. The latter merely incr=
eases
<br>sensitivity to the former.
<br>
<br>> And I'm sorry to say but poor eyesight must not be an argument=
for
<br>> not using commas, semicolons, braces that are only tad different t=
o
<br>> brackets etc.
<br>
<br>(Also, I hope you realize that such comments are rather poor taste...)
<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" 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_6182_312907069.1438251058137--
------=_Part_6181_1994930033.1438251058137--
.
Author: Arthur Tchaikovsky <atch.cpp@gmail.com>
Date: Thu, 30 Jul 2015 03:11:32 -0700 (PDT)
Raw View
------=_Part_287_1159177590.1438251092688
Content-Type: multipart/alternative;
boundary="----=_Part_288_1969518107.1438251092688"
------=_Part_288_1969518107.1438251092688
Content-Type: text/plain; charset=UTF-8
Mind to elaborate on that?
On Wednesday, 29 July 2015 18:38:32 UTC+1, Matthew Woehlke wrote:
>
>
> > And I'm sorry to say but poor eyesight must not be an argument for
> > not using commas, semicolons, braces that are only tad different to
> > brackets etc.
>
> (Also, I hope you realize that such comments are rather poor taste...)
>
> --
> 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_288_1969518107.1438251092688
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Mind to elaborate on that?<br><br>On Wednesday, 29 July 20=
15 18:38:32 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;"><br>> And I'm sorry to say but poor eyesight must not be=
an argument for
<br>> not using commas, semicolons, braces that are only tad different t=
o
<br>> brackets etc.
<br>
<br>(Also, I hope you realize that such comments are rather poor taste...)
<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" 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_288_1969518107.1438251092688--
------=_Part_287_1159177590.1438251092688--
.
Author: Arthur Tchaikovsky <atch.cpp@gmail.com>
Date: Thu, 30 Jul 2015 03:13:06 -0700 (PDT)
Raw View
------=_Part_18_584618919.1438251186340
Content-Type: multipart/alternative;
boundary="----=_Part_19_849357047.1438251186340"
------=_Part_19_849357047.1438251186340
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi, I'd appreciate if you would reply to my post in which I answer to the=
=20
questions put forward by you.
Thank you.
On Wednesday, 29 July 2015 17:35:44 UTC+1, dgutson wrote:
>
> On Wed, Jul 29, 2015 at 11:17 AM, Ville Voutilainen=20
> <ville.vo...@gmail.com <javascript:>> wrote:=20
> > On 29 July 2015 at 17:06, Arthur Tchaikovsky <atch...@gmail.com=20
> <javascript:>> wrote:=20
> >> It is in the same spirit that is: *make things uniform*.=20
> >=20
> > We make things uniform when it makes sense, not because uniformity=20
> > is always automatically good.=20
>
> I'd like to bring the old questions for the proposal criteria:=20
>
> * WHAT is the problem you are trying to solve?=20
> * WHY this is a problem, and who is affected?=20
> * How is people working around this problem?=20
> * What's the REAL BENEFIT of the solution?=20
>
> Unless I see convincing answers, I consider this a useless single-guy=20
> caprice.=20
>
> >=20
> >> The consistency argument is:=20
> >> if in declaration of a class we can:=20
> >>=20
> >> public:=20
> >> A a;=20
> >> B b;=20
> >>=20
> >> Why can't we do the same whilst declaring what classes we are=20
> inheriting=20
> >> from:=20
> >> class X: public: A,B,C;<-- here A,B,C would be publicly inherited=20
> >> {=20
> >> };=20
> >=20
> > What for? To make it easier to use multiple bases with different=20
> accesses?=20
> > Not being able to do that tersely doesn't sound like bug to me, that=20
> sounds like=20
> > a feature.=20
> >=20
> >>=20
> >>=20
> >> On Wednesday, 29 July 2015 13:43:19 UTC+1, Ville Voutilainen wrote:=20
> >>>=20
> >>> On 29 July 2015 at 13:34, Arthur Tchaikovsky <atch...@gmail.com>=20
> wrote:=20
> >>> > Hi Ville,=20
> >>> > So in the same spirit, why can't we have (in the sake of=20
> consistency)=20
> >>> > similar construct allowed:=20
> >>> > class X: public: A,B,C; protected D,E,F=20
> >>>=20
> >>> That is not "in the same spirit", and I fail to see the consistency=
=20
> >>> argument.=20
> >>> That idea has very little to do with a trailing comma in any list, an=
d=20
> >>> its motivation=20
> >>> would seem completely different.=20
> >>>=20
> >>> > {=20
> >>> > public:=20
> >>> > A a;=20
> >>> > B b;=20
> >>> > C c;=20
> >>> > protected:=20
> >>> > D d;=20
> >>> > E e;=20
> >>> > F f;=20
> >>> > };=20
> >>> >=20
> >>> > 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=20
> stating=20
> >>> > only=20
> >>> > once the desired inheritance level, not every time as we are oblige=
d=20
> to=20
> >>> > do=20
> >>> > now, unless we inheriting privately.=20
> >>> > This change is:=20
> >>> > a) Non breaking existing code=20
> >>> > b) Makes class declaration more uniform=20
> >>>=20
> >>>=20
> >>> But as has been mentioned, multiple base classes are much rarer than=
=20
> >>> multiple=20
> >>> non-static data members, so the motivation for such a thing seems=20
> weak.=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_19_849357047.1438251186340
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi, I'd appreciate if you would reply to my post in wh=
ich I answer to the questions put forward by you.<br><br>Thank you.<br><br>=
On Wednesday, 29 July 2015 17:35:44 UTC+1, dgutson wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">On Wed, Jul 29, 2015 at 11:17 AM, Ville Voutila=
inen
<br><<a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" onmoused=
own=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">ville.vo...@gmail.com</a>> wrote:
<br>> On 29 July 2015 at 17:06, Arthur Tchaikovsky <<a href=3D"javasc=
ript:" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'j=
avascript:';return true;" onclick=3D"this.href=3D'javascript:';=
return true;">atch...@gmail.com</a>> wrote:
<br>>> It is in the same spirit that is: *make things uniform*.
<br>>
<br>> We make things uniform when it makes sense, not because uniformity
<br>> is always automatically good.
<br>
<br>I'd like to bring the old questions for the proposal criteria:
<br>
<br>* WHAT is the problem you are trying to solve?
<br>* WHY this is a problem, and who is affected?
<br>* How is people working around this problem?
<br>* What's the REAL BENEFIT of the solution?
<br>
<br>Unless I see convincing answers, I consider this a useless single-guy c=
aprice.
<br>
<br>>
<br>>> 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't we do the same whilst declaring what classes we =
are inheriting
<br>>> from:
<br>>> class X: public: A,B,C;<-- here A,B,C would be publicly inh=
erited
<br>>> {
<br>>> };
<br>>
<br>> What for? To make it easier to use multiple bases with different a=
ccesses?
<br>> Not being able to do that tersely doesn't sound like bug to me=
, that sounds like
<br>> a feature.
<br>>
<br>>>
<br>>>
<br>>> On Wednesday, 29 July 2015 13:43:19 UTC+1, Ville Voutilainen w=
rote:
<br>>>>
<br>>>> On 29 July 2015 at 13:34, Arthur Tchaikovsky <<a>atch..=
..@gmail.com</a>> wrote:
<br>>>> > Hi Ville,
<br>>>> > So in the same spirit, why can't we have (in the =
sake of consistency)
<br>>>> > similar construct allowed:
<br>>>> > class X: public: A,B,C; protected D,E,F
<br>>>>
<br>>>> That is not "in the same spirit", and I fail to =
see the consistency
<br>>>> argument.
<br>>>> That idea has very little to do with a trailing comma in a=
ny list, and
<br>>>> its motivation
<br>>>> would seem completely different.
<br>>>>
<br>>>> > {
<br>>>> > public:
<br>>>> > A a;
<br>>>> > B b;
<br>>>> > C c;
<br>>>> > protected:
<br>>>> > D d;
<br>>>> > E e;
<br>>>> > F f;
<br>>>> > };
<br>>>> >
<br>>>> > The point ^^^ here is that we are inheriting in simil=
ar manner to
<br>>>> > classifying access level of members of a class, that =
is, we are stating
<br>>>> > only
<br>>>> > once the desired inheritance level, not every time as=
we are obliged to
<br>>>> > do
<br>>>> > now, unless we inheriting privately.
<br>>>> > This change is:
<br>>>> > a) Non breaking existing code
<br>>>> > b) Makes class declaration more uniform
<br>>>>
<br>>>>
<br>>>> But as has been mentioned, multiple base classes are much =
rarer than
<br>>>> multiple
<br>>>> non-static data members, so the motivation for such a thin=
g seems weak.
<br>>
<br>> --
<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 href=3D"javascript:" target=3D"_blank" rel=3D"nofollow"=
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"=
this.href=3D'javascript:';return true;">std-proposal...@isocpp.org<=
/a>.
<br>> To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&#=
39;;return true;" onclick=3D"this.href=3D'javascript:';return true;=
">std-pr...@isocpp.org</a>.
<br>> 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'http://groups.google.com/a/isocpp.org/group/std-proposals/=
';return true;" onclick=3D"this.href=3D'http://groups.google.com/a/=
isocpp.org/group/std-proposals/';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's never wrong but always right?
<br>Who'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" 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_19_849357047.1438251186340--
------=_Part_18_584618919.1438251186340--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 30 Jul 2015 11:47:30 -0400
Raw View
On 2015-07-30 06:10, Arthur Tchaikovsky wrote:
> On Wednesday, 29 July 2015 18:38:32 UTC+1, Matthew Woehlke wrote:
>> On 2015-07-29 13:24, Arthur Tchaikovsky wrote:
>>> Easy readability should be a *great* concern, but you totally missed my
>>> point, because I was referring to poor eyesight.
>>
>> No, I didn't; I fail to see the distinction. The latter merely increases
>> sensitivity to the former.
>
> If you fail to see the distinction between code being readable and poor
> eyesight then am afraid there is nothing I can do about it.
If you fail to see why there IS NOT a distinction, then I am afraid
there may be nothing I can do about that.
Oh, well, I'll try anyway...
Wiktionary doesn't give a great definition of readability, but
essentially it can be defined as "the property of being easy to read and
understand". As such, "readability" means (among other things) that
significant ideas are clearly conveyed with obvious markings that are
easily differentiated.
Readability can be improved by various techniques such as syntax-aware
coloring, which improves readability by increasing the visual indicators
that indicate syntax, by using distinctive symbols or markings to convey
significant ideas that are easily differentiated from other markings
conveying other ideas, and by appropriate use of white space. It can be
hampered by lack of such indicators, poor font choices, use of subtle
marks that are more easily overlooked to convey significant ideas, and
so forth.
(As an example, consider 'foo(a.b)' vs. 'foo(a,b)'. With my font and
screen, there is exactly *one pixel* difference between the two, yet
they have significantly different meanings. Readability here is
significantly improved by adding a space after the ',', which markedly
increases the visual distinction between the two differing ideas.)
Subjective readability is also strongly influenced by a particular
individual's visual acuity. (Objective readability would obviously not
take into account individualistic variations. Therefore, objective
readability must still consider issues such as color and font choice but
can consider only the objectively measurable information presented and
not how a particular individual perceives that information. It should be
clear, then, why my previous comment about poor eyesight increasing
sensitivity to readability corresponds to how such condition relates
subjective and objective readability.)
Using subtle marks to convey significant information content, as in your
proposal, is dubious readability even in an objective sense.
If you disagree with this point, then I can only assume that you are a
huge fan of code golf and think all code should be expressed as
succinctly as possible, and who cares if it is hard to tell what is
happening.
>>> And I'm sorry to say but poor eyesight must not be an argument for
>>> not using commas, semicolons, braces that are only tad different to
>>> brackets etc.
>>
>> (Also, I hope you realize that such comments are rather poor taste...)
>
> Mind to elaborate on that?
You have indicated that you do not value Tony's opinions because he has
a physical infirmity. (I should say you have declared his opinion
*invalid*.) I find that insensitive and mildly offensive. I wouldn't be
surprised if Tony's feelings are similar and less mild.
<sarcasm>
After all, we shouldn't have ramps for public buildings, or "accessible"
public bathrooms, because the fact that some people have physical
disabilities is no reason to care about them, right?
</sarcasm>
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 30 Jul 2015 19:43:34 +0300
Raw View
On 30 July 2015 at 18:47, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>> If you fail to see the distinction between code being readable and poor
>> eyesight then am afraid there is nothing I can do about it.
> If you fail to see why there IS NOT a distinction, then I am afraid
> there may be nothing I can do about that.
> Oh, well, I'll try anyway...
*ok*. Now, when it comes to omitting multiple access-specifiers in a
base-specifier
list, that idea didn't get any support the last time it was tried two
years ago, doesn't
seem to get any support now, is unlikely to result in a proposal, and
any such proposal
is very unlikely to be accepted by the committee. So what exactly is
the point of
rehashing it further, especially if it turns to a completely unrelated
discussion?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Arthur Tchaikovsky <atch.cpp@gmail.com>
Date: Thu, 30 Jul 2015 10:54:14 -0700 (PDT)
Raw View
------=_Part_4448_2126222909.1438278854811
Content-Type: multipart/alternative;
boundary="----=_Part_4449_1030609219.1438278854811"
------=_Part_4449_1030609219.1438278854811
Content-Type: text/plain; charset=UTF-8
The point is that I (even after two years) still believe that this idea is
a good idea and simply missed opportunity for C++ being more uniform. And I
would ask committee members to try to look at this *proposal* in a cool,
unprejudiced manner and see/think about the benefits of it that I've
listed. Also, how it is neatly and simply make the declaration of class
clean and yes, I will repeat myself, uniform.
Also, I'd ask committee members to list the negative sides of this
proposal, but for the love of God don't say that people who's eyesight is
poor may have problems with reading the code, example:
vector<int> vec(10);
vector<int> vec{10};
If the argument above would have right to exist, the code above should be
never allowed to exist, because of these unfortunates with poor eyesight.
I'm not trying to be awkward, or anything like that, I simply believe that
what I'm proposing would only do good to C++.
Thank you.
On Thursday, 30 July 2015 17:43:36 UTC+1, Ville Voutilainen wrote:
>
> On 30 July 2015 at 18:47, Matthew Woehlke <mwoehlk...@gmail.com
> <javascript:>> wrote:
> >> If you fail to see the distinction between code being readable and poor
> >> eyesight then am afraid there is nothing I can do about it.
> > If you fail to see why there IS NOT a distinction, then I am afraid
> > there may be nothing I can do about that.
> > Oh, well, I'll try anyway...
>
> *ok*. Now, when it comes to omitting multiple access-specifiers in a
> base-specifier
> list, that idea didn't get any support the last time it was tried two
> years ago, doesn't
> seem to get any support now, is unlikely to result in a proposal, and
> any such proposal
> is very unlikely to be accepted by the committee. So what exactly is
> the point of
> rehashing it further, especially if it turns to a completely unrelated
> discussion?
>
--
---
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_4449_1030609219.1438278854811
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The point is that I (even after two years) still believe t=
hat this idea is a good idea and simply missed opportunity for C++ being mo=
re uniform. And I would ask committee members to try to look at this *propo=
sal* in a cool, unprejudiced manner and see/think about the benefits of it =
that I've listed. Also, how it is neatly and simply make the declaratio=
n of class clean and yes, I will repeat myself, uniform.<br><br>Also, I'=
;d ask committee members to list the negative sides of this proposal, but f=
or the love of God don't say that people who's eyesight is poor may=
have problems with reading the code, example:<br><br>vector<int> vec=
(10);<br>vector<int> vec{10};<br><br>If the argument above would have=
right to exist, the code above should be never allowed to exist, because o=
f these unfortunates with poor eyesight.<br><br>I'm not trying to be aw=
kward, or anything like that, I simply believe that what I'm proposing =
would only do good to C++.<br><br>Thank you.<br><br>On Thursday, 30 July 20=
15 17:43:36 UTC+1, Ville Voutilainen wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">On 30 July 2015 at 18:47, Matthew Woehlke <<a href=3D"java=
script:" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
;javascript:';return true;" onclick=3D"this.href=3D'javascript:'=
;;return true;">mwoehlk...@gmail.com</a>> wrote:
<br>>> If you fail to see the distinction between code being readable=
and poor
<br>>> eyesight then am afraid there is nothing I can do about it.
<br>> If you fail to see why there IS NOT a distinction, then I am afrai=
d
<br>> there may be nothing I can do about that.
<br>> Oh, well, I'll try anyway...
<br>
<br>*ok*. Now, when it comes to omitting multiple access-specifiers in a
<br>base-specifier
<br>list, that idea didn't get any support the last time it was tried t=
wo
<br>years ago, doesn't
<br>seem to get any support now, is unlikely to result in a proposal, and
<br>any such proposal
<br>is very unlikely to be accepted by the committee. So what exactly is
<br>the point of
<br>rehashing it further, especially if it turns to a completely unrelated
<br>discussion?
<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" 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_4449_1030609219.1438278854811--
------=_Part_4448_2126222909.1438278854811--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 30 Jul 2015 21:02:07 +0300
Raw View
On 30 July 2015 at 20:54, Arthur Tchaikovsky <atch.cpp@gmail.com> wrote:
> The point is that I (even after two years) still believe that this idea is a
> good idea and simply missed opportunity for C++ being more uniform. And I
> would ask committee members to try to look at this *proposal* in a cool,
> unprejudiced manner and see/think about the benefits of it that I've listed.
> Also, how it is neatly and simply make the declaration of class clean and
> yes, I will repeat myself, uniform.
> Also, I'd ask committee members to list the negative sides of this proposal,
It introduces an alternative way to write a base-specifier list,
without the possibility
of getting rid of the legacy syntax (due to our wanting to avoid
breaking such code),
thus adding a fairly pointless alternative syntax for a language
facility that is
not used all that often. All that has been said both in this
discussion and the earlier
one. There's nothing new proposed that would change any of that. The chance
of such a proposal being accepted by the committee is, as I said, slim. One
could say bringing it to the committee is likely a waste of everybody's time.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Arthur Tchaikovsky <atch.cpp@gmail.com>
Date: Thu, 30 Jul 2015 11:06:27 -0700 (PDT)
Raw View
------=_Part_5422_1915044264.1438279587585
Content-Type: multipart/alternative;
boundary="----=_Part_5423_273903489.1438279587585"
------=_Part_5423_273903489.1438279587585
Content-Type: text/plain; charset=UTF-8
Matthew
I'm really finding your insinuation that I don't care about impaired people
*mildly* offensive, and all of my arguments misunderstood. You do not read
what I say.
Yes, we should have ramps, and any other facilities to help those of us who
are less fortunate. But those facilities should be provide by appropriate
bodies. Surely you don't expect architects who design the building to
physically go and build those building, right? Same with people who work in
offices, you don't expect them to actually produce the furniture they use?
Yes, everyone needs/should be accommodated, but this accommodation *must*
be done by proper bodies.
C++ role IS NOT to make font type more readable. Can we agree on that one?
C++ role IS to make code more readable. Can we agree on that one?
Those two above DO NOT mean the same way as you seem to imply.
On Thursday, 30 July 2015 16:47:48 UTC+1, Matthew Woehlke wrote:
>
> On 2015-07-30 06:10, Arthur Tchaikovsky wrote:
> > On Wednesday, 29 July 2015 18:38:32 UTC+1, Matthew Woehlke wrote:
> >> On 2015-07-29 13:24, Arthur Tchaikovsky wrote:
> >>> Easy readability should be a *great* concern, but you totally missed
> my
> >>> point, because I was referring to poor eyesight.
> >>
> >> No, I didn't; I fail to see the distinction. The latter merely
> increases
> >> sensitivity to the former.
> >
> > If you fail to see the distinction between code being readable and poor
> > eyesight then am afraid there is nothing I can do about it.
>
> If you fail to see why there IS NOT a distinction, then I am afraid
> there may be nothing I can do about that.
>
> Oh, well, I'll try anyway...
>
> Wiktionary doesn't give a great definition of readability, but
> essentially it can be defined as "the property of being easy to read and
> understand". As such, "readability" means (among other things) that
> significant ideas are clearly conveyed with obvious markings that are
> easily differentiated.
>
> Readability can be improved by various techniques such as syntax-aware
> coloring, which improves readability by increasing the visual indicators
> that indicate syntax, by using distinctive symbols or markings to convey
> significant ideas that are easily differentiated from other markings
> conveying other ideas, and by appropriate use of white space. It can be
> hampered by lack of such indicators, poor font choices, use of subtle
> marks that are more easily overlooked to convey significant ideas, and
> so forth.
>
> (As an example, consider 'foo(a.b)' vs. 'foo(a,b)'. With my font and
> screen, there is exactly *one pixel* difference between the two, yet
> they have significantly different meanings. Readability here is
> significantly improved by adding a space after the ',', which markedly
> increases the visual distinction between the two differing ideas.)
>
> Subjective readability is also strongly influenced by a particular
> individual's visual acuity. (Objective readability would obviously not
> take into account individualistic variations. Therefore, objective
> readability must still consider issues such as color and font choice but
> can consider only the objectively measurable information presented and
> not how a particular individual perceives that information. It should be
> clear, then, why my previous comment about poor eyesight increasing
> sensitivity to readability corresponds to how such condition relates
> subjective and objective readability.)
>
> Using subtle marks to convey significant information content, as in your
> proposal, is dubious readability even in an objective sense.
>
> If you disagree with this point, then I can only assume that you are a
> huge fan of code golf and think all code should be expressed as
> succinctly as possible, and who cares if it is hard to tell what is
> happening.
>
> >>> And I'm sorry to say but poor eyesight must not be an argument for
> >>> not using commas, semicolons, braces that are only tad different to
> >>> brackets etc.
> >>
> >> (Also, I hope you realize that such comments are rather poor taste...)
> >
> > Mind to elaborate on that?
>
> You have indicated that you do not value Tony's opinions because he has
> a physical infirmity. (I should say you have declared his opinion
> *invalid*.) I find that insensitive and mildly offensive. I wouldn't be
> surprised if Tony's feelings are similar and less mild.
>
> <sarcasm>
> After all, we shouldn't have ramps for public buildings, or "accessible"
> public bathrooms, because the fact that some people have physical
> disabilities is no reason to care about them, right?
> </sarcasm>
>
> --
> 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_5423_273903489.1438279587585
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Matthew <br>I'm really finding your insinuation that I=
don't care about impaired people *mildly* offensive, and all of my arg=
uments misunderstood. You do not read what I say.<br>Yes, we should have ra=
mps, and any other facilities to help those of us who are less fortunate. B=
ut those facilities should be provide by appropriate bodies. Surely you don=
't expect architects who design the building to physically go and build=
those building, right? Same with people who work in offices, you don't=
expect them to actually produce the furniture they use?<br>Yes, everyone n=
eeds/should be accommodated, but this accommodation *must* be done by prope=
r bodies.<br><br>C++ role IS NOT to make font type more readable. Can we ag=
ree on that one?<br>C++ role IS to make code more readable. Can we agree on=
that one?<br>Those two above DO NOT mean the same way as you seem to imply=
..<br><br>On Thursday, 30 July 2015 16:47:48 UTC+1, Matthew Woehlke wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">On 2015-07-30 06:10, Arthur Tch=
aikovsky wrote:
<br>> On Wednesday, 29 July 2015 18:38:32 UTC+1, Matthew Woehlke wrote:
<br>>> On 2015-07-29 13:24, Arthur Tchaikovsky wrote:=20
<br>>>> Easy readability should be a *great* concern, but you tota=
lly missed my=20
<br>>>> point, because I was referring to poor eyesight.=20
<br>>>
<br>>> No, I didn't; I fail to see the distinction. The latter me=
rely increases=20
<br>>> sensitivity to the former.=20
<br>>
<br>> If you fail to see the distinction between code being readable and=
poor=20
<br>> eyesight then am afraid there is nothing I can do about it.
<br>
<br>If you fail to see why there IS NOT a distinction, then I am afraid
<br>there may be nothing I can do about that.
<br>
<br>Oh, well, I'll try anyway...
<br>
<br>Wiktionary doesn't give a great definition of readability, but
<br>essentially it can be defined as "the property of being easy to re=
ad and
<br>understand". As such, "readability" means (among other t=
hings) that
<br>significant ideas are clearly conveyed with obvious markings that are
<br>easily differentiated.
<br>
<br>Readability can be improved by various techniques such as syntax-aware
<br>coloring, which improves readability by increasing the visual indicator=
s
<br>that indicate syntax, by using distinctive symbols or markings to conve=
y
<br>significant ideas that are easily differentiated from other markings
<br>conveying other ideas, and by appropriate use of white space. It can be
<br>hampered by lack of such indicators, poor font choices, use of subtle
<br>marks that are more easily overlooked to convey significant ideas, and
<br>so forth.
<br>
<br>(As an example, consider 'foo(a.b)' vs. 'foo(a,b)'. Wit=
h my font and
<br>screen, there is exactly *one pixel* difference between the two, yet
<br>they have significantly different meanings. Readability here is
<br>significantly improved by adding a space after the ',', which m=
arkedly
<br>increases the visual distinction between the two differing ideas.)
<br>
<br>Subjective readability is also strongly influenced by a particular
<br>individual's visual acuity. (Objective readability would obviously =
not
<br>take into account individualistic variations. Therefore, objective
<br>readability must still consider issues such as color and font choice bu=
t
<br>can consider only the objectively measurable information presented and
<br>not how a particular individual perceives that information. It should b=
e
<br>clear, then, why my previous comment about poor eyesight increasing
<br>sensitivity to readability corresponds to how such condition relates
<br>subjective and objective readability.)
<br>
<br>Using subtle marks to convey significant information content, as in you=
r
<br>proposal, is dubious readability even in an objective sense.
<br>
<br>If you disagree with this point, then I can only assume that you are a
<br>huge fan of code golf and think all code should be expressed as
<br>succinctly as possible, and who cares if it is hard to tell what is
<br>happening.
<br>
<br>>>> And I'm sorry to say but poor eyesight must not be an =
argument for=20
<br>>>> not using commas, semicolons, braces that are only tad dif=
ferent to=20
<br>>>> brackets etc.=20
<br>>>
<br>>> (Also, I hope you realize that such comments are rather poor t=
aste...)=20
<br>>
<br>> Mind to elaborate on that?
<br>
<br>You have indicated that you do not value Tony's opinions because he=
has
<br>a physical infirmity. (I should say you have declared his opinion
<br>*invalid*.) I find that insensitive and mildly offensive. I wouldn'=
t be
<br>surprised if Tony's feelings are similar and less mild.
<br>
<br><sarcasm>
<br>After all, we shouldn't have ramps for public buildings, or "a=
ccessible"
<br>public bathrooms, because the fact that some people have physical
<br>disabilities is no reason to care about them, right?
<br></sarcasm>
<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" 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_5423_273903489.1438279587585--
------=_Part_5422_1915044264.1438279587585--
.
Author: Arthur Tchaikovsky <atch.cpp@gmail.com>
Date: Thu, 30 Jul 2015 11:09:47 -0700 (PDT)
Raw View
------=_Part_562_48313017.1438279787994
Content-Type: multipart/alternative;
boundary="----=_Part_563_1936537298.1438279787995"
------=_Part_563_1936537298.1438279787995
Content-Type: text/plain; charset=UTF-8
Just like
unique_ptr<int> ptr;
is another *alternative* way of saying
int* ptr;
Notice that the above also do not
gets rid of the legacy syntax (due to our wanting to avoid breaking such
code);
And there are plenty of other examples. Old code will not get broken, yet
new improved features get added. That's the whole idea.
I'm sorry but this is something that I cannot accept.
On Thursday, 30 July 2015 19:02:08 UTC+1, Ville Voutilainen wrote:
>
> On 30 July 2015 at 20:54, Arthur Tchaikovsky <atch...@gmail.com
> <javascript:>> wrote:
> > The point is that I (even after two years) still believe that this idea
> is a
> > good idea and simply missed opportunity for C++ being more uniform. And
> I
> > would ask committee members to try to look at this *proposal* in a cool,
> > unprejudiced manner and see/think about the benefits of it that I've
> listed.
> > Also, how it is neatly and simply make the declaration of class clean
> and
> > yes, I will repeat myself, uniform.
> > Also, I'd ask committee members to list the negative sides of this
> proposal,
>
> It introduces an alternative way to write a base-specifier list,
> without the possibility
> of getting rid of the legacy syntax (due to our wanting to avoid
> breaking such code),
> thus adding a fairly pointless alternative syntax for a language
> facility that is
> not used all that often. All that has been said both in this
> discussion and the earlier
> one. There's nothing new proposed that would change any of that. The
> chance
> of such a proposal being accepted by the committee is, as I said, slim.
> One
> could say bringing it to the committee is likely a waste of everybody's
> time.
>
--
---
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_563_1936537298.1438279787995
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Just like <br>unique_ptr<int> ptr;<br>is another *al=
ternative* way of saying<br>int* ptr;<br><br>Notice that the above also do =
not<br> gets rid of the legacy syntax (due to our wanting to avoid
breaking such code);<br><br>And there are plenty of other examples. Old cod=
e will not get broken, yet new improved features get added. That's the =
whole idea.<br><br>I'm sorry but this is something that I cannot accept=
..<br><br>On Thursday, 30 July 2015 19:02:08 UTC+1, Ville Voutilainen wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">On 30 July 2015 at 20:54, Art=
hur Tchaikovsky <<a href=3D"javascript:" target=3D"_blank" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">atch...@gmail.com</a>&g=
t; wrote:
<br>> The point is that I (even after two years) still believe that this=
idea is a
<br>> good idea and simply missed opportunity for C++ being more uniform=
.. And I
<br>> would ask committee members to try to look at this *proposal* in a=
cool,
<br>> unprejudiced manner and see/think about the benefits of it that I&=
#39;ve listed.
<br>> Also, how it is neatly and simply make the declaration of class cl=
ean and
<br>> yes, I will repeat myself, uniform.
<br>> Also, I'd ask committee members to list the negative sides of =
this proposal,
<br>
<br>It introduces an alternative way to write a base-specifier list,
<br>without the possibility
<br>of getting rid of the legacy syntax (due to our wanting to avoid
<br>breaking such code),
<br>thus adding a fairly pointless alternative syntax for a language
<br>facility that is
<br>not used all that often. All that has been said both in this
<br>discussion and the earlier
<br>one. There's nothing new proposed that would change any of that. Th=
e chance
<br>of such a proposal being accepted by the committee is, as I said, slim.=
One
<br>could say bringing it to the committee is likely a waste of everybody&#=
39;s time.
<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" 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_563_1936537298.1438279787995--
------=_Part_562_48313017.1438279787994--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 30 Jul 2015 21:13:07 +0300
Raw View
On 30 July 2015 at 21:09, Arthur Tchaikovsky <atch.cpp@gmail.com> wrote:
> Just like
> unique_ptr<int> ptr;
> is another *alternative* way of saying
> int* ptr;
It is nothing of the sort. If you want to keep pushing your ideas, get
your facts straight.
> And there are plenty of other examples. Old code will not get broken, yet
> new improved features get added. That's the whole idea.
It's questionable whether there's any improvement proposed here.
> I'm sorry but this is something that I cannot accept.
Uh-huh, and so what? I'll have no trouble finding National Bodies who will
oppose your proposal. As I said, bringing it to the committee will be a waste
of time.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 30 Jul 2015 14:34:54 -0400
Raw View
--001a113466c6ac502f051c1bf567
Content-Type: text/plain; charset=UTF-8
On Wed, Jul 29, 2015 at 11:58 AM, Arthur Tchaikovsky <atch.cpp@gmail.com>
wrote:
> Well, apart from the fact that it would bring C++ one step closer of
> having more uniform syntax, which is good right? It would also make things
> neater, without breaking any existing code, which is good right?
>
Your proposal would make it _sort of_ uniform. Obviously the two contexts
are still different, and you do different things. ie in one you declare
variables and functions, etc, and in the other you list base classes. And
the syntax still isn't uniform. To be more uniform, maybe you should
require semi-colons between the base classes, and/or have the access
modifier last until the next one:
// access modifier (with colon), should last until the next one?
class X : public: A, B, protected C, D
{
// wait, protected C didn't have a colon.
// Is D proctected because that was the last specifier, or private
because that is the default for a class, or public because that was the
last specifier with a colon?
};
// should use semi-colons, like variable declarations?
class X : public: A; B; private C; D
{
};
Your proposal still isn't uniform. (I think your syntax might be better
than the above, but it is not more uniform than the above. It is
selectively uniform.)
>
> And I am really very sorry for your poor eyes' state, but this cannot be
> an argument. If that was the case, why type font like this is even aIIowed
> to exist? Did you spot the way l misspelled allowed?
> I'm sorry, but either we do want to make C++ cleaner and easier to learn
> or not and we just doing semi baked attempts like so called *uniform*
> initialization, which need I remind you, not only removed problem of
> initialization in C++, but on top of that it introduced one more way of
> initializing. How perverted is this?
>
Forget about my eyes. That wasn't the point. Even with perfect eyesight,
I still don't like subtlety. I'd like it to be a bit more obvious.
You also left out my other point:
1. multiple inheritance isn't that common, and multiple inheritance with
differing access is less so. Therefore is it worth committee time?
If I completely agree that it is more uniform, I still don't think it is
worth the committee's time. Take the time it have been given so far, and
multiply that by 100. At least. Is it worth it? Would you personally
commit that much time to it?
Uniformity is awesome, and it does help with learning, but I think there
are other/better places to strive for it.
Tony
>
> On Wednesday, 29 July 2015 16:45:16 UTC+1, Tony V E wrote:
>>
>> You can argue whether it is uniform or not, but I don't think it matters:
>>
>> 1. multiple inheritance isn't that common, and multiple inheritance with
>> differing access is less so. Therefore is it worth committee time?
>> 2. maybe I'm just old and my eyes are failing, but I don't like it when a
>> single character changes that much meaning;
>>
>> class X : public A, B, C
>> {
>> };
>>
>> class X : public: A, B, C
>> {
>> };
>>
>> I guess maybe the semi-colon you put at the end helps, although I also
>> find that semi-colon superfluous (and also easy to miss).
>>
>> Overall, it just doesn't seem worth it to me.
>>
>>
>> On Wed, Jul 29, 2015 at 11:36 AM, Arthur Tchaikovsky <atch...@gmail.com>
>> wrote:
>>
>>> I tend to disagree with that statement. Uniformity (in programming
>>> language) is always good. It means, one thing less to remember in this
>>> correct example.
>>> And surely it does make sense to have identical syntax for declaring how
>>> we are inheriting from and how we encapsulate members? Why would that
>>> doesn't make sense? And why would that be a feature as you call it?
>>> To reverse this scenario and show how bad it looks at the moment, how
>>> would you feel if we would have to do this each time we declare member:
>>>
>>> class X
>>> {
>>> public:
>>> A a;
>>> public:
>>> B b;
>>> public:
>>> C c;
>>> };
>>>
>>> Surely there is something wrong with the above approach isn't it? If the
>>> answer to the question is yes, then the way we are inheriting at the moment
>>> is exactly the same example and should be modernized so we specify
>>> inheritance modifier only once, not each time.
>>>
>>> On Wednesday, 29 July 2015 15:17:16 UTC+1, Ville Voutilainen wrote:
>>>
>>>> On 29 July 2015 at 17:06, Arthur Tchaikovsky <atch...@gmail.com>
>>>> wrote:
>>>> > It is in the same spirit that is: *make things uniform*.
>>>>
>>>> We make things uniform when it makes sense, not because uniformity
>>>> is always automatically good.
>>>>
>>>> > 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
>>>> > {
>>>> > };
>>>>
>>>> What for? To make it easier to use multiple bases with different
>>>> accesses?
>>>> Not being able to do that tersely doesn't sound like bug to me, that
>>>> sounds like
>>>> a feature.
>>>>
>>>> >
>>>> >
>>>> > 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>
>>>> 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-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/.
>>>
>>
>> --
>
> ---
> 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/.
--001a113466c6ac502f051c1bf567
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Jul 29, 2015 at 11:58 AM, Arthur Tchaikovsky <span dir=3D"ltr">=
<<a href=3D"mailto:atch.cpp@gmail.com" target=3D"_blank">atch.cpp@gmail.=
com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
">Well, apart from the fact that it would bring C++ one step closer of havi=
ng more uniform syntax, which is good right? It would also make things neat=
er, without breaking any existing code, which is good right?<br></div></blo=
ckquote><div><br></div><div>Your proposal would make it _sort of_ uniform.=
=C2=A0 Obviously the two contexts are still different, and you do different=
things.=C2=A0 ie in one you declare variables and functions, etc, and in t=
he other you list base classes.=C2=A0 And the syntax still isn't unifor=
m. To be more uniform, maybe you should require semi-colons between the bas=
e classes, and/or have the access modifier last until the next one:<br><br>=
</div><div>// access modifier (with colon), should last until the next one?=
<br></div><div>class X : public: A, B, protected C, D<br>{<br></div><div>=
=C2=A0=C2=A0 // wait, protected C didn't have a colon.<br>=C2=A0=C2=A0 =
// Is D proctected because that was the last specifier, or private because =
that is the default for a class, or public because that was the last specif=
ier with a colon?<br></div><div>};<br></div><div>// should use semi-colons,=
like variable declarations?<br></div><div><div>class X : public: A; B; pri=
vate C; D<br>{<br>};<br><br></div><div>Your proposal still isn't unifor=
m. (I think your syntax might be better than the above, but it is not more =
uniform than the above.=C2=A0 It is selectively uniform.)<br></div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>And I am really ver=
y sorry for your poor eyes' state, but this cannot be an argument. If t=
hat was the case, why type font like this is even aIIowed to exist? Did you=
spot the way l misspelled allowed?<br>I'm sorry, but either we do want=
to make C++ cleaner and easier to learn or not and we just doing semi bake=
d attempts like so called *uniform* initialization, which need I remind you=
, not only removed problem of initialization in C++, but on top of that it =
introduced one more way of initializing. How perverted is this?<span class=
=3D""><br></span></div></blockquote><div><br><br></div><div>Forget about my=
eyes.=C2=A0 That wasn't the point.=C2=A0 Even with perfect eyesight, I=
still don't like subtlety. I'd like it to be a bit more obvious.<b=
r></div><div><br></div><div>You also left out my other point:<br><br><div><=
/div>1. multiple inheritance isn't that=20
common, and multiple inheritance with differing access is less so.=20
Therefore is it worth committee time?<br><br></div><div>If I completely agr=
ee that it is more uniform, I still don't think it is worth the committ=
ee's time.=C2=A0 Take the time it have been given so far, and multiply =
that by 100. At least.=C2=A0 Is it worth it?=C2=A0 Would you personally com=
mit that much time to it?<br><br></div><div>Uniformity is awesome, and it d=
oes help with learning, but I think there are other/better places to strive=
for it.<br><br></div><div>Tony<br><br></div><div>=C2=A0</div><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"><span class=3D""><br>On Wednesday, 29 Ju=
ly 2015 16:45:16 UTC+1, Tony V E wrote:</span><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><span class=3D""><div dir=3D"ltr"><div><div><div><div><div><div=
>You can argue whether it is uniform or not, but I don't think it matte=
rs:<br><br></div>1. multiple inheritance isn't that common, and multipl=
e inheritance with differing access is less so. Therefore is it worth commi=
ttee time?<br></div>2. maybe I'm just old and my eyes are failing, but =
I don't like it when a single character changes that much meaning;<br><=
br></div>class X : public A, B, C<br>{<br>};<br><br></div>class X : public:=
A, B, C<br>{<br>};<br><br></div>I guess maybe the semi-colon you put at th=
e end helps, although I also find that semi-colon superfluous (and also eas=
y to miss).<br><br></div>Overall, it just doesn't seem worth it to me.<=
br>=C2=A0<br></div></span><div><br><div class=3D"gmail_quote"><div><div cla=
ss=3D"h5">On Wed, Jul 29, 2015 at 11:36 AM, Arthur Tchaikovsky <span dir=3D=
"ltr"><<a rel=3D"nofollow">atch...@gmail.com</a>></span> wrote:<br></=
div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div dir=3D=
"ltr">I tend to disagree with that statement. Uniformity (in programming la=
nguage) is always good. It means, one thing less to remember in this correc=
t example.<br>And surely it does make sense to have identical syntax for de=
claring how we are inheriting from and how we encapsulate members? Why woul=
d that doesn't make sense? And why would that be a feature as you call =
it?<br>To reverse this scenario and show how bad it looks at the moment, ho=
w would you feel if we would have to do this each time we declare member:<b=
r><br>class X<br>{<br>public:<br>A a;<br>public:<br>B b;<br>public:<br>C c;=
<br>};<br><br>Surely there is something wrong with the above approach isn&#=
39;t it? If the answer to the question is yes, then the way we are inheriti=
ng at the moment is exactly the same example and should be modernized so we=
specify inheritance modifier only once, not each time.<br><br>On Wednesday=
, 29 July 2015 15:17:16 UTC+1, Ville Voutilainen wrote:<div><div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On 29 July 2015 at 17:06, Arthur Tchaikovsky=
<<a rel=3D"nofollow">atch...@gmail.com</a>> wrote:
<br>> It is in the same spirit that is: *make things uniform*.
<br>
<br>We make things uniform when it makes sense, not because uniformity
<br>is always automatically good.
<br>
<br>> 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't we do the same whilst declaring what classes we are =
inheriting
<br>> from:
<br>> class X: public: A,B,C;<-- here A,B,C would be publicly inherit=
ed
<br>> {
<br>> };
<br>
<br>What for? To make it easier to use multiple bases with different access=
es?
<br>Not being able to do that tersely doesn't sound like bug to me, tha=
t sounds like
<br>a feature.
<br>
<br>>
<br>>
<br>> On Wednesday, 29 July 2015 13:43:19 UTC+1, Ville Voutilainen wrote=
:
<br>>>
<br>>> On 29 July 2015 at 13:34, Arthur Tchaikovsky <<a>atch...@gm=
ail.com</a>> wrote:
<br>>> > Hi Ville,
<br>>> > So in the same spirit, why can't we have (in the sake=
of consistency)
<br>>> > similar construct allowed:
<br>>> > class X: public: A,B,C; protected D,E,F
<br>>>
<br>>> That is not "in the same spirit", and I fail to see =
the consistency
<br>>> argument.
<br>>> That idea has very little to do with a trailing comma in any l=
ist, and
<br>>> its motivation
<br>>> would seem completely different.
<br>>>
<br>>> > {
<br>>> > public:
<br>>> > A a;
<br>>> > B b;
<br>>> > C c;
<br>>> > protected:
<br>>> > D d;
<br>>> > E e;
<br>>> > F f;
<br>>> > };
<br>>> >
<br>>> > The point ^^^ here is that we are inheriting in similar m=
anner to
<br>>> > classifying access level of members of a class, that is, =
we are stating
<br>>> > only
<br>>> > once the desired inheritance level, not every time as we =
are obliged to
<br>>> > do
<br>>> > now, unless we inheriting privately.
<br>>> > This change is:
<br>>> > a) Non breaking existing code
<br>>> > b) Makes class declaration more uniform
<br>>>
<br>>>
<br>>> But as has been mentioned, multiple base classes are much rare=
r than
<br>>> multiple
<br>>> non-static data members, so the motivation for such a thing se=
ems weak.
<br></blockquote></div></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" group.<br></div></div></div>=
</div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span class=3D""><br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank">http://groups.google.com=
/a/isocpp.org/group/std-proposals/</a>.<br>
</span></blockquote></div><br></div>
</blockquote></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" 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" 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 />
--001a113466c6ac502f051c1bf567--
.
Author: Arthur Tchaikovsky <atch.cpp@gmail.com>
Date: Fri, 31 Jul 2015 08:23:03 -0700 (PDT)
Raw View
------=_Part_681_841463388.1438356183498
Content-Type: multipart/alternative;
boundary="----=_Part_682_1479310085.1438356183499"
------=_Part_682_1479310085.1438356183499
Content-Type: text/plain; charset=UTF-8
Hi Tony,
As much I respect your opinion, you cannot say that my proposed syntax is
_sort of_ uniform. It is uniform. It is orthogonal *one - to - one* with
internals of a class and how theirs access are specified. Example:
class X
{
public:
int a, b, c;
};
class X : public: A,B,C;
{
};
The point here is that:
a) there is a colon after access modifier, all separate base classes have
*the same* access modifier and are separated by comma and the statement of
declaring inheritance access modifier is ended with semicolon. This is
*exactly* one to one mapping. Not, _sort of_, not *false* as Ville was
implying, but *exact*, one to one mapping.
On Thursday, 30 July 2015 19:35:01 UTC+1, Tony V E wrote:
>
>
>
> On Wed, Jul 29, 2015 at 11:58 AM, Arthur Tchaikovsky <atch...@gmail.com
> <javascript:>> wrote:
>
>> Well, apart from the fact that it would bring C++ one step closer of
>> having more uniform syntax, which is good right? It would also make things
>> neater, without breaking any existing code, which is good right?
>>
>
> Your proposal would make it _sort of_ uniform. Obviously the two contexts
> are still different, and you do different things. ie in one you declare
> variables and functions, etc, and in the other you list base classes. And
> the syntax still isn't uniform. To be more uniform, maybe you should
> require semi-colons between the base classes, and/or have the access
> modifier last until the next one:
>
> // access modifier (with colon), should last until the next one?
> class X : public: A, B, protected C, D
> {
> // wait, protected C didn't have a colon.
> // Is D proctected because that was the last specifier, or private
> because that is the default for a class, or public because that was the
> last specifier with a colon?
> };
> // should use semi-colons, like variable declarations?
> class X : public: A; B; private C; D
> {
> };
>
> Your proposal still isn't uniform. (I think your syntax might be better
> than the above, but it is not more uniform than the above. It is
> selectively uniform.)
>
>
>>
>> And I am really very sorry for your poor eyes' state, but this cannot be
>> an argument. If that was the case, why type font like this is even aIIowed
>> to exist? Did you spot the way l misspelled allowed?
>> I'm sorry, but either we do want to make C++ cleaner and easier to learn
>> or not and we just doing semi baked attempts like so called *uniform*
>> initialization, which need I remind you, not only removed problem of
>> initialization in C++, but on top of that it introduced one more way of
>> initializing. How perverted is this?
>>
>
>
> Forget about my eyes. That wasn't the point. Even with perfect eyesight,
> I still don't like subtlety. I'd like it to be a bit more obvious.
>
> You also left out my other point:
>
> 1. multiple inheritance isn't that common, and multiple inheritance with
> differing access is less so. Therefore is it worth committee time?
>
> If I completely agree that it is more uniform, I still don't think it is
> worth the committee's time. Take the time it have been given so far, and
> multiply that by 100. At least. Is it worth it? Would you personally
> commit that much time to it?
>
> Uniformity is awesome, and it does help with learning, but I think there
> are other/better places to strive for it.
>
> Tony
>
>
>
>>
>> On Wednesday, 29 July 2015 16:45:16 UTC+1, Tony V E wrote:
>>>
>>> You can argue whether it is uniform or not, but I don't think it matters:
>>>
>>> 1. multiple inheritance isn't that common, and multiple inheritance with
>>> differing access is less so. Therefore is it worth committee time?
>>> 2. maybe I'm just old and my eyes are failing, but I don't like it when
>>> a single character changes that much meaning;
>>>
>>> class X : public A, B, C
>>> {
>>> };
>>>
>>> class X : public: A, B, C
>>> {
>>> };
>>>
>>> I guess maybe the semi-colon you put at the end helps, although I also
>>> find that semi-colon superfluous (and also easy to miss).
>>>
>>> Overall, it just doesn't seem worth it to me.
>>>
>>>
>>> On Wed, Jul 29, 2015 at 11:36 AM, Arthur Tchaikovsky <atch...@gmail.com>
>>> wrote:
>>>
>>>> I tend to disagree with that statement. Uniformity (in programming
>>>> language) is always good. It means, one thing less to remember in this
>>>> correct example.
>>>> And surely it does make sense to have identical syntax for declaring
>>>> how we are inheriting from and how we encapsulate members? Why would that
>>>> doesn't make sense? And why would that be a feature as you call it?
>>>> To reverse this scenario and show how bad it looks at the moment, how
>>>> would you feel if we would have to do this each time we declare member:
>>>>
>>>> class X
>>>> {
>>>> public:
>>>> A a;
>>>> public:
>>>> B b;
>>>> public:
>>>> C c;
>>>> };
>>>>
>>>> Surely there is something wrong with the above approach isn't it? If
>>>> the answer to the question is yes, then the way we are inheriting at the
>>>> moment is exactly the same example and should be modernized so we specify
>>>> inheritance modifier only once, not each time.
>>>>
>>>> On Wednesday, 29 July 2015 15:17:16 UTC+1, Ville Voutilainen wrote:
>>>>
>>>>> On 29 July 2015 at 17:06, Arthur Tchaikovsky <atch...@gmail.com>
>>>>> wrote:
>>>>> > It is in the same spirit that is: *make things uniform*.
>>>>>
>>>>> We make things uniform when it makes sense, not because uniformity
>>>>> is always automatically good.
>>>>>
>>>>> > 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
>>>>> > {
>>>>> > };
>>>>>
>>>>> What for? To make it easier to use multiple bases with different
>>>>> accesses?
>>>>> Not being able to do that tersely doesn't sound like bug to me, that
>>>>> sounds like
>>>>> a feature.
>>>>>
>>>>> >
>>>>> >
>>>>> > 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>
>>>>> 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-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/.
>>>>
>>>
>>> --
>>
>> ---
>> 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_682_1479310085.1438356183499
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Tony,<br>As much I respect your opinion, you cannot say=
that my proposed syntax is _sort of_ uniform. It is uniform. It is orthogo=
nal *one - to - one* with internals of a class and how theirs access are sp=
ecified. Example:<br><br>class X<br>{<br>public:<br>int a, b, c;<br>};<br><=
br>class X : public: A,B,C;<br>{<br>};<br><br>The point here is that:<br>a)=
there is a colon after access modifier, all separate base classes have *th=
e same* access modifier and are separated by comma and the statement of dec=
laring inheritance access modifier is ended with semicolon. This is *exactl=
y* one to one mapping. Not, _sort of_, not *false* as Ville was implying, b=
ut *exact*, one to one mapping.<br><br>On Thursday, 30 July 2015 19:35:01 U=
TC+1, Tony V E wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><div><br><div class=3D"gmail_quote">On Wed, Jul 29, 2015 at 11=
:58 AM, Arthur Tchaikovsky <span dir=3D"ltr"><<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"EvVz6btqDgAJ" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this=
..href=3D'javascript:';return true;">atch...@gmail.com</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Well, apart fro=
m the fact that it would bring C++ one step closer of having more uniform s=
yntax, which is good right? It would also make things neater, without break=
ing any existing code, which is good right?<br></div></blockquote><div><br>=
</div><div>Your proposal would make it _sort of_ uniform.=C2=A0 Obviously t=
he two contexts are still different, and you do different things.=C2=A0 ie =
in one you declare variables and functions, etc, and in the other you list =
base classes.=C2=A0 And the syntax still isn't uniform. To be more unif=
orm, maybe you should require semi-colons between the base classes, and/or =
have the access modifier last until the next one:<br><br></div><div>// acce=
ss modifier (with colon), should last until the next one?<br></div><div>cla=
ss X : public: A, B, protected C, D<br>{<br></div><div>=C2=A0=C2=A0 // wait=
, protected C didn't have a colon.<br>=C2=A0=C2=A0 // Is D proctected b=
ecause that was the last specifier, or private because that is the default =
for a class, or public because that was the last specifier with a colon?<br=
></div><div>};<br></div><div>// should use semi-colons, like variable decla=
rations?<br></div><div><div>class X : public: A; B; private C; D<br>{<br>};=
<br><br></div><div>Your proposal still isn't uniform. (I think your syn=
tax might be better than the above, but it is not more uniform than the abo=
ve.=C2=A0 It is selectively uniform.)<br></div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><br>And I am really very sorry for your poo=
r eyes' state, but this cannot be an argument. If that was the case, wh=
y type font like this is even aIIowed to exist? Did you spot the way l miss=
pelled allowed?<br>I'm sorry, but either we do want to make C++ cleaner=
and easier to learn or not and we just doing semi baked attempts like so c=
alled *uniform* initialization, which need I remind you, not only removed p=
roblem of initialization in C++, but on top of that it introduced one more =
way of initializing. How perverted is this?<span><br></span></div></blockqu=
ote><div><br><br></div><div>Forget about my eyes.=C2=A0 That wasn't the=
point.=C2=A0 Even with perfect eyesight, I still don't like subtlety. =
I'd like it to be a bit more obvious.<br></div><div><br></div><div>You =
also left out my other point:<br><br><div></div>1. multiple inheritance isn=
't that=20
common, and multiple inheritance with differing access is less so.=20
Therefore is it worth committee time?<br><br></div><div>If I completely agr=
ee that it is more uniform, I still don't think it is worth the committ=
ee's time.=C2=A0 Take the time it have been given so far, and multiply =
that by 100. At least.=C2=A0 Is it worth it?=C2=A0 Would you personally com=
mit that much time to it?<br><br></div><div>Uniformity is awesome, and it d=
oes help with learning, but I think there are other/better places to strive=
for it.<br><br></div><div>Tony<br><br></div><div>=C2=A0</div><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"><span><br>On Wednesday, 29 July 2015 16:=
45:16 UTC+1, Tony V E wrote:</span><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><span><div dir=3D"ltr"><div><div><div><div><div><div>You can argue whether=
it is uniform or not, but I don't think it matters:<br><br></div>1. mu=
ltiple inheritance isn't that common, and multiple inheritance with dif=
fering access is less so. Therefore is it worth committee time?<br></div>2.=
maybe I'm just old and my eyes are failing, but I don't like it wh=
en a single character changes that much meaning;<br><br></div>class X : pub=
lic A, B, C<br>{<br>};<br><br></div>class X : public: A, B, C<br>{<br>};<br=
><br></div>I guess maybe the semi-colon you put at the end helps, although =
I also find that semi-colon superfluous (and also easy to miss).<br><br></d=
iv>Overall, it just doesn't seem worth it to me.<br>=C2=A0<br></div></s=
pan><div><br><div class=3D"gmail_quote"><div><div>On Wed, Jul 29, 2015 at 1=
1:36 AM, Arthur Tchaikovsky <span dir=3D"ltr"><<a rel=3D"nofollow">atch.=
...@gmail.com</a>></span> wrote:<br></div></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div><div><div dir=3D"ltr">I tend to disagree with that statement. Un=
iformity (in programming language) is always good. It means, one thing less=
to remember in this correct example.<br>And surely it does make sense to h=
ave identical syntax for declaring how we are inheriting from and how we en=
capsulate members? Why would that doesn't make sense? And why would tha=
t be a feature as you call it?<br>To reverse this scenario and show how bad=
it looks at the moment, how would you feel if we would have to do this eac=
h time we declare member:<br><br>class X<br>{<br>public:<br>A a;<br>public:=
<br>B b;<br>public:<br>C c;<br>};<br><br>Surely there is something wrong wi=
th the above approach isn't it? If the answer to the question is yes, t=
hen the way we are inheriting at the moment is exactly the same example and=
should be modernized so we specify inheritance modifier only once, not eac=
h time.<br><br>On Wednesday, 29 July 2015 15:17:16 UTC+1, Ville Voutilainen=
wrote:<div><div><blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 29 July 2015 a=
t 17:06, Arthur Tchaikovsky <<a rel=3D"nofollow">atch...@gmail.com</a>&g=
t; wrote:
<br>> It is in the same spirit that is: *make things uniform*.
<br>
<br>We make things uniform when it makes sense, not because uniformity
<br>is always automatically good.
<br>
<br>> 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't we do the same whilst declaring what classes we are =
inheriting
<br>> from:
<br>> class X: public: A,B,C;<-- here A,B,C would be publicly inherit=
ed
<br>> {
<br>> };
<br>
<br>What for? To make it easier to use multiple bases with different access=
es?
<br>Not being able to do that tersely doesn't sound like bug to me, tha=
t sounds like
<br>a feature.
<br>
<br>>
<br>>
<br>> On Wednesday, 29 July 2015 13:43:19 UTC+1, Ville Voutilainen wrote=
:
<br>>>
<br>>> On 29 July 2015 at 13:34, Arthur Tchaikovsky <<a>atch...@gm=
ail.com</a>> wrote:
<br>>> > Hi Ville,
<br>>> > So in the same spirit, why can't we have (in the sake=
of consistency)
<br>>> > similar construct allowed:
<br>>> > class X: public: A,B,C; protected D,E,F
<br>>>
<br>>> That is not "in the same spirit", and I fail to see =
the consistency
<br>>> argument.
<br>>> That idea has very little to do with a trailing comma in any l=
ist, and
<br>>> its motivation
<br>>> would seem completely different.
<br>>>
<br>>> > {
<br>>> > public:
<br>>> > A a;
<br>>> > B b;
<br>>> > C c;
<br>>> > protected:
<br>>> > D d;
<br>>> > E e;
<br>>> > F f;
<br>>> > };
<br>>> >
<br>>> > The point ^^^ here is that we are inheriting in similar m=
anner to
<br>>> > classifying access level of members of a class, that is, =
we are stating
<br>>> > only
<br>>> > once the desired inheritance level, not every time as we =
are obliged to
<br>>> > do
<br>>> > now, unless we inheriting privately.
<br>>> > This change is:
<br>>> > a) Non breaking existing code
<br>>> > b) Makes class declaration more uniform
<br>>>
<br>>>
<br>>> But as has been mentioned, multiple base classes are much rare=
r than
<br>>> multiple
<br>>> non-static data members, so the motivation for such a thing se=
ems weak.
<br></blockquote></div></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" group.<br></div></div></div>=
</div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span><br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=
=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';ret=
urn true;" onclick=3D"this.href=3D'http://groups.google.com/a/isocpp.or=
g/group/std-proposals/';return true;">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/</a>.<br>
</span></blockquote></div><br></div>
</blockquote></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" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
EvVz6btqDgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"EvVz6btqDgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';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'http://groups.google.com/a/isocpp.org/group/std-proposals/';ret=
urn true;" onclick=3D"this.href=3D'http://groups.google.com/a/isocpp.or=
g/group/std-proposals/';return true;">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_682_1479310085.1438356183499--
------=_Part_681_841463388.1438356183498--
.
Author: Bo Persson <bop@gmb.dk>
Date: Fri, 31 Jul 2015 18:48:21 +0200
Raw View
On 2015-07-31 17:23, Arthur Tchaikovsky wrote:
> Hi Tony,
> As much I respect your opinion, you cannot say that my proposed syntax
> is _sort of_ uniform. It is uniform. It is orthogonal *one - to - one*
> with internals of a class and how theirs access are specified. Example:
>
> class X
> {
> public:
> int a, b, c;
> };
>
> class X : public: A,B,C;
> {
> };
struct X : A,B,C
{
};
already does this, and even shorter.
How many variants do we really need?
>
> The point here is that:
> a) there is a colon after access modifier, all separate base classes
> have *the same* access modifier and are separated by comma and the
> statement of declaring inheritance access modifier is ended with
> semicolon. This is *exactly* one to one mapping. Not, _sort of_, not
> *false* as Ville was implying, but *exact*, one to one mapping.
>
Can't even remember when was the last time I had 3 or more base classes.
Are we solving a real problem here?
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/.
.
Author: Arthur Tchaikovsky <atch.cpp@gmail.com>
Date: Fri, 31 Jul 2015 12:30:57 -0700 (PDT)
Raw View
------=_Part_41_1373432626.1438371058125
Content-Type: multipart/alternative;
boundary="----=_Part_42_1424204852.1438371058126"
------=_Part_42_1424204852.1438371058126
Content-Type: text/plain; charset=UTF-8
You completely missed my point.
In order to prove it to you, I ask you to do this same with protected
access.
On Friday, 31 July 2015 17:48:42 UTC+1, Bo Persson wrote:
>
> On 2015-07-31 17:23, Arthur Tchaikovsky wrote:
> > Hi Tony,
> > As much I respect your opinion, you cannot say that my proposed syntax
> > is _sort of_ uniform. It is uniform. It is orthogonal *one - to - one*
> > with internals of a class and how theirs access are specified. Example:
> >
> > class X
> > {
> > public:
> > int a, b, c;
> > };
> >
> > class X : public: A,B,C;
> > {
> > };
>
>
> struct X : A,B,C
> {
> };
>
> already does this, and even shorter.
>
> How many variants do we really need?
>
> >
> > The point here is that:
> > a) there is a colon after access modifier, all separate base classes
> > have *the same* access modifier and are separated by comma and the
> > statement of declaring inheritance access modifier is ended with
> > semicolon. This is *exactly* one to one mapping. Not, _sort of_, not
> > *false* as Ville was implying, but *exact*, one to one mapping.
> >
>
> Can't even remember when was the last time I had 3 or more base classes.
> Are we solving a real problem here?
>
>
> 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/.
------=_Part_42_1424204852.1438371058126
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">You completely missed my point.<br>In order to prove it to=
you, I ask you to do this same with protected access.<br><br>On Friday, 31=
July 2015 17:48:42 UTC+1, Bo Persson wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">On 2015-07-31 17:23, Arthur Tchaikovsky wrote:
<br>> Hi Tony,
<br>> As much I respect your opinion, you cannot say that my proposed sy=
ntax
<br>> is _sort of_ uniform. It is uniform. It is orthogonal *one - to - =
one*
<br>> with internals of a class and how theirs access are specified. Exa=
mple:
<br>>
<br>> class X
<br>> {
<br>> public:
<br>> int a, b, c;
<br>> };
<br>>
<br>> class X : public: A,B,C;
<br>> {
<br>> };
<br>
<br>
<br>struct X : A,B,C
<br>{
<br>};
<br>
<br>already does this, and even shorter.
<br>
<br>How many variants do we really need?
<br>
<br>>
<br>> The point here is that:
<br>> a) there is a colon after access modifier, all separate base class=
es
<br>> have *the same* access modifier and are separated by comma and the
<br>> statement of declaring inheritance access modifier is ended with
<br>> semicolon. This is *exactly* one to one mapping. Not, _sort of_, n=
ot
<br>> *false* as Ville was implying, but *exact*, one to one mapping.
<br>>
<br>
<br>Can't even remember when was the last time I had 3 or more base cla=
sses.=20
<br>Are we solving a real problem here?
<br>
<br>
<br>Bo Persson
<br>
<br>
<br>
<br>
<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" 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_42_1424204852.1438371058126--
------=_Part_41_1373432626.1438371058125--
.
Author: Bo Persson <bop@gmb.dk>
Date: Fri, 31 Jul 2015 22:40:17 +0200
Raw View
On 2015-07-31 21:30, Arthur Tchaikovsky wrote:
> You completely missed my point.
> In order to prove it to you, I ask you to do this same with protected
> access.
And I have never, ever declared a class with 3 or more protected base
classes, so I don't need simplified syntax for doing that. Do you?
Bo Persson
>
> On Friday, 31 July 2015 17:48:42 UTC+1, Bo Persson wrote:
>
> On 2015-07-31 17:23, Arthur Tchaikovsky wrote:
> > Hi Tony,
> > As much I respect your opinion, you cannot say that my proposed
> syntax
> > is _sort of_ uniform. It is uniform. It is orthogonal *one - to -
> one*
> > with internals of a class and how theirs access are specified.
> Example:
> >
> > class X
> > {
> > public:
> > int a, b, c;
> > };
> >
> > class X : public: A,B,C;
> > {
> > };
>
>
> struct X : A,B,C
> {
> };
>
> already does this, and even shorter.
>
> How many variants do we really need?
>
> >
> > The point here is that:
> > a) there is a colon after access modifier, all separate base classes
> > have *the same* access modifier and are separated by comma and the
> > statement of declaring inheritance access modifier is ended with
> > semicolon. This is *exactly* one to one mapping. Not, _sort of_, not
> > *false* as Ville was implying, but *exact*, one to one mapping.
> >
>
> Can't even remember when was the last time I had 3 or more base
> classes.
> Are we solving a real problem here?
>
>
> 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/.
.
Author: Arthur Tchaikovsky <atch.cpp@gmail.com>
Date: Sat, 1 Aug 2015 03:54:05 -0700 (PDT)
Raw View
------=_Part_280_669975608.1438426446148
Content-Type: multipart/alternative;
boundary="----=_Part_281_1017051437.1438426446148"
------=_Part_281_1017051437.1438426446148
Content-Type: text/plain; charset=UTF-8
The point here is (apart from the fact that yes, I did declare class(es)
with more than 3 bases), so the point is here not that you never did that,
but that the syntax would be uniform.
On Friday, 31 July 2015 21:40:33 UTC+1, Bo Persson wrote:
>
> On 2015-07-31 21:30, Arthur Tchaikovsky wrote:
> > You completely missed my point.
> > In order to prove it to you, I ask you to do this same with protected
> > access.
>
> And I have never, ever declared a class with 3 or more protected base
> classes, so I don't need simplified syntax for doing that. Do you?
>
>
> Bo Persson
>
>
> >
> > On Friday, 31 July 2015 17:48:42 UTC+1, Bo Persson wrote:
> >
> > On 2015-07-31 17:23, Arthur Tchaikovsky wrote:
> > > Hi Tony,
> > > As much I respect your opinion, you cannot say that my proposed
> > syntax
> > > is _sort of_ uniform. It is uniform. It is orthogonal *one - to -
> > one*
> > > with internals of a class and how theirs access are specified.
> > Example:
> > >
> > > class X
> > > {
> > > public:
> > > int a, b, c;
> > > };
> > >
> > > class X : public: A,B,C;
> > > {
> > > };
> >
> >
> > struct X : A,B,C
> > {
> > };
> >
> > already does this, and even shorter.
> >
> > How many variants do we really need?
> >
> > >
> > > The point here is that:
> > > a) there is a colon after access modifier, all separate base
> classes
> > > have *the same* access modifier and are separated by comma and
> the
> > > statement of declaring inheritance access modifier is ended with
> > > semicolon. This is *exactly* one to one mapping. Not, _sort of_,
> not
> > > *false* as Ville was implying, but *exact*, one to one mapping.
> > >
> >
> > Can't even remember when was the last time I had 3 or more base
> > classes.
> > Are we solving a real problem here?
> >
> >
> > 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/.
------=_Part_281_1017051437.1438426446148
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The point here is (apart from the fact that yes, I did dec=
lare class(es) with more than 3 bases), so the point is here not that you n=
ever did that, but that the syntax would be uniform.<br><br>On Friday, 31 J=
uly 2015 21:40:33 UTC+1, Bo Persson 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-31 21:30, Arthur Tchaikovsky wrote:
<br>> You completely missed my point.
<br>> In order to prove it to you, I ask you to do this same with protec=
ted
<br>> access.
<br>
<br>And I have never, ever declared a class with 3 or more protected base=
=20
<br>classes, so I don't need simplified syntax for doing that. Do you?
<br>
<br>
<br>Bo Persson
<br>
<br>
<br>>
<br>> On Friday, 31 July 2015 17:48:42 UTC+1, Bo Persson wrote:
<br>>
<br>> =C2=A0 =C2=A0 On 2015-07-31 17:23, Arthur Tchaikovsky wrote:
<br>> =C2=A0 =C2=A0 =C2=A0> Hi Tony,
<br>> =C2=A0 =C2=A0 =C2=A0> As much I respect your opinion, you canno=
t say that my proposed
<br>> =C2=A0 =C2=A0 syntax
<br>> =C2=A0 =C2=A0 =C2=A0> is _sort of_ uniform. It is uniform. It i=
s orthogonal *one - to -
<br>> =C2=A0 =C2=A0 one*
<br>> =C2=A0 =C2=A0 =C2=A0> with internals of a class and how theirs =
access are specified.
<br>> =C2=A0 =C2=A0 Example:
<br>> =C2=A0 =C2=A0 =C2=A0>
<br>> =C2=A0 =C2=A0 =C2=A0> class X
<br>> =C2=A0 =C2=A0 =C2=A0> {
<br>> =C2=A0 =C2=A0 =C2=A0> public:
<br>> =C2=A0 =C2=A0 =C2=A0> int a, b, c;
<br>> =C2=A0 =C2=A0 =C2=A0> };
<br>> =C2=A0 =C2=A0 =C2=A0>
<br>> =C2=A0 =C2=A0 =C2=A0> class X : public: A,B,C;
<br>> =C2=A0 =C2=A0 =C2=A0> {
<br>> =C2=A0 =C2=A0 =C2=A0> };
<br>>
<br>>
<br>> =C2=A0 =C2=A0 struct X : A,B,C
<br>> =C2=A0 =C2=A0 {
<br>> =C2=A0 =C2=A0 };
<br>>
<br>> =C2=A0 =C2=A0 already does this, and even shorter.
<br>>
<br>> =C2=A0 =C2=A0 How many variants do we really need?
<br>>
<br>> =C2=A0 =C2=A0 =C2=A0>
<br>> =C2=A0 =C2=A0 =C2=A0> The point here is that:
<br>> =C2=A0 =C2=A0 =C2=A0> a) there is a colon after access modifier=
, all separate base classes
<br>> =C2=A0 =C2=A0 =C2=A0> have *the same* access modifier and are s=
eparated by comma and the
<br>> =C2=A0 =C2=A0 =C2=A0> statement of declaring inheritance access=
modifier is ended with
<br>> =C2=A0 =C2=A0 =C2=A0> semicolon. This is *exactly* one to one m=
apping. Not, _sort of_, not
<br>> =C2=A0 =C2=A0 =C2=A0> *false* as Ville was implying, but *exact=
*, one to one mapping.
<br>> =C2=A0 =C2=A0 =C2=A0>
<br>>
<br>> =C2=A0 =C2=A0 Can't even remember when was the last time I had=
3 or more base
<br>> =C2=A0 =C2=A0 classes.
<br>> =C2=A0 =C2=A0 Are we solving a real problem here?
<br>>
<br>>
<br>> =C2=A0 =C2=A0 Bo Persson
<br>>
<br>
<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" 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_281_1017051437.1438426446148--
------=_Part_280_669975608.1438426446148--
.