220 41196 <7ab7b56f-e805-4703-a566-d805d08e20e2@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: cppljevans@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Proposal: Extensions of Scoped Enumerations Date: Sun, 2 Dec 2018 08:25:53 -0800 (PST) Lines: 227 Approved: news@gmane.org Message-ID: <7ab7b56f-e805-4703-a566-d805d08e20e2@isocpp.org> References: <506ba0a8-2d6b-4a4d-8fe8-b5e94d232365@isocpp.org> <82c331a0-fb81-4b67-8a7e-c5a6b8929e00@isocpp.org> <43b3f4ec-fd19-4144-bf24-067ce587e071@isocpp.org> <9e3bba78-04c2-42d5-b522-2712932c1659@isocpp.org> <73866d3d-1466-3bca-55d2-3c00c16127a4@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3805_1739465788.1543767953717" X-Trace: blaine.gmane.org 1543767831 6280 195.159.176.226 (2 Dec 2018 16:23:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 2 Dec 2018 16:23:51 +0000 (UTC) Cc: philipgins@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDAYTI72VMGRBE4PSDQAKGQETNDYXZA@isocpp.org Sun Dec 02 17:23:47 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f69.google.com ([209.85.161.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gTUX4-0001Um-AX for gclcip-std-proposals@m.gmane.org; Sun, 02 Dec 2018 17:23:46 +0100 Original-Received: by mail-yw1-f69.google.com with SMTP id y65sf7879105ywy.3 for ; Sun, 02 Dec 2018 08:25:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=5zrp/PzfazqQggzhLWFyZwcgzWIAXgRKv6jcYI2cpWA=; b=VkdNimRpNWnM0QTcKBL70JyFl3U7AnUmDlBnwTtwd443ooUm1J93pXGcdeB8rt0X/K KftUtdxCPHQw3zoyDwrLu1/4/Tnw0iC4JqMTTaaHLClIxbXheuzmn4SoGl6PWmkEYFvO OwdnJqhE8zVq5NFUU67joz4/gAw3qXfrqsE2KyA/1G+uw7v0yUhvVtStvDIs8/KSb57Y 427AZTJj0uZ0bEwPcghjcHym4YZ5owJlPrEQoOKOxReMBFRRkj3vqRW3LZ1iLx/TZkmM 0kxW8eGvjELYhYpeo3Gnre99AIh+EnF/u6uik1JRNOwRSUHG9UIiHqj4SdZ3Cua1aENd Ij3g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=5zrp/PzfazqQggzhLWFyZwcgzWIAXgRKv6jcYI2cpWA=; b=cpkxfMFwZ2OwGxYhRmG7FSuoSCJuAZ5ki/tceOfnc4ZNiJ+gdqJL+juCXbwZVnObr4 QeuSatQ2t9H+ypt7Oi818h2SgNZrH+2IJlQhuxTH8ufb5Ra69e7YTBcPWzIeYketNi+l WoWOU7DkNCHuE1GmFDnYIpIu/7MTnxr46RjM7ptiVF3P8Z+3FoNU/x0322haGRPVKYQu 4ERUFd26PSj/aICl5N0sRg/i2LAnYBOydB6cGn3nIbWCrS+LY/d4jF102cUbjOtCfsSX N4rmDn5duNbcyVCsR7MQZDD+pYVSZ8BmLLsGFdyyBCQHDL8WipmimotxIsJgmj1AbIAU RxTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version: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=5zrp/PzfazqQggzhLWFyZwcgzWIAXgRKv6jcYI2cpWA=; b=oBzG7KVazaMMiacZLITg7G4DnpoQRLYc4jVVIo2BZubxXnU2wrYaS4DSzQktICV2AN 0mS9rafhtrPl7W40yVIoCLTztaYemqDpzir74G+2IWCKLXWLt3fOs+l5Ehpeu3B6aFH3 VTP7oyxYiuRXHIKS9hLvHU9DQoLHdZ7KRKEmZCfqHzi1B5tgRYeS0d2bds9axeYY36Dp Z3+Qvv0t/k3Uew1ChdgZW16AXlIEJEkxxLrlGA0Q5ds3OidBX6x04ijQEJOBFYdWisSW Az5p6BvepoBiB7kPlpPZv3z5O3hMV8/WLgxgvGF4nSzBrbSqAiyj54wqn6yRQ7DD+TMS ig5w== X-Gm-Message-State: AA+aEWat1uXGlc6mXez6mMIINuxDZxWRyCBCuLb9uJM92Le3cP8B+C7m XQbeJOoPO309V/qRSiuyLpYz0Q== X-Google-Smtp-Source: AFSGD/UHosFhNmPKc5C6up9F9XE9cYrsLJIW8mKClzxZXVWP6oTyuZd5wFn2Eu9w53UTpY+lrjJ6xQ== X-Received: by 2002:a25:ed5:: with SMTP id 204-v6mr7523195ybo.66.1543767956338; Sun, 02 Dec 2018 08:25:56 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:ab26:: with SMTP id u35-v6ls5188258ybi.10.gmail; Sun, 02 Dec 2018 08:25:54 -0800 (PST) X-Received: by 2002:a25:afcd:: with SMTP id d13-v6mr130791ybj.2.1543767954760; Sun, 02 Dec 2018 08:25:54 -0800 (PST) In-Reply-To: <73866d3d-1466-3bca-55d2-3c00c16127a4@wanadoo.fr> X-Original-Sender: cppljevans@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:41196 Archived-At: ------=_Part_3805_1739465788.1543767953717 Content-Type: multipart/alternative; boundary="----=_Part_3806_1597953238.1543767953717" ------=_Part_3806_1597953238.1543767953717 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sunday, December 2, 2018 at 7:47:40 AM UTC-6, Vicente J. Botet Escriba= =20 wrote: > > Le 02/12/2018 =C3=A0 02:49, phili...@gmail.com a =C3=A9crit= : > > Hi all,=20 > > I have updated the proposal=20 > to=20 > reflect some of your feedback: > > I've some trouble with the way you use sub-typing "there is a natural=20 > correspondence between sub-typing and adding enumerators to enums".=20 > > I was expecting to have an enum and be able to define sub-types of this= =20 > enums, by restricting the possible enumerators, not by adding new ones (a= s=20 > ADA does - see=20 > http://www.adaic.org/resources/add_content/standards/05rm/html/RM-3-5-1.h= tml).=20 > Have you considered this possibility? Are you sure that the common case i= s=20 > to extend enumerators, or to restrict them. Maybe both are useful. > So, for me you are proposing super-types of enums, not sub-types. It is= =20 > weird that we are using the same syntax as inheritance while we are=20 > defining the opposite relation, but this is already incoherent with the= =20 > C++11 scoped enum syntax.=20 > [snip]=20 I agree with Vincente that super-type is the correct term. The reason it seems weird is because class inheritance is for product types whereas enum inheritance is for sum types (e.g. std::variant): https://en.wikipedia.org/wiki/Algebraic_data_type and the duality property of category theory: https://en.wikipedia.org/wiki/Dual_(category_theory) =20 says that the arrows are reversed in the dual category. In this particular case, the arrow is the Liskov=20 substitution principle mentioned in Bernardo's post. More formally, let: A <: B =20 mean a type A can be substituted where a type B is expected( i.e. the Liskov principle). Now if: struct sB{int b_1; char b_2;} struct sA : sB{ bool a_3}; =20 then: sA <: sB =20 IOW, an instance of sA can substituted anywhere an instance of sB is expected (because sA has all of the fields that sB has). =20 OTOH, if: enum eB{b_1,b_2}; enum eA : eB{a_3}; =20 then: eB <: eA IOW, an instance of eB (e.g. b_2) can be substituted anywhere an instance of eA is expected (because b_2 is actually a member of eA as well as a member of eB). OTOH, there's an interesting corner case: enum eB{}; enum eA : eB{a_3}; =20 Now what happens when: eB b_0; =20 is used where an eA is expected? I don't know, but I'd guess there would be a core dump or something as unpleasant. -regards, Larry --=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/7ab7b56f-e805-4703-a566-d805d08e20e2%40isocpp.or= g. ------=_Part_3806_1597953238.1543767953717 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sunday, December 2, 2018 at 7:47:40 AM UTC-6, V= icente J. Botet Escriba wrote:
=20 =20 =20
Le 02/12/2018 =C3=A0 02:49, phili...@gmail.com a =C3=A9crit=C2=A0:
=20
Hi all,

