220 41198 article Path: news.gmane.org!.POSTED!not-for-mail From: philipgins@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Proposal: Extensions of Scoped Enumerations Date: Sun, 2 Dec 2018 09:17:27 -0800 (PST) Lines: 129 Approved: news@gmane.org Message-ID: 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_3829_2144669994.1543771047910" X-Trace: blaine.gmane.org 1543770924 12388 195.159.176.226 (2 Dec 2018 17:15:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 2 Dec 2018 17:15:24 +0000 (UTC) Cc: philipgins@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDF7JOGU34HRBKFHSDQAKGQEKLLXS5Y@isocpp.org Sun Dec 02 18:15:19 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb1-f198.google.com ([209.85.219.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gTVKx-00034b-IV for gclcip-std-proposals@m.gmane.org; Sun, 02 Dec 2018 18:15:19 +0100 Original-Received: by mail-yb1-f198.google.com with SMTP id i13-v6sf6857576ybe.14 for ; Sun, 02 Dec 2018 09:17:30 -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=m6g0PEGDBrqrhl2afBZFQTmnmk99ES+4XZPByxP2b0g=; b=JVDqSy7dEpKpyyj+cD5Ya81IWf25f6jX6jUChlh3irAOnU+B/sh7SGsIyBgmEUok2B 2p8lQZnr43U7ljMWZVtKsXtmko86TOtlCExmLSL/cotmKr6Umnfa8I284Db/UgNoRqqF UUHOyR6ZTee1eDd5vZZmRTsi/XSmKYLl2V1Gat9tq+TpMPotVFqzDtrHhC5i8ilId6c1 fKuE8B7yvFpKMyutVIoR4msOYeWhiSoE3fomlOIDDyTFcd+R9DgSO/l2iD9EaQ6z0V14 cUfRM52mswFMebx+pkAGphtuDH+YzCY5EOhmLqM2nvr40zLqz0gjv1BERbwQlhpDBY9+ qIGA== 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=m6g0PEGDBrqrhl2afBZFQTmnmk99ES+4XZPByxP2b0g=; b=QznFPNty/SBG6RdlXbiS0N5WfIj94hKN9AL4HXbE0fpdwiYWd0hWFcLhr/9j6rZyEP ZFqucID5iKSrn6T5/pu2ylqdIcrtRYmq722vhQIv5M85wgpP51M5dWAP7f1IewImfT5y y+pnXsGVYYqg++NJWfCQcXrfO93izDpXjIde7gHzJb/dpzgs36hXBaM7hrg1kVDvvvSG 9UswCdi3/89LJHVdR9f7gDWR+kXgiTaoTJ0NR0xPKGkfPSS1vUa10Q6d3bHuY0PfyScP 5LiKv1C232N+o33qarRZldvUiIe0HyQqw2gV4c5VzyDMQ2yQnPuokVi1gzWJLqspdh4P aKYw== 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=m6g0PEGDBrqrhl2afBZFQTmnmk99ES+4XZPByxP2b0g=; b=YM9Szk/Dgt3mpuzAwRs9UaaDJqDjsbYN0Af3nxXJixLewhmlG0bfzx9K+EsIZI1+xk hpjigENjtH58B5JWW8zinutWFmT0ytGCKuA4zz15SXqWNyUB67t82aZKXRwnDy5M+h8j ZO/MFA1W+GVUyrWHVgRt35UdV6MqHMhkBOY9SS4dXjefMO9ScQHXB5ZVCVkUw+T3inUE qaE0lCESk/dVSNnLl5Gp9Peh0RqrVg197oU0lAG29JWjk0FC15cI35bmLM4cvvKf+rmO kcZzUtycaaV/DmxQkfmCLHueuaCwTNeS60N94rDnT64yP+w5J953i+4reFbBOqfUsRcw euKg== X-Gm-Message-State: AA+aEWbhHpWeiSZDdSWPmRAKw85BC9KCW8i1IV0zRXLv3foCbwIX2zrS LJmKgJYfV/yy8VNx+H52vF/Edg== X-Google-Smtp-Source: AFSGD/XTnslQNeprkbS/A228KINarfre//HgJzuybgTuwuuvdTMd2pTKdlKVdAIXPq+6mWDjKZMeVg== X-Received: by 2002:a25:945:: with SMTP id u5-v6mr7640049ybm.14.1543771049704; Sun, 02 Dec 2018 09:17:29 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:3656:: with SMTP id d83-v6ls6372137ywa.0.gmail; Sun, 02 Dec 2018 09:17:28 -0800 (PST) X-Received: by 2002:a81:550b:: with SMTP id j11mr161115ywb.4.1543771048454; Sun, 02 Dec 2018 09:17:28 -0800 (PST) In-Reply-To: <73866d3d-1466-3bca-55d2-3c00c16127a4@wanadoo.fr> X-Original-Sender: philipgins@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:41198 Archived-At: ------=_Part_3829_2144669994.1543771047910 Content-Type: multipart/alternative; boundary="----=_Part_3830_764046016.1543771047910" ------=_Part_3830_764046016.1543771047910 Content-Type: text/plain; charset="UTF-8" Hi Bernardo, The Liskov substitution principle still holds, a TokenType& can be used as a SyntaxType&. Larry pointed to a paper earlier and put this into a better type theory context than I could in my own words. Hi Vincente, Thanks you for the thorough comments, I'll try to address them one by one. extension vs restriction: I think extensions serve a different purpose than what you have in mind: I can extend without knowing the internals of the base enumerator but I cannot restrict without knowing the internals of the larger enum. Thus extension can serve for modularity, whereas restriction do not and can already be implemented by e.g. predicate functions. syntax confusing: The same syntax is used to spell out the integral type or to specfy a base enumeration although those are two entirely different things, you rightly point this out as a bit confusing. Furthermore, the syntax is similar to class inheritance but produces the inverse result: a value of the base enum is _more_ constrained, as it can take on _less_ values. I had a more verbose syntax in mind before, but was strongly advised to not introduce new keywords or otherwise fancy syntax. I think this is a reasonable compromise. I quite like the ">:" syntax for extensions, however I expect that this has bigger chances to getting admitted to the standard without new syntax. multiple extensions: I agree it's not obviously a bad idea to allow it, but it seemed like it would result in unexpected behaviour too often. I think this goes a bit towards the first point: When thinking about restrictions (that would be well served with just a boolean predicate function) it seems obvious that this should be allowed. When thinking about it from the angle of modularity it's not so clear to me that this is useful enough to warrant the problems. conversion function: This doesn't solve the problem, although it does contain it. The implementation of the conversion function still has the exact same issue. If it is based on the underlying integer value then it will silently fail when the two enums go "out of sync". The only reason for scoped enums to exist is type safety and that would be thrown out of the window there. This is also the case with your next example that explicitly uses the underlying type. Best, Philip -- 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/a359f82b-1a89-4dae-8b6e-169a57065f4e%40isocpp.org. ------=_Part_3830_764046016.1543771047910 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0Hi Bernardo,

