220 19437 article Path: news.gmane.org!not-for-mail From: Arthur Tchaikovsky Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Omitting multiple access specifiers in base-specifier Date: Thu, 30 Jul 2015 03:13:06 -0700 (PDT) Lines: 303 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_18_584618919.1438251186340" X-Trace: ger.gmane.org 1438251190 1483 80.91.229.3 (30 Jul 2015 10:13:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 30 Jul 2015 10:13:10 +0000 (UTC) Cc: danielgutson@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDL6FI4NYYERBM7R46WQKGQEVQBIXWQ@isocpp.org Thu Jul 30 12:13:09 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vn0-f72.google.com ([209.85.216.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZKkpp-00016q-00 for gclcip-std-proposals@m.gmane.org; Thu, 30 Jul 2015 12:13:09 +0200 Original-Received: by vnbh82 with SMTP id h82sf44489661vnb.2 for ; Thu, 30 Jul 2015 03:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=jf46z98fYpx2wPTlBJ4RxG/hT6ubF+qlu1GZ0RQ7PnU=; b=uGIVLVbeHsSxc66uSTwRsH/gV4z31su4C4Jjs1FcKxH+Og4O6VcLsHXv/ey4T+rftQ v5NrkIT4GO/Zi3yFJImVHWA/Gur2cvJ+4rmek7kBS/Qz1QlbRzT5Vokw70et7xmfVOtC pcHaWXk9b7y5nEL7B6+87i0fhN/Uax0GVUSNvJX9fB0+rXtuPo+w60sLYY1gOErXMlKb mJlFgLshSqsQpmlP/8+CjNSw/Qquxs43o2lAMYjs5r2LZ19/iQV0ho/DWqW6+m9EQU7f qLzXqmPREWcV/3CkmMAVaM6Fl0AzC53q4zpyxzZKEROZQek7+cmmdVTBFmb5HBquGvTn DEKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type:x-original-sender :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=jf46z98fYpx2wPTlBJ4RxG/hT6ubF+qlu1GZ0RQ7PnU=; b=MERaAIv8d6J2FqzkGpu4hyivynCKKFBP/K6AcGUMlmHm3hGhG4zithAZNvFA3NRbsX mcNZl0Uv4GqDwPMluuzKA5k0i4eI5FShpHxZHetgXVZBQzqXfE0OWpY47x89TqWYHOTm d29Fer2rdSl9dEidBRVZd2Sd7IqnEouABONMeaNhbbDN5W3rU1ateBPP27J/2dmR1uTA MBin3ZH0jBjctgCRgjPhXdAp0OMLjDVo4pMl2QwrfC+kVXiRSQXeU+FqQMLNVlWEtq/v o2PaA1CvUhdzmlyuybe1lGKItSvLzYCMJl1B0h+9LmuvMiBXV0f1DLrRjzlb7D1gnvEq UZcg== X-Gm-Message-State: ALoCoQnhHkqhehf+C+jwbr2YZm6RGLyIcRNi+jEuXkFlNR/w9qraUVxaN8DDHFWxx3C7EGup/ktF X-Received: by 10.140.235.148 with SMTP id g142mr2721660qhc.9.1438251188194; Thu, 30 Jul 2015 03:13:08 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.84.229 with SMTP id l92ls670717qgd.41.gmail; Thu, 30 Jul 2015 03:13:07 -0700 (PDT) X-Received: by 10.140.107.34 with SMTP id g31mr635495qgf.17.1438251187052; Thu, 30 Jul 2015 03:13:07 -0700 (PDT) In-Reply-To: X-Original-Sender: atch.cpp@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:19437 Archived-At: ------=_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 > > wrote:=20 > > On 29 July 2015 at 17:06, Arthur Tchaikovsky > 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 =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 .=20 > > To post to this group, send email to std-pr...@isocpp.org = ..=20 > > > Visit this group at=20 > http://groups.google.com/a/isocpp.org/group/std-proposals/.=20 > > > > --=20 > Who=E2=80=99s got the sweetest disposition?=20 > One guess, that=E2=80=99s who?=20 > Who=E2=80=99d never, ever start an argument?=20 > Who never shows a bit of temperament?=20 > Who's never wrong but always right?=20 > Who'd never dream of starting a fight?=20 > Who get stuck with all the bad luck?=20 > --=20 ---=20 You received this message because you are subscribed to the Google 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
Hi, I'd appreciate if you would reply to my post in wh= ich I answer to the 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 Voutila= inen
<ville.vo...@gmail.com> 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.

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 c= aprice.

>
>> 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 inh= erited
>> {
>> };
>
> What for? To make it easier to use multiple bases with different a= ccesses?
> 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 w= rote:
>>>
>>> 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 a= ny 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 simil= ar 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 thin= g 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<= /a>.
> To post to this group, send email to http://groups.google.com= /a/isocpp.org/group/std-proposals/.



--=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?

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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/<= /a>.
------=_Part_19_849357047.1438251186340-- ------=_Part_18_584618919.1438251186340-- .