I have updated the pro= posal=C2=A0to reflect some of your feedback:

I've some trouble with the way you use sub-typing "there is= a natural correspondence between sub-typing and adding enumerators to enums".

I was expecting to have an enum and be able to define sub-types of this enums, by restricting the possible enumerators, not by adding new ones (as ADA does - see http://www.adaic.org/resources/add_content/stan= dards/05rm/html/RM-3-5-1.html). Have you considered this possibility? Are you sure that the common case is to extend enumerators, or to restrict them. Maybe both are useful.

So, for me you are proposing super-types of enums, not sub-types. It is weird that we are using the same syntax as inheritance while we are defining the opposite relation, but this is already incoherent with the C++11 scoped enum syntax.
[snip]=C2=A0
I agree with Vincente th= at super-type is the correct term.
The reason it seems weird is because = class inheritance is
for product types whereas enum inheritance is for s= um types
(e.g. std::variant):

=C2=A0 https://en.wikipedia.org/wik= i/Algebraic_data_type

and the duality property of category theory:
=C2=A0 https://en.wikipedia.org/wiki/Dual_(category_theory)
=C2=A0=
says that the arrows are reversed in the dual category.
In this par= ticular case, the arrow is the Liskov
substitution principle mentioned = in Bernardo's post.

More formally, let:

=C2=A0 A <: B<= br>=C2=A0
mean a type A can be substituted where a type B is expected(<= br>i.e. the Liskov principle).

Now if:

=C2=A0 struct sB{int b= _1; char b_2;}
=C2=A0 struct sA : sB{ bool a_3};
=C2=A0
then:
=
=C2=A0 sA <: sB
=C2=A0
IOW, an instance of sA can substituted= anywhere an instance
of sB is expected (because sA has all of the field= s that sB
has).
=C2=A0
OTOH, if:

=C2=A0 enum eB{b_1,b_2};<= br>=C2=A0 enum eA : eB{a_3};
=C2=A0
then:

=C2=A0 eB <: eA<= br>
IOW, an instance of eB (e.g. b_2) can be substituted
anywhere an = instance of eA is expected (because b_2 is
actually a member of eA as we= ll as a member of eB).

OTOH, there's an interesting corner case:=

=C2=A0 enum eB{};
=C2=A0 enum eA : eB{a_3};
=C2=A0
Now wh= at happens when:

=C2=A0 eB b_0;
=C2=A0
is used where an eA is= expected?

I don't know, but I'd guess there would be a core= dump or
something as unpleasant.

-regards,
Larry

--
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/7ab7b56f-e805-4703-a566-d805d08e20e2= %40isocpp.org.
------=_Part_3806_1597953238.1543767953717-- ------=_Part_3805_1739465788.1543767953717-- .