The Lisko= v substitution principle still holds, a TokenType& can be used as a Syn= taxType&.
Larry pointed to a paper earlier and put this into = a better type theory context than I could in my own words.


Hi Vincente,

Thanks you fo= r the thorough comments, I'll try to address them one by one.

extension vs restriction:
I think extensions serv= e a different purpose than what you have in mind: I can extend without know= ing the internals of the base enumerator but I cannot restrict without know= ing the internals of the larger enum. Thus extension can serve for modulari= ty, whereas restriction do not and can already be implemented by e.g. predi= cate functions.

syntax confusing:
The sa= me syntax is used to spell out the integral type or to specfy a base enumer= ation although those are two entirely different things, you rightly point t= his out as a bit confusing.
Furthermore, the syntax is similar to= class inheritance but produces the inverse result: a value of the base enu= m is _more_ constrained, as it can take on _less_ values.
I had a= more verbose syntax in mind before, but was strongly advised to not introd= uce new keywords or otherwise fancy syntax. I think this is a reasonable co= mpromise.
I quite like the ">:" syntax for extension= s, however I expect that this has bigger chances to getting admitted to the= standard without new syntax.

multiple extensions:=
I agree it's not obviously a bad idea to allow it, but it se= emed like it would result in unexpected behaviour too often.
I th= ink this goes a bit towards the first point: When thinking about restrictio= ns (that would be well served with just a boolean predicate function) it se= ems obvious that this should be allowed.
When thinking about it f= rom the angle of modularity it's not so clear to me that this is useful= enough to warrant the problems.

conversion functi= on:
This doesn't solve the problem, although it does contain = it. The implementation of the conversion function still has the exact same = issue.
If it is based on the underlying integer value then it wil= l silently fail when the two enums go "out of sync". The only rea= son for scoped enums to exist is type safety and that would be thrown out o= f the window there.
This is also the case with your next example = that explicitly uses the underlying type.

Best,
Philip
=C2=A0

--
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/a359f82b-1a89-4dae-8b6e-169a57065f4e= %40isocpp.org.
------=_Part_3830_764046016.1543771047910-- ------=_Part_3829_2144669994.1543771047910-- .