220 36733 article Path: news.gmane.org!.POSTED!not-for-mail From: Brian Bi Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Why doesn't C++ have const inheritance? Date: Sun, 21 Jan 2018 17:46:13 -0800 Lines: 341 Approved: news@gmane.org Message-ID: References: <5375ec95-89a6-0d4a-91ab-f06602089d97@gmail.com> <1b22eaaf-1441-4bd2-8f1d-a54c58964b05@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a11352e126779370563539853" X-Trace: blaine.gmane.org 1516585470 27741 195.159.176.226 (22 Jan 2018 01:44:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 22 Jan 2018 01:44:30 +0000 (UTC) Cc: tbfleming@gmail.com, o.pikozh@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDS5ZX5VU4NBBZUESXJQKGQELY64BMI@isocpp.org Mon Jan 22 02:44:26 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f71.google.com ([209.85.218.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1edR9f-00061f-Lf for gclcip-std-proposals@m.gmane.org; Mon, 22 Jan 2018 02:44:12 +0100 Original-Received: by mail-oi0-f71.google.com with SMTP id 75sf2541771oie.3 for ; Sun, 21 Jan 2018 17:46:16 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1516585575; cv=pass; d=google.com; s=arc-20160816; b=KKlhAoBt8tBBg6C+DpXqE8NQOPDcA+kIas2Eu3rVJExOttlMfhLjZQ/2pBxA4eNAk2 7nPS5GS6VGccp1voFsGJw5/nJEq+KKkJ1Fs1EPMy3Za2jxeDZEZlLAD67baEOThVtAhA PtRxg9gnkR9GtGotrF0mFx9U7cl2Fcy5ilvbJoWzzMkp/FPY/3PHBBmGBRbdBRdl8oun nQu3WzgNbv9EUjalZ3aAAyLoW0ykHOW9Km8fpy7SDiDa0C8qzc9aaxr+/e05hs0Kfe7k N+HArB1s6/oZBH8Rx/h2ogtnDeVVe06It+qZ/tOmUr753vfKw3GCG8kU7NFYktRuxG91 /zjw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:cc:to:subject:message-id :date:from:references:in-reply-to:mime-version :arc-authentication-results:arc-message-signature:dkim-signature :arc-authentication-results; bh=2tPYzPWBU3dI3wRb3hjO0UAcl7VmIp76z5q1svRuMKM=; b=xex7Lq5gNKFJ2DLmyYLWA8xpZ7GWsqIvo5Y1D7sItuM6n+G7eXIyV3saRr0pu99Iml pWwDqTbgR2o/3Up8aogkF3Ky0qYUC6Nx/JxzNhy+3NUZKJmEI2HIF+5+TQTuyl/a9MlS jVGtUNKsr6Nv0NZSwlO8UBjwRp1hBcJ1s77Pr6lDlxhOSYeEslwHZoBWTDqhbGJ+3QtX V8zDZqSQQVjY1bMCSKz2+2H9c1xDwv43x/DdHgnsv8H5BvULH0JJ2iCEwOL8uZK84JGx qOMy2j9l6/KJuu9cUYJ6qpV7A/zdwPGJi44Rh4owmMHNthvxoNlzFuyORrPrt/mW7Vd/ BVPg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MjZ8viWO; spf=pass (google.com: domain of bbi5291@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=bbi5291@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=2tPYzPWBU3dI3wRb3hjO0UAcl7VmIp76z5q1svRuMKM=; b=Ssh5RbeaGpJh4it680da1SYL6eYo2rJxF0VF7/K0c7PpReEWAh/7FeFQIMOVixaA1D IfCoPYRazvHcDYQ2X1F093bM92DbaOJJOIkvDFly61pgfqnoV20i5/OXlI/EcWPqyRuz R5SMT+Q5h+ddGTM3Z9f8LfZ/11p4z6SHlQ9Dbts/tb/pLpAVflZa8z1VKMTYzObOtGp7 +fmi66lE9rUeian3N0CccKebEYAvTBdmdpxlN6QSRDY3FJfVBoGoLeGRt6PwYAQVv3Yh pS5wAtxyHsJfaRbNlcaBm8o33K+MXVmGUyGddjEAwD3HdnmnNA1F0XcT7k1/HBsGi07Y 2NDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=2tPYzPWBU3dI3wRb3hjO0UAcl7VmIp76z5q1svRuMKM=; b=hDly4lqqL6XmySXQgQmqY0c6QPChlQr3QszIQ9iRllAdXARgQ8Ifcycv/dREhtHdMV csDpTj57cg8lsO1gRrj+pxvHiQqzH/EQ/UH1tVvz5YviiBRv1miNm0S7cM8i4ULobKOE jQThlR6/winNU7wgnybKB+etVP1ONeuQJFeOFuQwn6fIAHrsaJDy9gQxZYgQIhNObzlK f20KBuAbw5g9vWH5XIQjxrrxrDTDnJdasG1hakw9tCEGH3/YENugxph1+jHZhxzIPFUt MiC+Om7EBbwqdWKBiVanKQ+sDiRiMSWKHbpk30k+0i32KbgIBcQG4JFLhOxMaKuVJLPS o6Cw== X-Gm-Message-State: AKwxytcEtATp9X+3K6C2mUX0bbYdBv/bKpXRI2DvBIRebpq/b+0DqxYc 8uLtxBlPFM1sJ/qxhuRITsAxUw== X-Google-Smtp-Source: AH8x226+GXfcPcXZ/xSEg+AoDQR29w5MTca3XGsHktMypA8DY01kTZZMHgJdV/XrWAD2hLwB9K5jbg== X-Received: by 10.157.12.154 with SMTP id b26mr3271193otb.97.1516585575444; Sun, 21 Jan 2018 17:46:15 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.41.174 with SMTP id n43ls2041078otb.17.gmail; Sun, 21 Jan 2018 17:46:14 -0800 (PST) X-Received: by 10.157.60.119 with SMTP id j52mr3745875ote.353.1516585574495; Sun, 21 Jan 2018 17:46:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516585574; cv=none; d=google.com; s=arc-20160816; b=vebn/UhBR5INOg9teRGL8kokA2W9/+r73xzcP09FZMmahnAuNYZuq9y0QNQlek7hSj sUhM45LBOba0ak7iTrQXcoO7DAWXI6L30hxtYBheUiTmFuXK8eG0enCtHW7m+CL/Pwhq keNNL5bwCu1h8RlR71PvQ7D0+4598yWaNBiJFfbvX2CXbCvgNPHa/A+o0K78/fBrBbgF WrVhDqPQKdAEnAdfNTWi3HeaWXLQm4PSvLi+4NqqEirMHlAWYyUfjnd/3uyv/eBP92UL ZveC0i+72maGD4pk9fqxD1lkR/lkqI4wLA0gpfeOdsS3IOKC8Iut5cRZCw28VLLcAWv2 F8pA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:dkim-signature:arc-authentication-results; bh=E+rEwXiuDE9V3l4CfEwelXIkOa/5M9MyVtAutqK3LCw=; b=apkh0sXCWnBhlNxiX0D0C3VqylPRAC+EI8iUYpRrU8q+CcR7jCE4kvntApQrh6pCBT kzODhZ2Xdh1QQC8ZQ+uIKxvUwqgVcpjO6qKtjb34PyJhm3TkTPemhKCk8K6VWRfuQs9o PvGXIl5Y6D58Imhqr3myugDkQnnleDicIsVFZcg6u9cBVUmmijJ0xQocgeqbNMwZqcrp lz5dhwW3le9Yu3Nmhz1L25KVE0z6xpRbwjsjTPart5Y3iHc+PAfxJ3rtPvuxodHZ4x80 MBmQfKfTF3mzV/wjZgz10HOjXFKabNho6I4ZusJ85uSpOwFkvjAACSWuFpTBrwn7dmk1 cLqQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MjZ8viWO; spf=pass (google.com: domain of bbi5291@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=bbi5291@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id r6sor5174918oie.86.2018.01.21.17.46.14 for (Google Transport Security); Sun, 21 Jan 2018 17:46:14 -0800 (PST) Received-SPF: pass (google.com: domain of bbi5291@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.202.196.206 with SMTP id u197mr3197000oif.39.1516585573905; Sun, 21 Jan 2018 17:46:13 -0800 (PST) Original-Received: by 10.74.128.3 with HTTP; Sun, 21 Jan 2018 17:46:13 -0800 (PST) In-Reply-To: X-Original-Sender: bbi5291@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MjZ8viWO; spf=pass (google.com: domain of bbi5291@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=bbi5291@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=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:36733 Archived-At: --001a11352e126779370563539853 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You would have the same issue with a `const A` non-static member, and yet that's allowed. On Sun, Jan 21, 2018 at 5:44 PM, Cleiton Santoia wrote: > Consider > > struct A { > int x; > int y; > A(int x_) : x(x_) {} // constructor does not initialize y > }; > > struct B: const A { // how initialize A::y ? > > }; > > How would you construct the "const" part of A ? > > Em sexta-feira, 19 de janeiro de 2018 06:04:10 UTC-2, Oleksandr Pikozh > escreveu: >> >> On 19.01.18 03:19, Todd Fleming wrote: >> >> On Thursday, January 18, 2018 at 6:40:19 PM UTC-5, Oleksandr Pikozh >> wrote: >>> >>> Like this: >>> >>> struct A { >>> int original_member; >>> }; >>> struct B: const A { >>> int added_member; >>> }; >>> >>> This should mean that `B &` isn't type-cast-able to `A &`, but is >>> type-cast-able to `const A &`. This differs from declaring `B` with >>> having an instance of `A` declared just as a field (but not as ancestor= ) >>> and additionally having a type-case operator like `operator const A &() >>> const {return _a /*the field name*/;}`in the following aspects: >>> 1. Instances of `B` allow access to (some of, see below) members of `A` >>> through `.` operator (e.g. `B b; std::cout << b.original_member`; and o= f >>> course instances of `B *` allow access to (some of, see below) members >>> of `A` through `->` operator). >>> 2. Within `B` declaration, (some of, see below) virtual methods of `A` >>> can be overridden. >>> >>> In general the rules are expected to be the following: >>> 1. All non-static fields from `A` are inherited with usual visibility, >>> but making them effectively const. >>> 2. All non-static const methods from `A` are inherited with usual >>> visibility. >>> 3. All non-static non-const methods from `A` aren't allowed be called >>> from `B` (as `A` is effectively const-ed). They also aren't allowed to >>> be overridden within `B` with the `override` directive. Declaring withi= n >>> `B` a virtual method with a signature similar to a such method in `A` >>> without `override` causes a new entry in VMT. >>> 4. All static members are inherited with usual visibility. >>> >> >> A common response to "Why Not?" in this forum is "Why?". Is there a lot >> of code out there that this would simplify? Lambda functions, Modules, >> Coroutines, the Spaceship Operator, and other features had to pass that >> test. >> >> Todd >> >> >> Yep, you're right, this doesn't simplify a lot. It's more about making a >> feature stack more complete and intuitive (i.e. if we have non typical f= or >> other languages features (which partially erase border between >> aggregation and inheritance) like protected and private inheritance, the= n >> why not to go further (with erasing this border) with const inheritance, >> why actually not to make every type (e.g. int) to be able to act as >> ancestor), but it would be quite rarely used. So even I myself don't >> consider this feature to be somehow near the beginning of the list of >> missing C++ features (I personally wait for the "lambda structs" (i.e. >> structs that grab local context of the place of declaration and can use= it >> in their methods, extension of the `[&](=E2=80=A6){}` feature) for the m= ost now). >> > -- > You received this message because you are subscribed to the Google Groups > "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to std-proposals+unsubscribe@isocpp.org. > To post to this group, send email to std-proposals@isocpp.org. > To view this discussion on the web visit https://groups.google.com/a/ > isocpp.org/d/msgid/std-proposals/de685e29-1144-4991- > bde8-f1a3d837b26f%40isocpp.org > > . > --=20 *Brian Bi* --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/CAMmfjbOZ%2BsXzN0wv0AP7zUywtrDhL7Hyo8i2E0JAZoQ%2= BmqwQAA%40mail.gmail.com. --001a11352e126779370563539853 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You would have the same issue with a `const A` non-static = member, and yet that's allowed.

On Sun, Jan 21, 2018 at 5:44 PM, = Cleiton Santoia <cleitonsantoia@gmail.com> wrote:
=
Consider

struct A {
=C2=A0 int x;
=C2=A0 int y;
=C2=A0 A(int x_) : x(x_) <= span style=3D"color:#660" class=3D"m_3759043583166119104styled-by-prettify"= >{} // constructor does not initialize y
};

struct B: const A { =C2=A0// how initialize A= ::y ?
=C2=A0
};
How would you construct the "const" part of A ?
<= div class=3D"h5">
Em sexta-feira, 19 de janeiro de 2018 06:04:10 UTC-2, = Oleksandr Pikozh escreveu:
=20 =20 =20
On 19.01.18 03:19, Todd Fleming wrote:
On Thursday, January 18, 2018 at 6:40:19 PM UTC-5, Oleksandr Pikozh wrote:
Like this:

=C2=A0=C2=A0=C2=A0=C2=A0 struct A {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int original_mem= ber;
=C2=A0=C2=A0=C2=A0=C2=A0 };
=C2=A0=C2=A0=C2=A0=C2=A0 struct B: const A {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int added_member= ;
=C2=A0=C2=A0=C2=A0=C2=A0 };

This should mean that `B &` isn't type-cast-able to `A &`, but is
type-cast-able to `const A &`. This differs from declaring `B` with
having an instance of `A` declared just as a field (but not as ancestor)
and additionally having a type-case operator like `operator const A &()
const {return _a /*the field name*/;}`in the following aspects:
1. Instances of `B` allow access to (some of, see below) members of `A`
through `.` operator (e.g. `B b; std::cout << b.original_member`; and of
course instances of `B *` allow access to (some of, see below) members
of `A` through `->` operator).
2. Within `B` declaration, (some of, see below) virtual methods of `A`
can be overridden.

In general the rules are expected to be the following:
1. All non-static fields from `A` are inherited with usual visibility,
but making them effectively const.
2. All non-static const methods from `A` are inherited with usual
visibility.
3. All non-static non-const methods from `A` aren't allowed b= e called
from `B` (as `A` is effectively const-ed). They also aren't allowed to
be overridden within `B` with the `override` directive. Declaring within
`B` a virtual method with a signature similar to a such method in `A`
without `override` causes a new entry in VMT.
4. All static members are inherited with usual visibility.

A common response to "Why Not?" in this forum is &qu= ot;Why?". Is there a lot of code out there that this would simplify? Lambda functions, Modules, Coroutines, the Spaceship Operator, and other features had to pass that test.

Todd

Yep, you're right, this doesn't simplify a lot. It's more a= bout making a feature stack more complete and intuitive (i.e. if we have non typical for other languages features (which partially erase border between aggregation and inheritance) like protected and private inheritance, then why not to go further (with erasing this border) with const i= nheritance, why actually not to make every type (e.g. int) to be able to act as ancestor), but it would be quite rarely used. So even I myself don'= t consider this feature to be somehow near the beginning of the list of missing C++ features (I personally wait for the "lambda structs= " (i.e. structs that=C2=A0 grab local context of the place of declaration and can use it in their methods, extension of the `[&](=E2=80=A6){}= ` feature) for the most now).

--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit = https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/de68= 5e29-1144-4991-bde8-f1a3d837b26f%40isocpp.org.



--
Brian Bi
=

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMmfjbOZ%2Bs= XzN0wv0AP7zUywtrDhL7Hyo8i2E0JAZoQ%2BmqwQAA%40mail.gmail.com.
--001a11352e126779370563539853-- .