------=_Part_3090_508313440.1543515887055
Content-Type: multipart/alternative;
 boundary="----=_Part_3091_1729670461.1543515887055"

------=_Part_3091_1729670461.1543515887055
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello,

After receiving positive feedback on the sg14 mailing list=20
<https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/zZti8GVLt2U>,=20
I'd now like to share my proposal here.

Abstract:
Scoped enumerations (=E2=80=9Cenum classes=E2=80=9D) provide a type safe al=
ternative to=20
C-style enums.
It can be desirable to have enumerations that share a subset of their=20
enumerators and
there is a natural correspondence between subtyping and adding enumerators=
=20
to enums.
This proposal is for a simple, sound and practically useful extension to=20
the core language
standard to provide a mechanism for subtyping scoped enumerations.

The complete proposal can be read here=20
<https://github.com/ginsbach/CppProposal/blob/release_70/ExtendedScopedEnum=
erations.pdf> and=20
an implementation is available on github=20
<https://github.com/ginsbach/CppProposal>.
I'm looking forward to your feedback!

Thanks,
Philip Ginsbach

--=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/506ba0a8-2d6b-4a4d-8fe8-b5e94d232365%40isocpp.or=
g.

------=_Part_3091_1729670461.1543515887055
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello,</div><div><br></div><div>After receiving posit=
ive feedback on the <a href=3D"https://groups.google.com/a/isocpp.org/forum=
/#!topic/sg14/zZti8GVLt2U">sg14 mailing list</a>, I&#39;d now like to share=
 my proposal here.</div><div><br></div><div><div><div>Abstract:<br class=3D=
"Apple-interchange-newline">Scoped enumerations (=E2=80=9Cenum classes=E2=
=80=9D) provide a type safe alternative to C-style enums.</div><div>It can =
be desirable to have enumerations that share a subset of their enumerators =
and</div><div>there is a natural correspondence between subtyping and addin=
g enumerators to enums.</div><div>This proposal is for a simple, sound and =
practically useful extension to the core language</div><div>standard to pro=
vide a mechanism for subtyping scoped enumerations.</div></div></div><div><=
br></div><div><div>The complete proposal can be read=C2=A0<a href=3D"https:=
//github.com/ginsbach/CppProposal/blob/release_70/ExtendedScopedEnumeration=
s.pdf" target=3D"_blank" rel=3D"nofollow" style=3D"cursor: pointer;">here</=
a>=C2=A0and an implementation is available on=C2=A0<a href=3D"https://githu=
b.com/ginsbach/CppProposal" target=3D"_blank" rel=3D"nofollow" style=3D"cur=
sor: pointer;">github</a>.</div><div>I&#39;m looking forward to your feedba=
ck!</div></div><div><br></div><div>Thanks,</div><div>Philip Ginsbach</div><=
/div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/506ba0a8-2d6b-4a4d-8fe8-b5e94d232365%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/506ba0a8-2d6b-4a4d-8fe8-b5e94d232365=
%40isocpp.org</a>.<br />

------=_Part_3091_1729670461.1543515887055--

------=_Part_3090_508313440.1543515887055--

.

------=_Part_3086_756965234.1543530882222
Content-Type: multipart/alternative;
 boundary="----=_Part_3087_1519690702.1543530882222"

------=_Part_3087_1519690702.1543530882222
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I like your idea, but I am pretty sure it has been proposed and declined=20
before. If my memory serves me there were perceived issues with duplicate=
=20
enumerator values and possibly whether a sub-enum should be able to change=
=20
the value of a parent enumerator (in keeping with how a subclass can=20
override a name). I think you have to address this and I would suggest that=
=20
you use a "as if" strategy stating that the sub-enum is to be defined as if=
=20
the added enumerators were textually appended to those of the base-enum.

Maybe you should also specify if it is legal to *not *add any additional=20
enumerators in the sub-enum, and if allowed, exactly what this means.

Possibly the issue of multiple inheritance should be addressed to. Probably=
=20
best to forbid this, but it could be of interest to merge sets of values,=
=20
and it could possibly be legal if there are no common enumerator names or=
=20
values in both base-enums, except if both the enumerator and value are the=
=20
same (and any specified underlying type of course).

Den torsdag 29 november 2018 kl. 19:24:47 UTC+1 skrev phili...@gmail.com:
>
> Hello,
>
> After receiving positive feedback on the sg14 mailing list=20
> <https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/zZti8GVLt2U>,=
=20
> I'd now like to share my proposal here.
>
> Abstract:
> Scoped enumerations (=E2=80=9Cenum classes=E2=80=9D) provide a type safe =
alternative to=20
> C-style enums.
> It can be desirable to have enumerations that share a subset of their=20
> enumerators and
> there is a natural correspondence between subtyping and adding enumerator=
s=20
> to enums.
> This proposal is for a simple, sound and practically useful extension to=
=20
> the core language
> standard to provide a mechanism for subtyping scoped enumerations.
>
> The complete proposal can be read here=20
> <https://github.com/ginsbach/CppProposal/blob/release_70/ExtendedScopedEn=
umerations.pdf> and=20
> an implementation is available on github=20
> <https://github.com/ginsbach/CppProposal>.
> I'm looking forward to your feedback!
>
> Thanks,
> Philip Ginsbach
>

--=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/82c331a0-fb81-4b67-8a7e-c5a6b8929e00%40isocpp.or=
g.

------=_Part_3087_1519690702.1543530882222
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I like your idea, but I am pretty sure it has been propose=
d and declined before. If my memory serves me there were perceived issues w=
ith duplicate enumerator values and possibly whether a sub-enum should be a=
ble to change the value of a parent enumerator (in keeping with how a subcl=
ass can override a name). I think you have to address this and I would sugg=
est that you use a &quot;as if&quot; strategy stating that the sub-enum is =
to be defined as if the added enumerators were textually appended to those =
of the base-enum.<div><br></div><div>Maybe you should also specify if it is=
 legal to <i>not </i>add any additional enumerators in the sub-enum, and if=
 allowed, exactly what this means.</div><div><br></div><div>Possibly the is=
sue of multiple inheritance should be addressed to. Probably best to forbid=
 this, but it could be of interest to merge sets of values, and it could po=
ssibly be legal if there are no common enumerator names or values in both b=
ase-enums, except if both the enumerator and value are the same (and any sp=
ecified underlying type of course).<br><div><br>Den torsdag 29 november 201=
8 kl. 19:24:47 UTC+1 skrev phili...@gmail.com:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div>Hello,</div><div><br></div><div>After=
 receiving positive feedback on the <a href=3D"https://groups.google.com/a/=
isocpp.org/forum/#!topic/sg14/zZti8GVLt2U" target=3D"_blank" rel=3D"nofollo=
w" onmousedown=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/f=
orum/#!topic/sg14/zZti8GVLt2U&#39;;return true;" onclick=3D"this.href=3D&#3=
9;https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/zZti8GVLt2U&#39=
;;return true;">sg14 mailing list</a>, I&#39;d now like to share my proposa=
l here.</div><div><br></div><div><div><div>Abstract:<br>Scoped enumerations=
 (=E2=80=9Cenum classes=E2=80=9D) provide a type safe alternative to C-styl=
e enums.</div><div>It can be desirable to have enumerations that share a su=
bset of their enumerators and</div><div>there is a natural correspondence b=
etween subtyping and adding enumerators to enums.</div><div>This proposal i=
s for a simple, sound and practically useful extension to the core language=
</div><div>standard to provide a mechanism for subtyping scoped enumeration=
s.</div></div></div><div><br></div><div><div>The complete proposal can be r=
ead=C2=A0<a href=3D"https://github.com/ginsbach/CppProposal/blob/release_70=
/ExtendedScopedEnumerations.pdf" rel=3D"nofollow" target=3D"_blank" onmouse=
down=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgith=
ub.com%2Fginsbach%2FCppProposal%2Fblob%2Frelease_70%2FExtendedScopedEnumera=
tions.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE_f5CeZNAHeg_IuZwkV18F1aX=
8YA&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/u=
rl?q\x3dhttps%3A%2F%2Fgithub.com%2Fginsbach%2FCppProposal%2Fblob%2Frelease_=
70%2FExtendedScopedEnumerations.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjC=
NE_f5CeZNAHeg_IuZwkV18F1aX8YA&#39;;return true;">here</a>=C2=A0and an imple=
mentation is available on=C2=A0<a href=3D"https://github.com/ginsbach/CppPr=
oposal" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;=
https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fginsbach%2FCppPr=
oposal\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFU1FBcDPSzzfpMwY2D2YP3TfhE8g=
&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?=
q\x3dhttps%3A%2F%2Fgithub.com%2Fginsbach%2FCppProposal\x26sa\x3dD\x26sntz\x=
3d1\x26usg\x3dAFQjCNFU1FBcDPSzzfpMwY2D2YP3TfhE8g&#39;;return true;">github<=
/a>.</div><div>I&#39;m looking forward to your feedback!</div></div><div><b=
r></div><div>Thanks,</div><div>Philip Ginsbach</div></div></blockquote></di=
v></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/82c331a0-fb81-4b67-8a7e-c5a6b8929e00%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/82c331a0-fb81-4b67-8a7e-c5a6b8929e00=
%40isocpp.org</a>.<br />

------=_Part_3087_1519690702.1543530882222--

------=_Part_3086_756965234.1543530882222--

.

I think this might be a very useful feature. For instance, when
transitioning from API A to API B (the next major version of A), B
signatures could use a subtype of the enumeration used in A during the
transition period. This would be better than adding unsupported values
to the A enumeration and better than simply repeating the already
existing constants in the new enumeration.
On Thu, Nov 29, 2018 at 8:34 PM Bengt Gustafsson
<bengt.gustafsson@beamways.com> wrote:
>
> I like your idea, but I am pretty sure it has been proposed and declined =
before. If my memory serves me there were perceived issues with duplicate e=
numerator values and possibly whether a sub-enum should be able to change t=
he value of a parent enumerator (in keeping with how a subclass can overrid=
e a name). I think you have to address this and I would suggest that you us=
e a "as if" strategy stating that the sub-enum is to be defined as if the a=
dded enumerators were textually appended to those of the base-enum.
>
> Maybe you should also specify if it is legal to not add any additional en=
umerators in the sub-enum, and if allowed, exactly what this means.
>
> Possibly the issue of multiple inheritance should be addressed to. Probab=
ly best to forbid this, but it could be of interest to merge sets of values=
, and it could possibly be legal if there are no common enumerator names or=
 values in both base-enums, except if both the enumerator and value are the=
 same (and any specified underlying type of course).
>
> Den torsdag 29 november 2018 kl. 19:24:47 UTC+1 skrev phili...@gmail.com:
>>
>> Hello,
>>
>> After receiving positive feedback on the sg14 mailing list, I'd now like=
 to share my proposal here.
>>
>> Abstract:
>> Scoped enumerations (=E2=80=9Cenum classes=E2=80=9D) provide a type safe=
 alternative to C-style enums.
>> It can be desirable to have enumerations that share a subset of their en=
umerators and
>> there is a natural correspondence between subtyping and adding enumerato=
rs to enums.
>> This proposal is for a simple, sound and practically useful extension to=
 the core language
>> standard to provide a mechanism for subtyping scoped enumerations.
>>
>> The complete proposal can be read here and an implementation is availabl=
e on github.
>> I'm looking forward to your feedback!
>>
>> Thanks,
>> Philip Ginsbach
>
> --
> 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/isoc=
pp.org/d/msgid/std-proposals/82c331a0-fb81-4b67-8a7e-c5a6b8929e00%40isocpp.=
org.

--=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/CAMSdZ4Zf%2B0meeQ4hzwZVZ_j88u5gpB_qd_XmsR-OfrhCy=
Yndhw%40mail.gmail.com.

.

------=_Part_3572_121023110.1543638940731
Content-Type: multipart/alternative;
 boundary="----=_Part_3573_713048252.1543638940731"

------=_Part_3573_713048252.1543638940731
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Thursday, November 29, 2018 at 12:24:47 PM UTC-6, phili...@gmail.com=20
wrote:
>
> Hello,
>
> After receiving positive feedback on the sg14 mailing list=20
> <https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/zZti8GVLt2U>,=
=20
> I'd now like to share my proposal here.
>
> Abstract:
> Scoped enumerations (=E2=80=9Cenum classes=E2=80=9D) provide a type safe =
alternative to=20
> C-style enums.
> It can be desirable to have enumerations that share a subset of their=20
> enumerators and
> there is a natural correspondence between subtyping and adding enumerator=
s=20
> to enums.
> This proposal is for a simple, sound and practically useful extension to=
=20
> the core language
> standard to provide a mechanism for subtyping scoped enumerations.
>
> The complete proposal can be read here=20
> <https://github.com/ginsbach/CppProposal/blob/release_70/ExtendedScopedEn=
umerations.pdf> and=20
> an implementation is available on github=20
> <https://github.com/ginsbach/CppProposal>.
> I'm looking forward to your feedback!
>
> Thanks,
> Philip Ginsbach
>

Hi Philip.

Page 2 of that proposal says:

    3. Values of the base enumeration can be safely and implicitly cast to=
=20
values of the
     extended enumeration type.

  Note that the last property is essentially inverse to the
  effects of class inheritance.
 =20
The reason why it's the reverse is that the enum's are
somewhat like tagged variants with the same type, empty, for
each tagged type.  The subtype relationship for variants is
the opposite of that for structs, as claimed on page 2 of:

  http://web.cecs.pdx.edu/~mpj/pubs/96-3.pdf
 =20
Or, more intuitively, since the super type (e.g. TokenType)
is simply a subset of the derived type (e.g. SyntaxType), an
element of the supertype can be implicitly converted to the
derived type.
 =20
Attached is a slightly modified version of the code on pages
3-5 of your proposal.  It includes a macro:

  USE_EXTENDED_SCOPE_ENUM
 =20
which is used to turn the use of your proposed feature
on/off and highlights where the changes to existing c++ code
occurs. This might make the impact of the proposal easier to see.
   =20
HTH.

-regards,
Larry
=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a1d6b842-ff21-4779-bc0a-0849d404e64e%40isocpp.or=
g.

------=_Part_3573_713048252.1543638940731
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, November 29, 2018 at 12:24:47 PM UTC-=
6, phili...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><div>Hello,</div><div><br></div><div>After receiving positiv=
e feedback on the <a href=3D"https://groups.google.com/a/isocpp.org/forum/#=
!topic/sg14/zZti8GVLt2U" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/=
zZti8GVLt2U&#39;;return true;" onclick=3D"this.href=3D&#39;https://groups.g=
oogle.com/a/isocpp.org/forum/#!topic/sg14/zZti8GVLt2U&#39;;return true;">sg=
14 mailing list</a>, I&#39;d now like to share my proposal here.</div><div>=
<br></div><div><div><div>Abstract:<br>Scoped enumerations (=E2=80=9Cenum cl=
asses=E2=80=9D) provide a type safe alternative to C-style enums.</div><div=
>It can be desirable to have enumerations that share a subset of their enum=
erators and</div><div>there is a natural correspondence between subtyping a=
nd adding enumerators to enums.</div><div>This proposal is for a simple, so=
und and practically useful extension to the core language</div><div>standar=
d to provide a mechanism for subtyping scoped enumerations.</div></div></di=
v><div><br></div><div><div>The complete proposal can be read=C2=A0<a href=
=3D"https://github.com/ginsbach/CppProposal/blob/release_70/ExtendedScopedE=
numerations.pdf" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.hre=
f=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fginsbac=
h%2FCppProposal%2Fblob%2Frelease_70%2FExtendedScopedEnumerations.pdf\x26sa\=
x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE_f5CeZNAHeg_IuZwkV18F1aX8YA&#39;;return =
true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A=
%2F%2Fgithub.com%2Fginsbach%2FCppProposal%2Fblob%2Frelease_70%2FExtendedSco=
pedEnumerations.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE_f5CeZNAHeg_Iu=
ZwkV18F1aX8YA&#39;;return true;">here</a>=C2=A0and an implementation is ava=
ilable on=C2=A0<a href=3D"https://github.com/ginsbach/CppProposal" rel=3D"n=
ofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;https://www.goog=
le.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fginsbach%2FCppProposal\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNFU1FBcDPSzzfpMwY2D2YP3TfhE8g&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F=
%2Fgithub.com%2Fginsbach%2FCppProposal\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAF=
QjCNFU1FBcDPSzzfpMwY2D2YP3TfhE8g&#39;;return true;">github</a>.</div><div>I=
&#39;m looking forward to your feedback!</div></div><div><br></div><div>Tha=
nks,</div><div>Philip Ginsbach</div></div></blockquote><div><br></div><div>=
Hi Philip.</div><div><br></div><div>Page 2 of that proposal says:<br><br>=
=C2=A0=C2=A0=C2=A0 3. Values of the base enumeration can be safely and impl=
icitly cast to values of the<br>=C2=A0=C2=A0=C2=A0=C2=A0 extended enumerati=
on type.<br><br>=C2=A0 Note that the last property is essentially inverse t=
o the<br>=C2=A0 effects of class inheritance.<br>=C2=A0 <br>The reason why =
it&#39;s the reverse is that the enum&#39;s are<br>somewhat like tagged var=
iants with the same type, empty, for<br>each tagged type.=C2=A0 The subtype=
 relationship for variants is<br>the opposite of that for structs, as claim=
ed on page 2 of:<br><br>=C2=A0 http://web.cecs.pdx.edu/~mpj/pubs/96-3.pdf<b=
r>=C2=A0 <br>Or, more intuitively, since the super type (e.g. TokenType)<br=
>is simply a subset of the derived type (e.g. SyntaxType), an<br>element of=
 the supertype can be implicitly converted to the<br>derived type.<br>=C2=
=A0 <br>Attached is a slightly modified version of the code on pages<br>3-5=
 of your proposal.=C2=A0 It includes a macro:<br><br>=C2=A0 USE_EXTENDED_SC=
OPE_ENUM<br>=C2=A0 <br>which is used to turn the use of your proposed featu=
re<br>on/off and highlights where the changes to existing c++ code<br>occur=
s. This might make the impact of the proposal easier to see.<br>=C2=A0=C2=
=A0=C2=A0 <br>HTH.<br><br>-regards,<br>Larry<br></div><div>=C2=A0</div></di=
v>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a1d6b842-ff21-4779-bc0a-0849d404e64e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a1d6b842-ff21-4779-bc0a-0849d404e64e=
%40isocpp.org</a>.<br />

------=_Part_3573_713048252.1543638940731--

------=_Part_3572_121023110.1543638940731
Content-Type: text/x-c++src; charset=UTF-8; name=parse.cpp
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename=parse.cpp
X-Attachment-Id: 4aefc9ab-f538-436a-a841-e869d42263e5
Content-ID: <4aefc9ab-f538-436a-a841-e869d42263e5>

//Purpose:
//  Test parse code from:
//    https://raw.githubusercontent.com/ginsbach/CppProposal/release_70/Ext=
endedScopedEnumerations.pdf
//=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
#include <string>
#include <vector>
#include <iostream>
using namespace std;
//#define USE_EXTENDED_SCOPE_ENUM

#ifdef USE_EXTENDED_SCOPE_ENUM
#else
using enum_underlying_type =3D unsigned;
#endif
// Tokens can either be constants or binary operators . The numeric values =
are
// intentionally arbitrary .
  enum class=20
TokenType
#ifdef USE_EXTENDED_SCOPE_ENUM=20
  { constant  =3D211=20
  , binary_op =3D223=20
#else
  : enum_underlying_type
  { constant
  , binary_op
#endif =20
  };

struct Token {
    TokenType type ;
    string    value ;
};

// A node in the parse tree can either be a leaf ( i . e . a token ) or a b=
inary
// expression . We can elegantly express this with Extended Scoped Enumerat=
ions .
// Without this feature , we =E2=80=99d have to duplicate the entries in To=
kenType and
// we =E2=80=99d have no guaratees when casting from TokenType to SyntaxTyp=
e , which can
// be done implicitly and safely with Extended Scoped Enumerations .
  enum class=20
SyntaxType=20
#ifdef USE_EXTENDED_SCOPE_ENUM=20
  : TokenType=20
  { binary_exp /* =3D 224 */=20
#else
  //This method has obvisous disadvantage of=20
  //repeating the enumerators in TokenType.
  : enum_underlying_type
  { constant
  , binary_op
  , binary_exp
#endif =20
  };

struct Syntax {
    SyntaxType        type ;
    vector < Syntax > children ;
    string            value ;
};

Syntax parse ( vector < Token > tokens )
{
    vector < Syntax > stack ;

    for ( Token token : tokens )
    {
         // We can construct an instance of Syntax with token . type , alth=
ough it
         // is actually of type TokenType , because it is implicitly cast .
         // Without Extended Scoped Enumerations , we =E2=80=99d either nee=
d a big switch
         // statement or we =E2=80=99d have to use an unsafe cast , relying=
 on the
         // underlying numeric values for elements in TokenType to be the s=
ame as
         // in SyntaxType . That would make obsolete the use of enum class =
,
         // as the advantage over C - style enums is supposedly type safety=
 .
         stack=20
         . push_back=20
#ifdef USE_EXTENDED_SCOPE_ENUM=20
           ({ token . type //TokenType auto conversion -> SyntaxType
#else
           ({ SyntaxType(token . type ) //coerce conversion TokenType -> Sy=
ntaxType
#endif          =20
           , {}=20
           , token . value=20
           });
         while ( stack . size () >=3D3 &&
                 stack [ stack . size () -1]. type !=3D SyntaxType :: binar=
y_op &&
                 stack [ stack . size () -2]. type =3D=3D SyntaxType :: bin=
ary_op &&
                 stack [ stack . size () -3]. type !=3D SyntaxType :: binar=
y_op )
         {
             stack [ stack . size () -3] =3D Syntax { SyntaxType :: binary_=
exp ,
                                                    { stack [ stack . size =
() -3] ,
                                                      stack [ stack . size =
() -2] ,
                                                      stack [ stack . size =
() -1]}};
             stack . resize ( stack . size () - 2);
         }
    }

    if ( stack . size () =3D=3D 1)
          return stack [0];
    throw ;
}

double evaluate ( Syntax syntax )
{
    switch ( syntax . type ) {
    case SyntaxType :: constant :
        return atof ( syntax . value . c_str ());
    case SyntaxType :: binary_exp :
        double left =3D evaluate ( syntax . children [0]);
        double right =3D evaluate ( syntax . children [2]);
        if ( syntax . children [1]. value =3D=3D " + " ) return left + righ=
t ;
        if ( syntax . children [1]. value =3D=3D " -" ) return left - right=
 ;
        if ( syntax . children [1]. value =3D=3D " * " ) return left * righ=
t ;
        if ( syntax . children [1]. value =3D=3D " / " ) return left / righ=
t ;
    }
        throw ;
}

int main ()
{
    vector < Token > tokens {{ TokenType :: constant , " 4.0 " } ,
                             { TokenType :: binary_op , " * " } ,
                             { TokenType :: constant , " 2 " } ,
                             { TokenType :: binary_op , " + " } ,
                             { TokenType :: constant , " 1.5 " }};

    Syntax syntax =3D parse ( tokens );
    for ( Token token : tokens )
        cout << token.value;
    cout << "=3D" << evaluate ( syntax ) << " \n " ;

    return 0;
}

------=_Part_3572_121023110.1543638940731--

.

------=_Part_3581_1696539954.1543664979643
Content-Type: multipart/alternative;
 boundary="----=_Part_3582_2110312753.1543664979643"

------=_Part_3582_2110312753.1543664979643
Content-Type: text/plain; charset="UTF-8"

Hi Bengt,

Thanks for the suggestions. I think as for the duplicate enumerator values
I agree entirely with your proposed solution: it would have to be allowed
"as if" textually appended. That's of course what my implementation does
anyway and it seems the clearest thing to specify. This means no overrides.

As for empty extensions - I don't see any reason not to allow it. Enum
classes can be entirely empty as well after all. It would simply mean we
have two types that are essentially the same but allow implicit casting
only in one direction.

Multiple inheritance came up before. There are definitely legitimate use
cases such as partitioning an enum into several sub-enums.
However it opens up a huge can of worms and all the problems that it brings
up (no overlapping values, same base types, you mentioned them) would seem
very unintuitive to programmers. I think it's best to be avoided for now.

Can you give me a hint where to look for the previous rejection, it seems
pretty critical that I directly address what came up in the discussion
there. Or move on if it was in fact the exact same proposal.

I will update the pdf with clarifications as to multiple inheritance and
the "as if" convention.

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/43b3f4ec-fd19-4144-bf24-067ce587e071%40isocpp.org.

------=_Part_3582_2110312753.1543664979643
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Bengt,</div><div><br></div><div>Thanks for the sug=
gestions. I think as for the duplicate enumerator values I agree entirely w=
ith your proposed solution: it would have to be allowed &quot;as if&quot; t=
extually appended. That&#39;s of course what my implementation does anyway =
and it seems the clearest thing to specify. This means no overrides.</div><=
div><br></div><div>As for empty extensions - I don&#39;t see any reason not=
 to allow it. Enum classes can be entirely empty as well after all. It woul=
d simply mean we have two types that are essentially the same but allow imp=
licit casting only in one direction.</div><div><br></div><div>Multiple inhe=
ritance came up before. There are definitely legitimate use cases such as p=
artitioning an enum into several sub-enums.</div><div>However it opens up a=
 huge can of worms and all the problems that it brings up (no overlapping v=
alues, same base types, you mentioned them) would seem very unintuitive to =
programmers. I think it&#39;s best to be avoided for now.</div><div><br></d=
iv><div>Can you give me a hint where to look for the previous rejection, it=
 seems pretty critical that I directly address what came up in the discussi=
on there. Or move on if it was in fact the exact same proposal.</div><div><=
br></div><div>I will update the pdf with clarifications as to multiple inhe=
ritance and the &quot;as if&quot; convention.</div><div><br></div><div>Best=
,</div><div>Philip</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/43b3f4ec-fd19-4144-bf24-067ce587e071%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/43b3f4ec-fd19-4144-bf24-067ce587e071=
%40isocpp.org</a>.<br />

------=_Part_3582_2110312753.1543664979643--

------=_Part_3581_1696539954.1543664979643--

.

------=_Part_459_972236796.1543665050446
Content-Type: multipart/alternative;
 boundary="----=_Part_460_190238791.1543665050447"

------=_Part_460_190238791.1543665050447
Content-Type: text/plain; charset="UTF-8"

Hi Bernardo,

Thanks for the encouragement!

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/08e0e2d8-640a-4fa3-8dc5-b0fdd157caac%40isocpp.org.

------=_Part_460_190238791.1543665050447
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Bernardo,</div><div><br></div>Thanks for the encou=
ragement!<div><br></div><div>Best,<br>Philip</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/08e0e2d8-640a-4fa3-8dc5-b0fdd157caac%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/08e0e2d8-640a-4fa3-8dc5-b0fdd157caac=
%40isocpp.org</a>.<br />

------=_Part_460_190238791.1543665050447--

------=_Part_459_972236796.1543665050446--

.

------=_Part_3684_694923393.1543665476220
Content-Type: multipart/alternative;
 boundary="----=_Part_3685_1255621492.1543665476220"

------=_Part_3685_1255621492.1543665476220
Content-Type: text/plain; charset="UTF-8"

Hi Larry,

Thanks, that's a much nicer way of stating it.
I'll try to make clearer in the proposal that this inverse relationship
comes immediately with the territory and isn't some weird quirk of my
proposal.

These ifdefs might make it clearer, I agree. Will insert them.

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/7f5f6fe6-7e15-4811-941b-622c89a818a2%40isocpp.org.

------=_Part_3685_1255621492.1543665476220
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Larry,<br>
<br>
Thanks, that&#39;s a much nicer way of stating it.<br>
I&#39;ll try to make clearer in the proposal that this inverse relationship=
 comes=20
immediately with the territory and isn&#39;t some weird quirk of my=20
proposal.<br>
<br>
These ifdefs might make it clearer, I agree. Will insert them.<br>
<br>
Best,<br>
Philip<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7f5f6fe6-7e15-4811-941b-622c89a818a2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7f5f6fe6-7e15-4811-941b-622c89a818a2=
%40isocpp.org</a>.<br />

------=_Part_3685_1255621492.1543665476220--

------=_Part_3684_694923393.1543665476220--

.

------=_Part_2498_1616524114.1543665509875
Content-Type: multipart/alternative;
 boundary="----=_Part_2499_1897532881.1543665509875"

------=_Part_2499_1897532881.1543665509875
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Re: The rejection I can't remember any details, I just have a fairly strong=
=20
memory that a similar (or possibly identical) proposal has fallen before.=
=20
You having a working implementation may be reason enough for it to be able=
=20
to move forward!

Den l=C3=B6rdag 1 december 2018 kl. 12:49:39 UTC+1 skrev phili...@gmail.com=
:
>
> Hi Bengt,
>
> Thanks for the suggestions. I think as for the duplicate enumerator value=
s=20
> I agree entirely with your proposed solution: it would have to be allowed=
=20
> "as if" textually appended. That's of course what my implementation does=
=20
> anyway and it seems the clearest thing to specify. This means no override=
s.
>
> As for empty extensions - I don't see any reason not to allow it. Enum=20
> classes can be entirely empty as well after all. It would simply mean we=
=20
> have two types that are essentially the same but allow implicit casting=
=20
> only in one direction.
>
> Multiple inheritance came up before. There are definitely legitimate use=
=20
> cases such as partitioning an enum into several sub-enums.
> However it opens up a huge can of worms and all the problems that it=20
> brings up (no overlapping values, same base types, you mentioned them)=20
> would seem very unintuitive to programmers. I think it's best to be avoid=
ed=20
> for now.
>
> Can you give me a hint where to look for the previous rejection, it seems=
=20
> pretty critical that I directly address what came up in the discussion=20
> there. Or move on if it was in fact the exact same proposal.
>
> I will update the pdf with clarifications as to multiple inheritance and=
=20
> the "as if" convention.
>
> Best,
> Philip
>

--=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/8a747a37-4024-409a-9b70-475aa1eb96f2%40isocpp.or=
g.

------=_Part_2499_1897532881.1543665509875
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Re: The rejection I can&#39;t remember any details, I just=
 have a fairly strong memory that a similar (or possibly identical) proposa=
l has fallen before. You having a working implementation may be reason enou=
gh for it to be able to move forward!<br><br>Den l=C3=B6rdag 1 december 201=
8 kl. 12:49:39 UTC+1 skrev phili...@gmail.com:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div>Hi Bengt,</div><div><br></div><div>Th=
anks for the suggestions. I think as for the duplicate enumerator values I =
agree entirely with your proposed solution: it would have to be allowed &qu=
ot;as if&quot; textually appended. That&#39;s of course what my implementat=
ion does anyway and it seems the clearest thing to specify. This means no o=
verrides.</div><div><br></div><div>As for empty extensions - I don&#39;t se=
e any reason not to allow it. Enum classes can be entirely empty as well af=
ter all. It would simply mean we have two types that are essentially the sa=
me but allow implicit casting only in one direction.</div><div><br></div><d=
iv>Multiple inheritance came up before. There are definitely legitimate use=
 cases such as partitioning an enum into several sub-enums.</div><div>Howev=
er it opens up a huge can of worms and all the problems that it brings up (=
no overlapping values, same base types, you mentioned them) would seem very=
 unintuitive to programmers. I think it&#39;s best to be avoided for now.</=
div><div><br></div><div>Can you give me a hint where to look for the previo=
us rejection, it seems pretty critical that I directly address what came up=
 in the discussion there. Or move on if it was in fact the exact same propo=
sal.</div><div><br></div><div>I will update the pdf with clarifications as =
to multiple inheritance and the &quot;as if&quot; convention.</div><div><br=
></div><div>Best,</div><div>Philip</div></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8a747a37-4024-409a-9b70-475aa1eb96f2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8a747a37-4024-409a-9b70-475aa1eb96f2=
%40isocpp.org</a>.<br />

------=_Part_2499_1897532881.1543665509875--

------=_Part_2498_1616524114.1543665509875--

.

------=_Part_3669_1995601322.1543671719436
Content-Type: multipart/alternative;
 boundary="----=_Part_3670_1515415363.1543671719436"

------=_Part_3670_1515415363.1543671719436
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Another thing you may want to define is what std::underlying_type should=20
return for a derived enum. Under the as-if rule it should be the underlying=
=20
integer type, but looking at the syntax and comparing what it does today it=
=20
could be the base-enum.

I think I would prefer the integer type to keep the as-if rule clean.=20
Getting the base enum should be part of static reflection. So the=20
reflection aspects will eventually have to be covered in a complete=20
proposal. As reflection is still in flux (at least syntactically) this may=
=20
not be an immediate concern.

Den l=C3=B6rdag 1 december 2018 kl. 12:49:39 UTC+1 skrev phili...@gmail.com=
:
>
> Hi Bengt,
>
> Thanks for the suggestions. I think as for the duplicate enumerator value=
s=20
> I agree entirely with your proposed solution: it would have to be allowed=
=20
> "as if" textually appended. That's of course what my implementation does=
=20
> anyway and it seems the clearest thing to specify. This means no override=
s.
>
> As for empty extensions - I don't see any reason not to allow it. Enum=20
> classes can be entirely empty as well after all. It would simply mean we=
=20
> have two types that are essentially the same but allow implicit casting=
=20
> only in one direction.
>
> Multiple inheritance came up before. There are definitely legitimate use=
=20
> cases such as partitioning an enum into several sub-enums.
> However it opens up a huge can of worms and all the problems that it=20
> brings up (no overlapping values, same base types, you mentioned them)=20
> would seem very unintuitive to programmers. I think it's best to be avoid=
ed=20
> for now.
>
> Can you give me a hint where to look for the previous rejection, it seems=
=20
> pretty critical that I directly address what came up in the discussion=20
> there. Or move on if it was in fact the exact same proposal.
>
> I will update the pdf with clarifications as to multiple inheritance and=
=20
> the "as if" convention.
>
> Best,
> Philip
>

--=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/d54cc535-542f-4a7b-80f9-b4dab85e0ca4%40isocpp.or=
g.

------=_Part_3670_1515415363.1543671719436
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Another thing you may want to define is what std::underlyi=
ng_type should return for a derived enum. Under the as-if rule it should be=
 the underlying integer type, but looking at the syntax and comparing what =
it does today it could be the base-enum.<div><br></div><div>I think I would=
 prefer the integer type to keep the as-if rule clean. Getting the base enu=
m should be part of static reflection. So the reflection aspects will event=
ually have to be covered in a complete proposal. As reflection is still in =
flux (at least syntactically) this may not be an immediate concern.<br><br>=
Den l=C3=B6rdag 1 december 2018 kl. 12:49:39 UTC+1 skrev phili...@gmail.com=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Hi Beng=
t,</div><div><br></div><div>Thanks for the suggestions. I think as for the =
duplicate enumerator values I agree entirely with your proposed solution: i=
t would have to be allowed &quot;as if&quot; textually appended. That&#39;s=
 of course what my implementation does anyway and it seems the clearest thi=
ng to specify. This means no overrides.</div><div><br></div><div>As for emp=
ty extensions - I don&#39;t see any reason not to allow it. Enum classes ca=
n be entirely empty as well after all. It would simply mean we have two typ=
es that are essentially the same but allow implicit casting only in one dir=
ection.</div><div><br></div><div>Multiple inheritance came up before. There=
 are definitely legitimate use cases such as partitioning an enum into seve=
ral sub-enums.</div><div>However it opens up a huge can of worms and all th=
e problems that it brings up (no overlapping values, same base types, you m=
entioned them) would seem very unintuitive to programmers. I think it&#39;s=
 best to be avoided for now.</div><div><br></div><div>Can you give me a hin=
t where to look for the previous rejection, it seems pretty critical that I=
 directly address what came up in the discussion there. Or move on if it wa=
s in fact the exact same proposal.</div><div><br></div><div>I will update t=
he pdf with clarifications as to multiple inheritance and the &quot;as if&q=
uot; convention.</div><div><br></div><div>Best,</div><div>Philip</div></div=
></blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d54cc535-542f-4a7b-80f9-b4dab85e0ca4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d54cc535-542f-4a7b-80f9-b4dab85e0ca4=
%40isocpp.org</a>.<br />

------=_Part_3670_1515415363.1543671719436--

------=_Part_3669_1995601322.1543671719436--

.

------=_Part_3762_273739129.1543671884593
Content-Type: multipart/alternative;
 boundary="----=_Part_3763_544513372.1543671884593"

------=_Part_3763_544513372.1543671884593
Content-Type: text/plain; charset="UTF-8"

Hi Bengt,

That's an interesting detail to fill in, thanks. I will add something about
that to the pdf as well. I think it should absolutely be the integer and
not the base enum, just as you suggest.

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/9e3bba78-04c2-42d5-b522-2712932c1659%40isocpp.org.

------=_Part_3763_544513372.1543671884593
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Bengt,<div><br></div><div>That&#39;s an interesting det=
ail to fill in, thanks. I will add something about that to the pdf as well.=
 I think it should absolutely be the integer and not the base enum, just as=
 you suggest.</div><div><br></div><div>Best,<br>Philip</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9e3bba78-04c2-42d5-b522-2712932c1659%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9e3bba78-04c2-42d5-b522-2712932c1659=
%40isocpp.org</a>.<br />

------=_Part_3763_544513372.1543671884593--

------=_Part_3762_273739129.1543671884593--

.

------=_Part_3668_967179773.1543715365131
Content-Type: multipart/alternative;
 boundary="----=_Part_3669_74524406.1543715365131"

------=_Part_3669_74524406.1543715365131
Content-Type: text/plain; charset="UTF-8"

Hi all,

I have updated the proposal
<https://github.com/ginsbach/CppProposal/blob/release_70/ExtendedScopedEnumerations.pdf> to
reflect some of your feedback:
Bengt: "as if" semantics, empty extensions, multiple inheritance,
std::underlying_type
Larry: ifdefs in code example
Myself: implicit integral types

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/cffbc45a-406b-444b-a52f-64cedd955cbd%40isocpp.org.

------=_Part_3669_74524406.1543715365131
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<div><br></div><div>I have updated the <a href=3D"h=
ttps://github.com/ginsbach/CppProposal/blob/release_70/ExtendedScopedEnumer=
ations.pdf">proposal</a>=C2=A0to reflect some of your feedback:</div><div>B=
engt: &quot;as if&quot; semantics, empty extensions, multiple inheritance, =
std::underlying_type</div><div>Larry: ifdefs in code example</div><div>Myse=
lf: implicit integral types</div><div><br></div><div>Best,<br>Philip</div><=
/div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cffbc45a-406b-444b-a52f-64cedd955cbd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cffbc45a-406b-444b-a52f-64cedd955cbd=
%40isocpp.org</a>.<br />

------=_Part_3669_74524406.1543715365131--

------=_Part_3668_967179773.1543715365131--

.

--000000000000f3e747057c06f18a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Mechnically WHAT you are proposing is pretty clear.  You need to do a
better job on the WHY.

Concretely, in your motivation section, I would find and highlight some
examples in real world open source code where availability of this feature,
if it was used, would make things better.

When we were proposing nested namespaces (which got accepted into C++17) we
pointed to boost, and showed that they could be applied 5000+ times there.

You need to do something similiar, otherwise EWG is just going to ask what
the problem is this is trying to address.  Proposals are only accepted if
they are thought to solve an important problem faced by real world C++
programmers.

On Fri, Nov 30, 2018 at 4:24 AM <philipgins@gmail.com> wrote:

> Hello,
>
> After receiving positive feedback on the sg14 mailing list
> <https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/zZti8GVLt2U>,
> I'd now like to share my proposal here.
>
> Abstract:
> Scoped enumerations (=E2=80=9Cenum classes=E2=80=9D) provide a type safe =
alternative to
> C-style enums.
> It can be desirable to have enumerations that share a subset of their
> enumerators and
> there is a natural correspondence between subtyping and adding enumerator=
s
> to enums.
> This proposal is for a simple, sound and practically useful extension to
> the core language
> standard to provide a mechanism for subtyping scoped enumerations.
>
> The complete proposal can be read here
> <https://github.com/ginsbach/CppProposal/blob/release_70/ExtendedScopedEn=
umerations.pdf> and
> an implementation is available on github
> <https://github.com/ginsbach/CppProposal>.
> I'm looking forward to your feedback!
>
> Thanks,
> Philip Ginsbach
>
> --
> 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/506ba0a8-2d6=
b-4a4d-8fe8-b5e94d232365%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/506ba0a8-2d=
6b-4a4d-8fe8-b5e94d232365%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=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/CAB%2B4KHLXkQGRhrrJ7C4PwzN-L_%3DwaGOfzQjUj-1bpfC=
uw3UX3A%40mail.gmail.com.

--000000000000f3e747057c06f18a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Mechnically WHAT you are proposing is pretty clear.=C2=A0 =
You need to do a better job on the WHY.<div><br></div><div>Concretely, in y=
our motivation section, I would find and highlight some examples in real wo=
rld open source code where availability of this feature, if it was used, wo=
uld make things better.<div><br></div><div>When we were proposing nested na=
mespaces (which got accepted into C++17) we pointed to boost, and showed th=
at they could be applied 5000+ times there.<br></div><div><br></div><div>Yo=
u need to do something similiar, otherwise EWG is just going to ask what th=
e problem is this is trying to address.=C2=A0 Proposals are only accepted i=
f they are thought to solve an important problem faced by real world C++ pr=
ogrammers.</div><div><br></div><div><div class=3D"gmail_quote"><div dir=3D"=
ltr">On Fri, Nov 30, 2018 at 4:24 AM &lt;<a href=3D"mailto:philipgins@gmail=
..com">philipgins@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr"><div>Hello,</div><div><br></div>=
<div>After receiving positive feedback on the <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/forum/#!topic/sg14/zZti8GVLt2U" target=3D"_blank">sg14=
 mailing list</a>, I&#39;d now like to share my proposal here.</div><div><b=
r></div><div><div><div>Abstract:<br class=3D"m_-1021837472551496723Apple-in=
terchange-newline">Scoped enumerations (=E2=80=9Cenum classes=E2=80=9D) pro=
vide a type safe alternative to C-style enums.</div><div>It can be desirabl=
e to have enumerations that share a subset of their enumerators and</div><d=
iv>there is a natural correspondence between subtyping and adding enumerato=
rs to enums.</div><div>This proposal is for a simple, sound and practically=
 useful extension to the core language</div><div>standard to provide a mech=
anism for subtyping scoped enumerations.</div></div></div><div><br></div><d=
iv><div>The complete proposal can be read=C2=A0<a href=3D"https://github.co=
m/ginsbach/CppProposal/blob/release_70/ExtendedScopedEnumerations.pdf" rel=
=3D"nofollow" target=3D"_blank">here</a>=C2=A0and an implementation is avai=
lable on=C2=A0<a href=3D"https://github.com/ginsbach/CppProposal" rel=3D"no=
follow" target=3D"_blank">github</a>.</div><div>I&#39;m looking forward to =
your feedback!</div></div><div><br></div><div>Thanks,</div><div>Philip Gins=
bach</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/506ba0a8-2d6b-4a4d-8fe8-b5e94d232365%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/506ba0a8-2d6b-=
4a4d-8fe8-b5e94d232365%40isocpp.org</a>.<br>
</blockquote></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHLXkQGRhrrJ7C4PwzN-L_%3DwaGOf=
zQjUj-1bpfCuw3UX3A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHLXkQ=
GRhrrJ7C4PwzN-L_%3DwaGOfzQjUj-1bpfCuw3UX3A%40mail.gmail.com</a>.<br />

--000000000000f3e747057c06f18a--

.

This is a multi-part message in MIME format.
--------------05EC378C03A1B83C10DA678F
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 02/12/2018 =C3=A0 02:49, philipgins@gmail.com a =C3=A9crit=C2=A0:
> Hi all,
>
> I have updated the proposal=20
> <https://github.com/ginsbach/CppProposal/blob/release_70/ExtendedScopedEn=
umerations.pdf>=C2=A0to=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".

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=20
(as ADA does - see=20
http://www.adaic.org/resources/add_content/standards/05rm/html/RM-3-5-1.htm=
l).=20
Have you considered this possibility? Are you sure that the common case=20
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=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.

With scoped enums you have that the underlying type is seen as a=20
representation type, not as a super-type.

So we have that : is used either to separate the super-type for class,=20
either to separate the underlying type for scoped enums or either to=20
separate the sub-type for your proposal. I don't know if this is good.

In the rational for non-having multiple extensions when you say that=20
"fail if any of their enumerators have the same value", I don't see why=20
this should fail. I agree that having the same enumerator name would=20
introduce some problems, if you want strict extensions.


Next follows some alternatives solution to the problem you are trying to=20
solve. Please, let me if you have considered some of them.


*Current solution using C++2a*

The example using the current standard is not fair as you can now define

 =C2=A0=C2=A0=C2=A0 enum class TokenType : int { constant =3D 211, binary_o=
p =3D 223 };

 =C2=A0=C2=A0=C2=A0 enum class SyntaxType : int { constant =3D TokenType::c=
onstant,=20
binary_op =3D TokenType::binary_op, binary_expr};

and adding a conversion function

 =C2=A0=C2=A0=C2=A0 SyntaxType to_SyntaxType (TokenType);

So the single additional difference between your proposal and the=20
current solution would be to call explicitly this conversion

 =C2=A0=C2=A0=C2=A0 stack.push_back({toke.type, {}, toke.value})

versus

 =C2=A0=C2=A0=C2=A0 stack.push_back({*to_SyntaxType*(toke.type), {}, toke.v=
alue})


This has the drawback however that the relation is not transitive, and=20
we would need to define more conversion functions.


*Alternative*

Next follows an alternative based on the possibility to define "implicit=20
constructors/conversions on an enum class" (this feature doesn't exists=20
evidently).

This could allow to define enum "super-typing" and "sub-typing" at the=20
same time, but has the drawback that conversions are not transitive :(

The result is cumbersome, I admit, but I like the ability to define any=20
kind of super-typing, sub-typing.


Your Token example could be defined as follows:

enum class SyntaxType : int { constant =3D TokenType::constant, binary_op=
=20
=3D TokenType::binary_op, binary_expr}

*{ // here we start to be able to define operations on a enum*

**

 =C2=A0=C2=A0=C2=A0 SyntaxType(TokenType e) {

 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 underlying(*this) =3D underlying(e);=
 *// extension to refer to=20
the representation of an enum*

 =C2=A0=C2=A0=C2=A0 }

 =C2=A0=C2=A0=C2=A0 explicit operator TokenType() {

 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [[expects : is_enumerator_value=
<TokenType>(underlying(*this))=20
]] *// is_enumerator_value states if a underlying value is the value of=20
one of the enumerators of the enum type*

 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 return TokenType(underlying(*this));

};


Next follows the typical sub-type example for Day and WeekDay.

enum class Day : int { Mon,=C2=A0Tue,=C2=A0Wed,=C2=A0Thu,=C2=A0Fri,=C2=A0Sa=
t,=C2=A0Sun };

enum class Weekday : int { Mon,=C2=A0Tue,=C2=A0Wed,=C2=A0Thu,=C2=A0Fri }

{

 =C2=A0=C2=A0=C2=A0 explicit Weekday(Day e) {

 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [[expects : is_enumerator_value=
<Weekday>(underlying(e)) ]]

 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 underlying(*this) =3D underlying(e);

 =C2=A0=C2=A0=C2=A0 }

 =C2=A0=C2=A0=C2=A0 implicit operator Day() {

 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 return Day(underlying(*this));

 =C2=A0=C2=A0=C2=A0 }

};

*Ideal*

IMHO, iIdeally we should be able to define the super-type, sub-type with=20
some kind of syntactic sugar as

enum class SyntaxType *>:* TokenType { binary_expr }; // extension

enum class Weekday *:<*=C2=A0 Day=C2=A0 { Mon ... Fri }; // restriction


where I use >: to mean a super-type and :< a sub-type.

In this case the sub-typing relationship would of course be transitive=20
and implicit when moving from sub-types to super-types and explicit on=20
the other direction, e.g. using some kind of cast, why not static_cast.


BR,

Vicente

--=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/73866d3d-1466-3bca-55d2-3c00c16127a4%40wanadoo.f=
r.

--------------05EC378C03A1B83C10DA678F
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 02/12/2018 =C3=A0 02:49, <a
        class=3D"moz-txt-link-abbreviated"
        href=3D"mailto:philipgins@gmail.com">philipgins@gmail.com</a> a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"
      cite=3D"mid:cffbc45a-406b-444b-a52f-64cedd955cbd@isocpp.org">
      <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF=
-8">
      <div dir=3D"ltr">Hi all,
        <div><br>
        </div>
        <div>I have updated the <a
href=3D"https://github.com/ginsbach/CppProposal/blob/release_70/ExtendedSco=
pedEnumerations.pdf"
            moz-do-not-send=3D"true">proposal</a>=C2=A0to reflect some of y=
our
          feedback:</div>
        <br>
      </div>
    </blockquote>
    <p>I've some trouble with the way you use sub-typing "there is a
      natural correspondence between sub-typing and adding enumerators
      to enums". <br>
    </p>
    <p>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
      <a class=3D"moz-txt-link-freetext"
href=3D"http://www.adaic.org/resources/add_content/standards/05rm/html/RM-3=
-5-1.html">http://www.adaic.org/resources/add_content/standards/05rm/html/R=
M-3-5-1.html</a>).
      Have you considered this possibility? Are you sure that the common
      case is to extend enumerators, or to restrict them. Maybe both are
      useful.<br>
    </p>
    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.
    <p>With scoped enums you have that the underlying type is seen as a
      representation type, not as a super-type. <br>
    </p>
    <p>So we have that : is used either to separate the super-type for
      class, either to separate the underlying type for scoped enums or
      either to separate the sub-type for your proposal. I don't know if
      this is good.<br>
    </p>
    <p>In the rational for non-having multiple extensions when you say
      that "fail if any of their enumerators have the same value", I
      don't see why this should fail. I agree that having the same
      enumerator name would introduce some problems, if you want strict
      extensions.<br>
    </p>
    <p><br>
    </p>
    <p>Next follows some alternatives solution to the problem you are
      trying to solve. Please, let me if you have considered some of
      them.<br>
    </p>
    <p><br>
    </p>
    <p><b>Current solution using C++2a</b><br>
    </p>
    <p>The example using the current standard is not fair as you can now
      define <br>
    </p>
    <p>=C2=A0=C2=A0=C2=A0 enum class TokenType : int { constant =3D 211, bi=
nary_op =3D 223
      };<br>
    </p>
    <p>=C2=A0=C2=A0=C2=A0 enum class SyntaxType : int { constant =3D TokenT=
ype::constant,
      binary_op =3D TokenType::binary_op, binary_expr};</p>
    <p>and adding a conversion function<br>
    </p>
    <p>=C2=A0=C2=A0=C2=A0 SyntaxType to_SyntaxType (TokenType);</p>
    <p>So the single additional difference between your proposal and the
      current solution would be to call explicitly this conversion</p>
    <p>=C2=A0=C2=A0=C2=A0 stack.push_back({toke.type, {}, toke.value}) </p>
    <p>versus<br>
    </p>
    <p>=C2=A0=C2=A0=C2=A0 stack.push_back({<b>to_SyntaxType</b>(toke.type),=
 {},
      toke.value}) </p>
    <p><br>
    </p>
    <p>This has the drawback however that the relation is not
      transitive, and we would need to define more conversion functions.
      <br>
    </p>
    <p><br>
    </p>
    <p><b>Alternative</b><br>
    </p>
    <p>Next follows an alternative based on the possibility to define
      "implicit constructors/conversions on an enum class" (this feature
      doesn't exists evidently). <br>
    </p>
    <p>This could allow to define enum "super-typing" and "sub-typing"
      at the same time, but has the drawback that conversions are not
      transitive :(<br>
    </p>
    <p>The result is cumbersome, I admit, but I like the ability to
      define any kind of super-typing, sub-typing.</p>
    <p><br>
    </p>
    <p>Your Token example could be defined as follows:<br>
    </p>
    <p>enum class SyntaxType : int { constant =3D TokenType::constant,
      binary_op =3D TokenType::binary_op, binary_expr} <br>
    </p>
    <p><b>{ // here we start to be able to define operations on a enum</b><=
/p>
    <b> </b>
    <p>=C2=A0=C2=A0=C2=A0 SyntaxType(TokenType e) {</p>
    <p>=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 underlying(*this) =3D underlyi=
ng(e); <b>// extension to
        refer to the representation of an enum</b></p>
    <p>=C2=A0=C2=A0=C2=A0 }<br>
    </p>
    <p>=C2=A0=C2=A0=C2=A0 explicit operator TokenType() { <br>
    </p>
    <p>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [[expects :
      is_enumerator_value&lt;TokenType&gt;(underlying(*this)) ]] <b>//
        is_enumerator_value states if a underlying value is the value of
        one of the enumerators of the enum type</b><br>
    </p>
    <p>=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 return TokenType(underlying(*t=
his));<br>
    </p>
    };
    <p><br>
    </p>
    <p>Next follows the typical sub-type example for Day and WeekDay.<br>
    </p>
    <p>enum class Day : int { Mon,=C2=A0Tue,=C2=A0Wed,=C2=A0Thu,=C2=A0Fri,=
=C2=A0Sat,=C2=A0Sun };</p>
    <p>enum class Weekday : int { Mon,=C2=A0Tue,=C2=A0Wed,=C2=A0Thu,=C2=A0F=
ri } <br>
    </p>
    <p>{</p>
    <p>=C2=A0=C2=A0=C2=A0 explicit Weekday(Day e) {</p>
    <p>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [[expects :
      is_enumerator_value&lt;Weekday&gt;(underlying(e)) ]]</p>
    <p>=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 underlying(*this) =3D underlyi=
ng(e);</p>
    <p>=C2=A0=C2=A0=C2=A0 }</p>
    <p>=C2=A0=C2=A0=C2=A0 implicit operator Day() { <br>
    </p>
    <p>=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 return Day(underlying(*this));=
</p>
    <p>=C2=A0=C2=A0=C2=A0 }<br>
    </p>
    <p>};</p>
    <p><b>Ideal</b><br>
    </p>
    <p>IMHO, iIdeally we should be able to define the super-type,
      sub-type with some kind of syntactic sugar as</p>
    <p>enum class SyntaxType <b>&gt;:</b> TokenType { binary_expr }; //
      extension<br>
    </p>
    enum class Weekday <b>:&lt;</b>=C2=A0 Day=C2=A0 { Mon ... Fri }; //
    restriction<br>
    <p><br>
    </p>
    <p>where I use &gt;: to mean a super-type and :&lt; a sub-type.<br>
    </p>
    <p>In this case the sub-typing relationship would of course be
      transitive and implicit when moving from sub-types to super-types
      and explicit on the other direction, e.g. using some kind of cast,
      why not static_cast.<br>
    </p>
    <p><br>
    </p>
    <p>BR,</p>
    <p>Vicente<br>
    </p>
  </body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/73866d3d-1466-3bca-55d2-3c00c16127a4%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/73866d3d-1466-3bca-55d2-3c00c16127a4=
%40wanadoo.fr</a>.<br />

--------------05EC378C03A1B83C10DA678F--

.

------=_Part_3971_387967718.1543761479368
Content-Type: multipart/alternative;
 boundary="----=_Part_3972_1043122808.1543761479368"

------=_Part_3972_1043122808.1543761479368
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sunday, December 2, 2018 at 11:47:40 AM UTC-2, Vicente J. Botet Escriba=
=20
wrote:
>
> Le 02/12/2018 =C3=A0 02:49, phili...@gmail.com <javascript:> a =C3=A9crit=
 :
>
> Hi all,=20
>
> I have updated the proposal=20
> <https://github.com/ginsbach/CppProposal/blob/release_70/ExtendedScopedEn=
umerations.pdf> 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.
>
=20
It is expected that code which can work with T& can also work with S&=20
(where S is a sub-type of T). This is sometimes referred to as the Liskov=
=20
substitution principle.

If sub-typing an enumeration allows the programmer to add new values,=20
suddenly some S& cannot be used as T& anymore, because they do not have=20
corresponding values in T.

Even though I expected that extending an enumeration would only allow one=
=20
to add to it (much like you cannot subtract members from a parent class), I=
=20
think this causes some issues after reading Vicente's post.

--=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/dd054ccd-9241-4c0b-8040-6093340da91c%40isocpp.or=
g.

------=_Part_3972_1043122808.1543761479368
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, December 2, 2018 at 11:47:40 AM UTC-2, Vicente =
J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div>Le 02/12/2018 =C3=A0 02:49, <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"zJYTvNQjAwAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">phili...@gmail.com</a> a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
     =20
      <div dir=3D"ltr">Hi all,
        <div><br>
        </div>
        <div>I have updated the <a href=3D"https://github.com/ginsbach/CppP=
roposal/blob/release_70/ExtendedScopedEnumerations.pdf" target=3D"_blank" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?=
q\x3dhttps%3A%2F%2Fgithub.com%2Fginsbach%2FCppProposal%2Fblob%2Frelease_70%=
2FExtendedScopedEnumerations.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE_=
f5CeZNAHeg_IuZwkV18F1aX8YA&#39;;return true;" onclick=3D"this.href=3D&#39;h=
ttps://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fginsbach%2FCppPro=
posal%2Fblob%2Frelease_70%2FExtendedScopedEnumerations.pdf\x26sa\x3dD\x26sn=
tz\x3d1\x26usg\x3dAFQjCNE_f5CeZNAHeg_IuZwkV18F1aX8YA&#39;;return true;">pro=
posal</a>=C2=A0to reflect some of your
          feedback:</div>
        <br>
      </div>
    </blockquote>
    <p>I&#39;ve some trouble with the way you use sub-typing &quot;there is=
 a
      natural correspondence between sub-typing and adding enumerators
      to enums&quot;. <br>
    </p>
    <p>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
      <a href=3D"http://www.adaic.org/resources/add_content/standards/05rm/=
html/RM-3-5-1.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.=
href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.adaic.org%2Fres=
ources%2Fadd_content%2Fstandards%2F05rm%2Fhtml%2FRM-3-5-1.html\x26sa\x3dD\x=
26sntz\x3d1\x26usg\x3dAFQjCNGXgIm3DKkm2_D1VAgEQTCE7jjjzg&#39;;return true;"=
 onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fww=
w.adaic.org%2Fresources%2Fadd_content%2Fstandards%2F05rm%2Fhtml%2FRM-3-5-1.=
html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGXgIm3DKkm2_D1VAgEQTCE7jjjzg&#=
39;;return true;">http://www.adaic.org/<wbr>resources/add_content/<wbr>stan=
dards/05rm/html/RM-3-5-1.<wbr>html</a>).
      Have you considered this possibility? Are you sure that the common
      case is to extend enumerators, or to restrict them. Maybe both are
      useful.</p></div></blockquote><div>=C2=A0</div><div>It is expected th=
at code which can work with T&amp; can also work with S&amp; (where S is a =
sub-type of T). This is sometimes referred to as the Liskov substitution pr=
inciple.<br><br>If sub-typing an enumeration allows the programmer to add n=
ew values, suddenly some S&amp; cannot be used as T&amp; anymore, because t=
hey do not have corresponding values in T.</div><div><br></div><div>Even th=
ough I expected that extending an enumeration would only allow one to add t=
o it (much like you cannot subtract members from a parent class), I think t=
his causes some issues after reading Vicente&#39;s post.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/dd054ccd-9241-4c0b-8040-6093340da91c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dd054ccd-9241-4c0b-8040-6093340da91c=
%40isocpp.org</a>.<br />

------=_Part_3972_1043122808.1543761479368--

------=_Part_3971_387967718.1543761479368--

.

------=_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 <javascript:> a =C3=A9crit=
 :
>
> Hi all,=20
>
> I have updated the proposal=20
> <https://github.com/ginsbach/CppProposal/blob/release_70/ExtendedScopedEn=
umerations.pdf> 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

<div dir=3D"ltr"><br><br>On Sunday, December 2, 2018 at 7:47:40 AM UTC-6, V=
icente J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div>Le 02/12/2018 =C3=A0 02:49, <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"zJYTvNQjAwAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">phili...@gmail.com</a> a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
     =20
      <div dir=3D"ltr">Hi all,
        <div><br>
        </div>
        <div>I have updated the <a href=3D"https://github.com/ginsbach/CppP=
roposal/blob/release_70/ExtendedScopedEnumerations.pdf" target=3D"_blank" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?=
q\x3dhttps%3A%2F%2Fgithub.com%2Fginsbach%2FCppProposal%2Fblob%2Frelease_70%=
2FExtendedScopedEnumerations.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE_=
f5CeZNAHeg_IuZwkV18F1aX8YA&#39;;return true;" onclick=3D"this.href=3D&#39;h=
ttps://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fginsbach%2FCppPro=
posal%2Fblob%2Frelease_70%2FExtendedScopedEnumerations.pdf\x26sa\x3dD\x26sn=
tz\x3d1\x26usg\x3dAFQjCNE_f5CeZNAHeg_IuZwkV18F1aX8YA&#39;;return true;">pro=
posal</a>=C2=A0to reflect some of your
          feedback:</div>
        <br>
      </div>
    </blockquote>
    <p>I&#39;ve some trouble with the way you use sub-typing &quot;there is=
 a
      natural correspondence between sub-typing and adding enumerators
      to enums&quot;. <br>
    </p>
    <p>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
      <a href=3D"http://www.adaic.org/resources/add_content/standards/05rm/=
html/RM-3-5-1.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.=
href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.adaic.org%2Fres=
ources%2Fadd_content%2Fstandards%2F05rm%2Fhtml%2FRM-3-5-1.html\x26sa\x3dD\x=
26sntz\x3d1\x26usg\x3dAFQjCNGXgIm3DKkm2_D1VAgEQTCE7jjjzg&#39;;return true;"=
 onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fww=
w.adaic.org%2Fresources%2Fadd_content%2Fstandards%2F05rm%2Fhtml%2FRM-3-5-1.=
html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGXgIm3DKkm2_D1VAgEQTCE7jjjzg&#=
39;;return true;">http://www.adaic.org/<wbr>resources/add_content/<wbr>stan=
dards/05rm/html/RM-3-5-1.<wbr>html</a>).
      Have you considered this possibility? Are you sure that the common
      case is to extend enumerators, or to restrict them. Maybe both are
      useful.<br>
    </p>
    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.
    </div></blockquote><div>[snip]=C2=A0</div><div>I agree with Vincente th=
at super-type is the correct term.<br>The reason it seems weird is because =
class inheritance is<br>for product types whereas enum inheritance is for s=
um types<br>(e.g. std::variant):<br><br>=C2=A0 https://en.wikipedia.org/wik=
i/Algebraic_data_type<br><br>and the duality property of category theory:<b=
r><br>=C2=A0 https://en.wikipedia.org/wiki/Dual_(category_theory)<br>=C2=A0=
 <br>says that the arrows are reversed in the dual category.<br>In this par=
ticular case, the arrow is the Liskov <br>substitution principle mentioned =
in Bernardo&#39;s post.<br><br>More formally, let:<br><br>=C2=A0 A &lt;: B<=
br>=C2=A0 <br>mean a type A can be substituted where a type B is expected(<=
br>i.e. the Liskov principle).<br><br>Now if:<br><br>=C2=A0 struct sB{int b=
_1; char b_2;}<br>=C2=A0 struct sA : sB{ bool a_3};<br>=C2=A0 <br>then:<br>=
<br>=C2=A0 sA &lt;: sB<br>=C2=A0 <br>IOW, an instance of sA can substituted=
 anywhere an instance<br>of sB is expected (because sA has all of the field=
s that sB<br>has).<br>=C2=A0 <br>OTOH, if:<br><br>=C2=A0 enum eB{b_1,b_2};<=
br>=C2=A0 enum eA : eB{a_3};<br>=C2=A0 <br>then:<br><br>=C2=A0 eB &lt;: eA<=
br><br>IOW, an instance of eB (e.g. b_2) can be substituted<br>anywhere an =
instance of eA is expected (because b_2 is<br>actually a member of eA as we=
ll as a member of eB).<br><br>OTOH, there&#39;s an interesting corner case:=
<br><br>=C2=A0 enum eB{};<br>=C2=A0 enum eA : eB{a_3};<br>=C2=A0 <br>Now wh=
at happens when:<br><br>=C2=A0 eB b_0;<br>=C2=A0 <br>is used where an eA is=
 expected?<br><br>I don&#39;t know, but I&#39;d guess there would be a core=
 dump or<br>something as unpleasant.<br><br>-regards,<br>Larry<br><br></div=
></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7ab7b56f-e805-4703-a566-d805d08e20e2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7ab7b56f-e805-4703-a566-d805d08e20e2=
%40isocpp.org</a>.<br />

------=_Part_3806_1597953238.1543767953717--

------=_Part_3805_1739465788.1543767953717--

.

This is a multi-part message in MIME format.
--------------61304B4CF3937C71ED912CBA
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 02/12/2018 =C3=A0 17:25, cppljevans@gmail.com a =C3=A9crit=C2=A0:
>
>
> On Sunday, December 2, 2018 at 7:47:40 AM UTC-6, Vicente J. Botet=20
> Escriba wrote:
>
>     Le 02/12/2018 =C3=A0 02:49, phili...@gmail.com <javascript:> a =C3=A9=
crit=C2=A0:
>>     Hi all,
>>
>>     I have updated the proposal
>>     <https://github.com/ginsbach/CppProposal/blob/release_70/ExtendedSco=
pedEnumerations.pdf>=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/standards/05rm/html/RM-3-5=
-1.html
>     <http://www.adaic.org/resources/add_content/standards/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]
> 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):
>
> =C2=A0 https://en.wikipedia.org/wiki/Algebraic_data_type
>
> and the duality property of category theory:
>
> =C2=A0 https://en.wikipedia.org/wiki/Dual_(category_theory)
>
> says that the arrows are reversed in the dual category.

Thanks for the link.

I agree completely with you, and could then accept that : is used to=20
mean super-type with sum-types.

What is unfortunate is that we have used : to designate the underlying=20
type as well.


> In this particular case, the arrow is the Liskov
> substitution principle mentioned in Bernardo's post.
>
> More formally, let:
>
> =C2=A0 A <: B
>
> mean a type A can be substituted where a type B is expected(
> 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};
>
> then:
>
> =C2=A0 sA <: sB
>
> IOW, an instance of sA can substituted anywhere an instance
> of sB is expected (because sA has all of the fields that sB
> has).
>
> OTOH, if:
>
> =C2=A0 enum eB{b_1,b_2};
> =C2=A0 enum eA : eB{a_3};
>
> then:
>
> =C2=A0 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:
>
> =C2=A0 enum eB{};
> =C2=A0 enum eA : eB{a_3};
>
> Now what happens when:
>
> =C2=A0 eB b_0;
>
> is used where an eA is expected?
>
This is the good case, as eB is a sub-type of eA, isn't it?
> I don't know, but I'd guess there would be a core dump or
> something as unpleasant.

Why? What am I missing?

Now, if

 =C2=A0 enum eA : eB{a_3};


means that eA is a super-type of eB, which syntax could be used to state=20
that eC is a sub-type of eB, because it has less sum types (enumerators).

 =C2=A0 enum eC <: eB{...};


Vicente

--=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/b879599b-c8ba-68fd-72ef-813b8c9d42e6%40wanadoo.f=
r.

--------------61304B4CF3937C71ED912CBA
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 02/12/2018 =C3=A0 17:25,
      <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:cppljevans@gmail=
..com">cppljevans@gmail.com</a> a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"
      cite=3D"mid:7ab7b56f-e805-4703-a566-d805d08e20e2@isocpp.org">
      <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF=
-8">
      <div dir=3D"ltr"><br>
        <br>
        On Sunday, December 2, 2018 at 7:47:40 AM UTC-6, Vicente J.
        Botet Escriba wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div text=3D"#000000" bgcolor=3D"#FFFFFF">
            <div>Le 02/12/2018 =C3=A0 02:49, <a href=3D"javascript:"
                target=3D"_blank" gdf-obfuscated-mailto=3D"zJYTvNQjAwAJ"
                rel=3D"nofollow"
                onmousedown=3D"this.href=3D'javascript:';return true;"
                onclick=3D"this.href=3D'javascript:';return true;"
                moz-do-not-send=3D"true">phili...@gmail.com</a> a =C3=A9cri=
t=C2=A0:<br>
            </div>
            <blockquote type=3D"cite">
              <div dir=3D"ltr">Hi all,
                <div><br>
                </div>
                <div>I have updated the <a
href=3D"https://github.com/ginsbach/CppProposal/blob/release_70/ExtendedSco=
pedEnumerations.pdf"
                    target=3D"_blank" rel=3D"nofollow"
onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fg=
ithub.com%2Fginsbach%2FCppProposal%2Fblob%2Frelease_70%2FExtendedScopedEnum=
erations.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE_f5CeZNAHeg_IuZwkV18F=
1aX8YA';return
                    true;"
onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithu=
b.com%2Fginsbach%2FCppProposal%2Fblob%2Frelease_70%2FExtendedScopedEnumerat=
ions.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE_f5CeZNAHeg_IuZwkV18F1aX8=
YA';return
                    true;" moz-do-not-send=3D"true">proposal</a>=C2=A0to
                  reflect some of your feedback:</div>
                <br>
              </div>
            </blockquote>
            <p>I've some trouble with the way you use sub-typing "there
              is a natural correspondence between sub-typing and adding
              enumerators to enums". <br>
            </p>
            <p>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 <a
href=3D"http://www.adaic.org/resources/add_content/standards/05rm/html/RM-3=
-5-1.html"
                target=3D"_blank" rel=3D"nofollow"
onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww=
..adaic.org%2Fresources%2Fadd_content%2Fstandards%2F05rm%2Fhtml%2FRM-3-5-1.h=
tml\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGXgIm3DKkm2_D1VAgEQTCE7jjjzg';r=
eturn
                true;"
onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.ada=
ic.org%2Fresources%2Fadd_content%2Fstandards%2F05rm%2Fhtml%2FRM-3-5-1.html\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGXgIm3DKkm2_D1VAgEQTCE7jjjzg';retur=
n
                true;" moz-do-not-send=3D"true">http://www.adaic.org/<wbr>r=
esources/add_content/<wbr>standards/05rm/html/RM-3-5-1.<wbr>html</a>).
              Have you considered this possibility? Are you sure that
              the common case is to extend enumerators, or to restrict
              them. Maybe both are useful.<br>
            </p>
            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. </div>
        </blockquote>
        <div>[snip]=C2=A0</div>
        <div>I agree with Vincente that super-type is the correct term.<br>
          The reason it seems weird is because class inheritance is<br>
          for product types whereas enum inheritance is for sum types<br>
          (e.g. std::variant):<br>
          <br>
          =C2=A0 <a class=3D"moz-txt-link-freetext" href=3D"https://en.wiki=
pedia.org/wiki/Algebraic_data_type">https://en.wikipedia.org/wiki/Algebraic=
_data_type</a><br>
          <br>
          and the duality property of category theory:<br>
          <br>
          =C2=A0 <a class=3D"moz-txt-link-freetext" href=3D"https://en.wiki=
pedia.org/wiki/Dual_(category_theory)">https://en.wikipedia.org/wiki/Dual_(=
category_theory)</a><br>
          =C2=A0 <br>
          says that the arrows are reversed in the dual category.<br>
        </div>
      </div>
    </blockquote>
    <p>Thanks for the link. <br>
    </p>
    <p>I agree completely with you, and could then accept that : is used
      to mean super-type with sum-types.</p>
    <p>What is unfortunate is that we have used : to designate the
      underlying type as well.</p>
    <p><br>
    </p>
    <blockquote type=3D"cite"
      cite=3D"mid:7ab7b56f-e805-4703-a566-d805d08e20e2@isocpp.org">
      <div dir=3D"ltr">
        <div>In this particular case, the arrow is the Liskov <br>
          substitution principle mentioned in Bernardo's post.<br>
          <br>
          More formally, let:<br>
          <br>
          =C2=A0 A &lt;: B<br>
          =C2=A0 <br>
          mean a type A can be substituted where a type B is expected(<br>
          i.e. the Liskov principle).<br>
          <br>
          Now if:<br>
          <br>
          =C2=A0 struct sB{int b_1; char b_2;}<br>
          =C2=A0 struct sA : sB{ bool a_3};<br>
          =C2=A0 <br>
          then:<br>
          <br>
          =C2=A0 sA &lt;: sB<br>
          =C2=A0 <br>
          IOW, an instance of sA can substituted anywhere an instance<br>
          of sB is expected (because sA has all of the fields that sB<br>
          has).<br>
          =C2=A0 <br>
          OTOH, if:<br>
          <br>
          =C2=A0 enum eB{b_1,b_2};<br>
          =C2=A0 enum eA : eB{a_3};<br>
          =C2=A0 <br>
          then:<br>
          <br>
          =C2=A0 eB &lt;: eA<br>
          <br>
          IOW, an instance of eB (e.g. b_2) can be substituted<br>
          anywhere an instance of eA is expected (because b_2 is<br>
          actually a member of eA as well as a member of eB).<br>
          <br>
          OTOH, there's an interesting corner case:<br>
          <br>
          =C2=A0 enum eB{};<br>
          =C2=A0 enum eA : eB{a_3};<br>
          =C2=A0 <br>
          Now what happens when:<br>
          <br>
          =C2=A0 eB b_0;<br>
          =C2=A0 <br>
          is used where an eA is expected?<br>
          <br>
        </div>
      </div>
    </blockquote>
    This is the good case, as eB is a sub-type of eA, isn't it?
    <blockquote type=3D"cite"
      cite=3D"mid:7ab7b56f-e805-4703-a566-d805d08e20e2@isocpp.org">
      <div dir=3D"ltr">
        <div>I don't know, but I'd guess there would be a core dump or<br>
          something as unpleasant.<br>
        </div>
      </div>
    </blockquote>
    <p>Why? What am I missing?</p>
    <p>Now, if <br>
    </p>
    <p>=C2=A0 enum eA : eB{a_3};</p>
    <p><br>
    </p>
    <p>means that eA is a super-type of eB, which syntax could be used
      to state that eC is a sub-type of eB, because it has less sum
      types (enumerators). <br>
    </p>
    <p>=C2=A0 enum eC &lt;: eB{...};</p>
    <p><br>
    </p>
    <p>Vicente<br>
    </p>
  </body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b879599b-c8ba-68fd-72ef-813b8c9d42e6%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b879599b-c8ba-68fd-72ef-813b8c9d42e6=
%40wanadoo.fr</a>.<br />

--------------61304B4CF3937C71ED912CBA--

.

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

<div dir=3D"ltr"><div>=C2=A0Hi Bernardo,</div><div><br></div><div>The Lisko=
v substitution principle still holds, a TokenType&amp; can be used as a Syn=
taxType&amp;.</div><div>Larry pointed to a paper earlier and put this into =
a better type theory context than I could in my own words.</div><div><br></=
div><div><br></div><div>Hi Vincente,</div><div><br></div><div>Thanks you fo=
r the thorough comments, I&#39;ll try to address them one by one.</div><div=
><br></div><div>extension vs restriction:</div><div>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.</div><div><br></div><div>syntax confusing:</div><div>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.</div><div>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.</div><div>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.</div><div>I quite like the &quot;&gt;:&quot; syntax for extension=
s, however I expect that this has bigger chances to getting admitted to the=
 standard without new syntax.</div><div><br></div><div>multiple extensions:=
</div><div>I agree it&#39;s not obviously a bad idea to allow it, but it se=
emed like it would result in unexpected behaviour too often.</div><div>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.</div><div>When thinking about it f=
rom the angle of modularity it&#39;s not so clear to me that this is useful=
 enough to warrant the problems.</div><div><br></div><div>conversion functi=
on:</div><div>This doesn&#39;t solve the problem, although it does contain =
it. The implementation of the conversion function still has the exact same =
issue.</div><div>If it is based on the underlying integer value then it wil=
l silently fail when the two enums go &quot;out of sync&quot;. The only rea=
son for scoped enums to exist is type safety and that would be thrown out o=
f the window there.</div><div>This is also the case with your next example =
that explicitly uses the underlying type.</div><div><br></div><div>Best,</d=
iv><div>Philip</div><div>=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a359f82b-1a89-4dae-8b6e-169a57065f4e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a359f82b-1a89-4dae-8b6e-169a57065f4e=
%40isocpp.org</a>.<br />

------=_Part_3830_764046016.1543771047910--

------=_Part_3829_2144669994.1543771047910--

.

------=_Part_3773_1551674208.1543772054129
Content-Type: multipart/alternative;
 boundary="----=_Part_3774_907893369.1543772054129"

------=_Part_3774_907893369.1543772054129
Content-Type: text/plain; charset="UTF-8"


>
>
>

Hi Larry,

As for the core dump there shouldn't be a need to worry, at runtime these
are all integers.

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/639834c0-4fee-4a16-b31b-2347c9e4d189%40isocpp.org.

------=_Part_3774_907893369.1543772054129
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>=C2=A0</div></div></blockquote><div>=C2=A0</div><div>Hi Larry,</di=
v><div><br></div><div>As for the core dump there shouldn&#39;t be a need to=
 worry, at runtime these are all integers.</div><div><br></div><div>Best,<b=
r>Philip=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/639834c0-4fee-4a16-b31b-2347c9e4d189%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/639834c0-4fee-4a16-b31b-2347c9e4d189=
%40isocpp.org</a>.<br />

------=_Part_3774_907893369.1543772054129--

------=_Part_3773_1551674208.1543772054129--

.

Le 02/12/2018 =C3=A0 18:17, philipgins@gmail.com a =C3=A9crit=C2=A0:
> =C2=A0Hi Bernardo,
>
> The Liskov substitution principle still holds, a TokenType& can be=20
> used as a SyntaxType&.
> Larry pointed to a paper earlier and put this into a better type=20
> 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=20
> mind: I can extend without knowing the internals of the base=20
> enumerator but I cannot restrict without knowing the internals of the=20
> larger enum. Thus extension can serve for modularity, whereas=20
> restriction do not and can already be implemented by e.g. predicate=20
> functions.
Well, predicate functions don't define types, so no, is not a solution.=20
Except if the Predicate is part of the type, of course.
>
> syntax confusing:
> The same syntax is used to spell out the integral type or to specfy a=20
> base enumeration although those are two entirely different things, you=20
> rightly point this out as a bit confusing.
> Furthermore, the syntax is similar to class inheritance but produces=20
> the inverse result: a value of the base enum is _more_ constrained, as=20
> it can take on _less_ values.
> I had a more verbose syntax in mind before, but was strongly advised=20
> to not introduce new keywords or otherwise fancy syntax. I think this=20
> is a reasonable compromise.
> I quite like the ">:" syntax for extensions, however I expect that=20
> this has bigger chances to getting admitted to the standard without=20
> new syntax.
I believe the paper could talk about both cases extension and=20
restrictions of enums, and suggest the need for both mechanism. If the=20
EWG is for both mechanisms, then we would need good syntax for both. If=20
EWG is only for extension, or for restrictions, then the syntax problem=20
would be reduced.
>
> multiple extensions:
> I agree it's not obviously a bad idea to allow it, but it seemed like=20
> it would result in unexpected behaviour too often.
> I think this goes a bit towards the first point: When thinking about=20
> restrictions (that would be well served with just a boolean predicate=20
> function) it seems obvious that this should be allowed.
> When thinking about it from the angle of modularity it's not so clear=20
> to me that this is useful enough to warrant the problems.
I just wanted to signal, that having an additional enumerator with an=20
existing value couldn't introduce any issue, and so couldn't introduce=20
it with multiple extensions.
>
> conversion function:
> This doesn't solve the problem, although it does contain it. The=20
> implementation of the conversion function still has the exact same issue.
Which issue are you referring to? it is what follows?
> If it is based on the underlying integer value then it will silently=20
> fail when the two enums go "out of sync".
Could you be more precise?
> The only reason for scoped enums to exist is type safety and that=20
> would be thrown out of the window there.
Why?
> This is also the case with your next example that explicitly uses the=20
> underlying type.
>
Again, could you be more explicit?

I introduced the conversion function as in your example your doing some=20
kind of conversion, but with bad code that doesn't respect DRY and so=20
the example using C++2a seems even worst. Are you talking of the=20
alternative with the constructor/conversion operators between enums?

Vicente


--=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/fbb4f455-7248-7be2-ca1f-e9254c74e916%40wanadoo.f=
r.

.

------=_Part_3916_1905119416.1543778194459
Content-Type: multipart/alternative;
 boundary="----=_Part_3917_372699993.1543778194460"

------=_Part_3917_372699993.1543778194460
Content-Type: text/plain; charset="UTF-8"

Hi Vicente,

*predicte functions no solution:*
Predicate functions are not a solution that's directly embedded in the type
system but it is a reasonable solution that is safe.
It might be a good idea to embed predicate functions of enums in the type
system but that's a different topic.
Extensions do not have a reasonable solution that is type safe.

*restrictions and extensions:*
I think the two are fundamentally serving different purposes and I would
not see the need to introduce them in the same proposal.
However, if there is a general consensus on that I'm willing to change my
mind.

*enumerators sharing values:*
Having two enumerators with the same value contradicts the fundamental
contract of what an enum is.

enum class Workday : int {Mon, Tue, Wed, Thu, Fri }; // Mon = 0 implicit
enum class Weekend : int {Sat, Sun}; // Sat = 0 implicit
enum class Day : Workday, Weekend { };

Day day = Weekday::Mon;
if(day == Weekend::Sat)
std::cout<<"wtf";

*problem with conversion function in C++2a:*
Let's take your weekday example.

enum class Workday { Mon, Tue, Wed, Thu, Fri };
enum class Day { Mon=Workday::Mon, Tue=Workday::Tue, Wed=Workday::Wed,
Thu=Workday::Thu, Fri=Workday::Fri, Sat, Sun };

The proper type safe way to implement the conversion is as follows.
I assume that nobody would do that though.

Day convert1(Workday w)
{ switch(w) {
  case Workday::Mon: return Day::Mon;
  case Workday::Tue: return Day::Tue;
  case Workday::Wed: return Day::Wed;
  case Workday::Thu: return Day::Thu;
  case Workday::Fri: return Day::Fri;
  }
}

Otherwise we can just discard the type information and work with the
underlying integers (this is what you propose I think).

Day convert2(Weekday w)
{ return (Day)w; }

Somebody could decide that Saturday is a work day now and modify the
Workday enum.

enum class Workday { Sat, Mon, Tue, Wed, Thu, Fri };

Everything is broken now with convert2 and there is no warning at all.
On the other hand, convert1 would give a warning, so that's fine.
However, after updating convert1, it could no longer be optimized away by
the compiler and would remain an expensive runtime operation!

*alternative to C++2a:*
What happens in this case?

enum class Day : int { Sat, Sun, Mon, Tue, Wed, Thu, Fri };
enum class Weekday : int { Mon, Tue, Wed, Thu, Fri }
{

    explicit Weekday(Day e) {

        [[expects : is_enumerator_value<Weekday>(underlying(e)) ]]

        underlying(*this) = underlying(e);

    }

    implicit operator Day() {
        return Day(underlying(*this));

    }
};

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/fcc1eafe-47fb-4cbb-9697-4a646c3e48c8%40isocpp.org.

------=_Part_3917_372699993.1543778194460
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Vicente,</div><div><br></div><div><b>predicte func=
tions no solution:</b></div><div>Predicate functions are not a solution tha=
t&#39;s directly embedded in the type system but it is a reasonable solutio=
n that is safe.</div><div>It might be a good idea to embed predicate functi=
ons of enums in the type system but that&#39;s a different topic.</div><div=
>Extensions do not have a reasonable solution that is type safe.</div><div>=
<br></div><div><b>restrictions and extensions:</b></div><div>I think the tw=
o are fundamentally serving different purposes and I would not see the need=
 to introduce them in the same proposal.</div><div>However, if there is a g=
eneral consensus on that I&#39;m willing to change my mind.</div><div><br><=
/div><div><b>enumerators sharing values:</b></div><div>Having two enumerato=
rs with the same value contradicts the fundamental contract of what an enum=
 is.</div><div><br></div><div>enum class Workday : int {Mon, Tue, Wed, Thu,=
 Fri }; // Mon =3D 0 implicit</div><div>enum class Weekend : int {Sat, Sun}=
; // Sat =3D 0 implicit</div><div>enum class Day : Workday, Weekend { };</d=
iv><div><br></div><div>Day day =3D Weekday::Mon;</div><div>if(day =3D=3D We=
ekend::Sat)</div><div><span style=3D"white-space:pre"> </span>std::cout&lt;=
&lt;&quot;wtf&quot;;</div><div><br></div><div><b>problem with conversion fu=
nction in C++2a:</b></div><div>Let&#39;s take your weekday example.</div><d=
iv><br></div><div>enum class Workday { Mon, Tue, Wed, Thu, Fri };</div><div=
>enum class Day { Mon=3DWorkday::Mon, Tue=3DWorkday::Tue, Wed=3DWorkday::We=
d, Thu=3DWorkday::Thu, Fri=3DWorkday::Fri, Sat, Sun };</div><div><br></div>=
<div>The proper type safe way to implement the conversion is as follows.</d=
iv><div>I assume that nobody would do that though.</div><div><br></div><div=
>Day convert1(Workday w)</div><div>{ switch(w) {</div><div>=C2=A0 case Work=
day::Mon: return Day::Mon;</div><div>=C2=A0 case Workday::Tue: return Day::=
Tue;</div><div>=C2=A0 case Workday::Wed: return Day::Wed;</div><div>=C2=A0 =
case Workday::Thu: return Day::Thu;</div><div>=C2=A0 case Workday::Fri: ret=
urn Day::Fri;</div><div>=C2=A0 }</div><div>}</div><div><br></div><div>Other=
wise we can just discard the type information and work with the underlying =
integers (this is what you propose I think).</div><div><br></div><div>Day c=
onvert2(Weekday w)</div><div>{ return (Day)w; }</div><div><br></div><div>So=
mebody could decide that Saturday is a work day now and modify the Workday =
enum.</div><div><br></div><div>enum class Workday { Sat, Mon, Tue, Wed, Thu=
, Fri };</div><div><br></div><div>Everything is broken now with convert2 an=
d there is no warning at all.</div><div>On the other hand, convert1 would g=
ive a warning, so that&#39;s fine.</div><div>However, after updating conver=
t1, it could no longer be optimized away by the compiler and would remain a=
n expensive runtime operation!</div><div><br></div><div><b>alternative to C=
++2a:</b></div><div>What happens in this case?</div><div><br></div><div>enu=
m class Day : int { Sat, Sun, Mon, Tue, Wed, Thu, Fri };</div><div>enum cla=
ss Weekday : int { Mon, Tue, Wed, Thu, Fri }=C2=A0</div><div>{</div><div><b=
r></div><div>=C2=A0 =C2=A0 explicit Weekday(Day e) {</div><div><br></div><d=
iv>=C2=A0 =C2=A0 =C2=A0 =C2=A0 [[expects : is_enumerator_value&lt;Weekday&g=
t;(underlying(e)) ]]</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 u=
nderlying(*this) =3D underlying(e);</div><div><br></div><div>=C2=A0 =C2=A0 =
}</div><div><br></div><div>=C2=A0 =C2=A0 implicit operator Day() {=C2=A0</d=
iv><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return Day(underlying(*this));</div><di=
v><br></div><div>=C2=A0 =C2=A0 }</div><div>};</div><div><br></div><div>Phil=
ip</div><div>=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fcc1eafe-47fb-4cbb-9697-4a646c3e48c8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fcc1eafe-47fb-4cbb-9697-4a646c3e48c8=
%40isocpp.org</a>.<br />

------=_Part_3917_372699993.1543778194460--

------=_Part_3916_1905119416.1543778194459--

.

--0000000000003f51ac057c0fa94d
Content-Type: text/plain; charset="UTF-8"

I do not follow every item put forth in this conversation completely.

My two cents (worth nothing) is:

What is the underlying purpose of an enum?

My answer: there seems to be two different purposes!
The enum object came out of the need to provide a simple way for code users
to
communicate which options are being used when a function is called.
This arose because before enums you had to remember and use the correct code
to specify the option value. Codes changed, as functions were expanded and
modified.

There were two different uses:
1) the simple code, where the user specified a value (usually an integer)
that represented
   the option being selected.
2) an exact value like 2048. or 4096, etc.. The specified value was
actually used.
   This was more difficult because not all values were valid. So an easy
way to
   provide this value was by using constants or a list of constants.

By using numbers simple code and the constants added additional attributes
to the
object, namely the numerical ordering and the arithmetic operations.
Programmers took advantage of these additional attributes (being numbers).

Along comes object oriented programming, with homeomorphism, multiple
inheritance. and
operator overloading.

In an effort to handle the problems that enums proposed in this new
environment, again
the two use cases were lumped into one implementation, where the
referencing of
the enum value required to state the enum type (or class) value with each
reference.

Going back to the original case situation, there are really two different
objects being
involved.   The simple code value does not in itself require the additional
attributes
that are associated with numbers.  The name/value case of constants may or
may
not require numeric attributes.

The two uses can and should be separated, for good design requirements.  It
has been
my experience that using one thing for two purposes usually leads to
conflicts, as
is the case with enums.

The simple code case does not require a numeric value. It only requires a
unique identifier.
The only attributes needed in the code environment is equal and unequal,
valid or not valid.

The name/value case may or may not need a numerical ordering, and numeric
operations.

In the case of the simple code, any value for the code can be set, as long
as it is not equal
to any other enum value (i.e. unique within all possible enum code values
within the environment.)
The exact value for each enum value can be determined at execution time.
Many enum lists
can use the same enum value without concern of its use by another function.
It has only
one meaning.

The case of name/value enums is different. In this situation the actual
value is very important.
can be used for calculation purposes. Its value is dependent on the local
scope in which it
is used. In this situation the naming of the scope is required.

As far as return types.  The scoped enum definition should return the name
of the scope
as the type value.  For code enums the ENUM type should be returned.

By using the different type values the two cases are identified as
different. If an enum
value is used without the scope type, it should be assumed to be of type
"ENUM", then
if a function requires a specific type of enum, it can detect that the
wrong type of enum
is being used. The reverse is also true.

These are just some worthless thoughts about the ENUM subject. They cost
nothing
and have that value







On Sat, Dec 1, 2018 at 7:44 AM <philipgins@gmail.com> wrote:

> Hi Bengt,
>
> That's an interesting detail to fill in, thanks. I will add something
> about that to the pdf as well. I think it should absolutely be the integer
> and not the base enum, just as you suggest.
>
> 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/9e3bba78-04c2-42d5-b522-2712932c1659%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9e3bba78-04c2-42d5-b522-2712932c1659%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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/CA%2BAqvO1Tdn-2NyEUBVMVJnuQw%2Bfsxym0gKVv1F5Q3sq3h5rLGw%40mail.gmail.com.

--0000000000003f51ac057c0fa94d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I do not follow every item put forth in this conversation =
completely.<div><br></div><div>My two cents (worth nothing) is:</div><div><=
br></div><div>What is the underlying purpose of an enum?</div><div><br></di=
v><div>My answer: there seems to be two different purposes!</div><div>The e=
num object came out of the need to provide a simple way for code users to</=
div><div>communicate which options are being used when a function is called=
..=C2=A0</div><div>This arose because before enums you had to remember and u=
se the correct code</div><div>to specify the option value. Codes changed, a=
s functions were expanded and modified.</div><div><br></div><div>There were=
 two different uses:</div><div>1) the simple code, where the user specified=
 a value (usually an integer) that represented</div><div>=C2=A0 =C2=A0the o=
ption being selected.=C2=A0=C2=A0</div><div>2) an exact value like 2048. or=
 4096, etc.. The specified value was actually used.</div><div>=C2=A0 =C2=A0=
This was more difficult because not all values were valid. So an easy way t=
o=C2=A0</div><div>=C2=A0 =C2=A0provide this value was by using constants or=
 a list of constants.=C2=A0=C2=A0</div><div><br></div><div>By using numbers=
 simple code and the constants added additional attributes to the=C2=A0</di=
v><div>object, namely the numerical ordering and the arithmetic operations.=
=C2=A0</div><div>Programmers took advantage of these additional attributes =
(being numbers).</div><div><br></div><div>Along comes object oriented progr=
amming, with homeomorphism, multiple inheritance. and</div><div>operator ov=
erloading.=C2=A0=C2=A0</div><div><br></div><div>In an effort to handle the =
problems that enums proposed in this new environment, again=C2=A0</div><div=
>the two use cases were lumped into one implementation, where the referenci=
ng of</div><div>the enum value required to state the enum type (or class) v=
alue with each reference.=C2=A0</div><div><br></div><div>Going back to the =
original case situation, there are really two different objects being</div>=
<div>involved.=C2=A0 =C2=A0The simple code value does not in itself require=
 the additional attributes</div><div>that are associated with numbers.=C2=
=A0 The name/value case of constants may or may=C2=A0</div><div>not require=
 numeric attributes.=C2=A0</div><div><br></div><div>The two uses can and sh=
ould be separated, for good design requirements.=C2=A0 It has been</div><di=
v>my experience that using one thing for two purposes usually leads to conf=
licts, as</div><div>is the case with enums.=C2=A0</div><div><br></div><div>=
The simple code case does not require a numeric value. It only requires a u=
nique identifier.</div><div>The only attributes needed in the code environm=
ent is equal and unequal, valid or not valid.</div><div><br></div><div>The =
name/value case may or may not need a numerical ordering, and numeric opera=
tions.</div><div><br></div><div>In the case of the simple code, any value f=
or the code can be set, as long as it is not equal</div><div>to any other e=
num value (i.e. unique within all possible enum code values within the envi=
ronment.)</div><div>The exact value for each enum value can be determined a=
t execution time. Many enum lists</div><div>can use the same enum value wit=
hout concern of its use by another function. It has only</div><div>one mean=
ing.=C2=A0=C2=A0</div><div><br></div><div>The case of name/value enums is d=
ifferent. In this situation the actual value is very important.</div><div>c=
an be used for calculation purposes. Its value is dependent on the local sc=
ope in which it</div><div>is used. In this situation the naming of the scop=
e is required.=C2=A0</div><div><br></div><div>As far as return types.=C2=A0=
 The scoped enum definition should return the name of the scope</div><div>a=
s the type value.=C2=A0 For code enums the ENUM type should be returned.=C2=
=A0</div><div><br></div><div>By using the different type values the two cas=
es are identified as different. If an enum</div><div>value is used without =
the scope type, it should be assumed to be of type &quot;ENUM&quot;, then</=
div><div>if a function requires a specific type of enum, it can detect that=
 the wrong type of enum</div><div>is being used. The reverse is also true.=
=C2=A0</div><div><br></div><div>These are just some worthless thoughts abou=
t the ENUM subject. They cost nothing</div><div>and have that value</div><d=
iv><br></div><div>=C2=A0</div><div><br></div><div><br></div><div>=C2=A0<br>=
</div><div><div><br></div></div></div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr">On Sat, Dec 1, 2018 at 7:44 AM &lt;<a href=3D"mailto:philipgins@=
gmail.com" target=3D"_blank">philipgins@gmail.com</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi Bengt,<div><br></div><div=
>That&#39;s an interesting detail to fill in, thanks. I will add something =
about that to the pdf as well. I think it should absolutely be the integer =
and not the base enum, just as you suggest.</div><div><br></div><div>Best,<=
br>Philip</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9e3bba78-04c2-42d5-b522-2712932c1659%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9e3bba78-04c2-=
42d5-b522-2712932c1659%40isocpp.org</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BAqvO1Tdn-2NyEUBVMVJnuQw%2Bfsxym0=
gKVv1F5Q3sq3h5rLGw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BAqvO1Tdn=
-2NyEUBVMVJnuQw%2Bfsxym0gKVv1F5Q3sq3h5rLGw%40mail.gmail.com</a>.<br />

--0000000000003f51ac057c0fa94d--

.

------=_Part_4179_848349328.1543785723150
Content-Type: multipart/alternative;
 boundary="----=_Part_4180_1040366162.1543785723150"

------=_Part_4180_1040366162.1543785723150
Content-Type: text/plain; charset="UTF-8"

@Vicente:
I have reworked the introduction
<https://github.com/ginsbach/CppProposal/blob/release_70/ExtendedScopedEnumerations.pdf>
and inserted a discussion chapter using the week day example that you
provided, thank you very much for it. Do you think this is clearer now?

@Lawrence:
Thanks for the thoughts. I agree that this is an important distinction to
make here.
I would argue that scoped enumerations lean much more to option 1) than
option 2) and that is the perspective I had on the situation when I wrote
the proposal.
I would even go so far as to say there is a spectrum from option 2) to
option 1) going like this:
[int] -> [#define's] -> [unscoped enum] -> [scoped enum]

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/ea51f7a2-d576-4fd0-a182-b8c91f9c3656%40isocpp.org.

------=_Part_4180_1040366162.1543785723150
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>@Vicente:</div><div>I have <a href=3D"https://github.=
com/ginsbach/CppProposal/blob/release_70/ExtendedScopedEnumerations.pdf">re=
worked the introduction</a> and inserted a discussion chapter using the wee=
k day example that you provided, thank you very much for it. Do you think t=
his is clearer now?</div><div><br></div><div>@Lawrence:</div><div>Thanks fo=
r the thoughts. I agree that this is an important distinction to make here.=
</div><div>I would argue that scoped enumerations lean much more to option =
1) than option 2) and that is the perspective I had on the situation when I=
 wrote the proposal.</div><div>I would even go so far as to say there is a =
spectrum from option 2) to option 1) going like this:</div><div>[int] -&gt;=
 [#define&#39;s] -&gt; [unscoped enum] -&gt; [scoped enum]</div><div><br></=
div><div>Philip</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ea51f7a2-d576-4fd0-a182-b8c91f9c3656%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ea51f7a2-d576-4fd0-a182-b8c91f9c3656=
%40isocpp.org</a>.<br />

------=_Part_4180_1040366162.1543785723150--

------=_Part_4179_848349328.1543785723150--

.

------=_Part_4093_1842357115.1543787238288
Content-Type: multipart/alternative;
 boundary="----=_Part_4094_1294355688.1543787238289"

------=_Part_4094_1294355688.1543787238289
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Sunday, December 2, 2018 at 11:15:38 AM UTC-6, Vicente J. Botet Escriba=
=20
wrote:
>
> Le 02/12/2018 =C3=A0 17:25, cpplj...@gmail.com <javascript:> a =C3=A9crit=
 :
>
>
>
> On Sunday, December 2, 2018 at 7:47:40 AM UTC-6, Vicente J. Botet Escriba=
=20
> wrote:=20
>>
>> Le 02/12/2018 =C3=A0 02:49, phili...@gmail.com a =C3=A9crit :
>>
>> Hi all,=20
>>
>> I have updated the proposal=20
>> <https://github.com/ginsbach/CppProposal/blob/release_70/ExtendedScopedE=
numerations.pdf> 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 (=
as=20
>> ADA does - see=20
>> http://www.adaic.org/resources/add_content/standards/05rm/html/RM-3-5-1.=
html).=20
>> Have you considered this possibility? Are you sure that the common case =
is=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.
>
> Thanks for the link.=20
>
> I agree completely with you, and could then accept that : is used to mean=
=20
> super-type with sum-types.
>
> What is unfortunate is that we have used : to designate the underlying=20
> type as well.
>
>
> 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?
>
> This is the good case, as eB is a sub-type of eA, isn't it?=20
>
> I don't know, but I'd guess there would be a core dump or
> something as unpleasant.
>
> Why? What am I missing?
>
[snip]=20

Nothing.  Your question prompting my rethinking and now
I don't see any problem with using empty enums.  I just
rashly thought that anything with no possible value
would have to be undefined, but there is a value, just like:

struct empty_struct{};
union empty_union{};

have values.

Sorry for noise :(

-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/ad8e2253-66ac-416b-b200-b0d47c58de75%40isocpp.or=
g.

------=_Part_4094_1294355688.1543787238289
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Sunday, December 2, 2018 at 11:15:38 AM UTC-6, =
Vicente J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>
 =20
   =20
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div>Le 02/12/2018 =C3=A0 17:25,
      <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"AB=
9eAy4vAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#3=
9;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;"=
>cpplj...@gmail.com</a> a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
     =20
      <div dir=3D"ltr"><br>
        <br>
        On Sunday, December 2, 2018 at 7:47:40 AM UTC-6, Vicente J.
        Botet Escriba wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
          <div text=3D"#000000" bgcolor=3D"#FFFFFF">
            <div>Le 02/12/2018 =C3=A0 02:49, <a rel=3D"nofollow">phili...@g=
mail.com</a> a =C3=A9crit=C2=A0:<br>
            </div>
            <blockquote type=3D"cite">
              <div dir=3D"ltr">Hi all,
                <div><br>
                </div>
                <div>I have updated the <a href=3D"https://github.com/ginsb=
ach/CppProposal/blob/release_70/ExtendedScopedEnumerations.pdf" rel=3D"nofo=
llow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;https://www.google.=
com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fginsbach%2FCppProposal%2Fblob%2Frel=
ease_70%2FExtendedScopedEnumerations.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNE_f5CeZNAHeg_IuZwkV18F1aX8YA&#39;;return true;" onclick=3D"this.href=
=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fginsbach=
%2FCppProposal%2Fblob%2Frelease_70%2FExtendedScopedEnumerations.pdf\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE_f5CeZNAHeg_IuZwkV18F1aX8YA&#39;;return t=
rue;">proposal</a>=C2=A0to
                  reflect some of your feedback:</div>
                <br>
              </div>
            </blockquote>
            <p>I&#39;ve some trouble with the way you use sub-typing &quot;=
there
              is a natural correspondence between sub-typing and adding
              enumerators to enums&quot;. <br>
            </p>
            <p>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 <a hre=
f=3D"http://www.adaic.org/resources/add_content/standards/05rm/html/RM-3-5-=
1.html" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.adaic.org%2Fresources%2Fadd=
_content%2Fstandards%2F05rm%2Fhtml%2FRM-3-5-1.html\x26sa\x3dD\x26sntz\x3d1\=
x26usg\x3dAFQjCNGXgIm3DKkm2_D1VAgEQTCE7jjjzg&#39;;return true;" onclick=3D"=
this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.adaic.org%=
2Fresources%2Fadd_content%2Fstandards%2F05rm%2Fhtml%2FRM-3-5-1.html\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGXgIm3DKkm2_D1VAgEQTCE7jjjzg&#39;;return t=
rue;">http://www.adaic.org/<wbr>resources/add_content/<wbr>standards/05rm/h=
tml/RM-3-5-1.<wbr>html</a>).
              Have you considered this possibility? Are you sure that
              the common case is to extend enumerators, or to restrict
              them. Maybe both are useful.<br>
            </p>
            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. </div>
        </blockquote>
        <div>[snip]=C2=A0</div>
        <div>I agree with Vincente that super-type is the correct term.<br>
          The reason it seems weird is because class inheritance is<br>
          for product types whereas enum inheritance is for sum types<br>
          (e.g. std::variant):<br>
          <br>
          =C2=A0 <a href=3D"https://en.wikipedia.org/wiki/Algebraic_data_ty=
pe" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http=
s://www.google.com/url?q\x3dhttps%3A%2F%2Fen.wikipedia.org%2Fwiki%2FAlgebra=
ic_data_type\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFvc3wUerLJ0PbmQaM5DD7Z=
naXf2g&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.google.co=
m/url?q\x3dhttps%3A%2F%2Fen.wikipedia.org%2Fwiki%2FAlgebraic_data_type\x26s=
a\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFvc3wUerLJ0PbmQaM5DD7ZnaXf2g&#39;;retur=
n true;">https://en.wikipedia.org/wiki/<wbr>Algebraic_data_type</a><br>
          <br>
          and the duality property of category theory:<br>
          <br>
          =C2=A0 <a href=3D"https://en.wikipedia.org/wiki/Dual_(category_th=
eory)" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;h=
ttps://www.google.com/url?q\x3dhttps%3A%2F%2Fen.wikipedia.org%2Fwiki%2FDual=
_(category_theory)\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE5Dx15TJ5yxx_O3i=
Ud3vjeWkQPkg&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.goo=
gle.com/url?q\x3dhttps%3A%2F%2Fen.wikipedia.org%2Fwiki%2FDual_(category_the=
ory)\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE5Dx15TJ5yxx_O3iUd3vjeWkQPkg&#=
39;;return true;">https://en.wikipedia.org/wiki/<wbr>Dual_(category_theory)=
</a><br>
          =C2=A0 <br>
          says that the arrows are reversed in the dual category.<br>
        </div>
      </div>
    </blockquote>
    <p>Thanks for the link. <br>
    </p>
    <p>I agree completely with you, and could then accept that : is used
      to mean super-type with sum-types.</p>
    <p>What is unfortunate is that we have used : to designate the
      underlying type as well.</p>
    <p><br>
    </p>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>In this particular case, the arrow is the Liskov <br>
          substitution principle mentioned in Bernardo&#39;s post.<br>
          <br>
          More formally, let:<br>
          <br>
          =C2=A0 A &lt;: B<br>
          =C2=A0 <br>
          mean a type A can be substituted where a type B is expected(<br>
          i.e. the Liskov principle).<br>
          <br>
          Now if:<br>
          <br>
          =C2=A0 struct sB{int b_1; char b_2;}<br>
          =C2=A0 struct sA : sB{ bool a_3};<br>
          =C2=A0 <br>
          then:<br>
          <br>
          =C2=A0 sA &lt;: sB<br>
          =C2=A0 <br>
          IOW, an instance of sA can substituted anywhere an instance<br>
          of sB is expected (because sA has all of the fields that sB<br>
          has).<br>
          =C2=A0 <br>
          OTOH, if:<br>
          <br>
          =C2=A0 enum eB{b_1,b_2};<br>
          =C2=A0 enum eA : eB{a_3};<br>
          =C2=A0 <br>
          then:<br>
          <br>
          =C2=A0 eB &lt;: eA<br>
          <br>
          IOW, an instance of eB (e.g. b_2) can be substituted<br>
          anywhere an instance of eA is expected (because b_2 is<br>
          actually a member of eA as well as a member of eB).<br>
          <br>
          OTOH, there&#39;s an interesting corner case:<br>
          <br>
          =C2=A0 enum eB{};<br>
          =C2=A0 enum eA : eB{a_3};<br>
          =C2=A0 <br>
          Now what happens when:<br>
          <br>
          =C2=A0 eB b_0;<br>
          =C2=A0 <br>
          is used where an eA is expected?<br>
          <br>
        </div>
      </div>
    </blockquote>
    This is the good case, as eB is a sub-type of eA, isn&#39;t it?
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>I don&#39;t know, but I&#39;d guess there would be a core dump=
 or<br>
          something as unpleasant.<br>
        </div>
      </div>
    </blockquote>
    <p>Why? What am I missing?</p></div></blockquote><div text=3D"#000000" =
bgcolor=3D"#FFFFFF">[snip] <br></div><div text=3D"#000000" bgcolor=3D"#FFFF=
FF"><br></div><div text=3D"#000000" bgcolor=3D"#FFFFFF">Nothing.=C2=A0 Your=
 question prompting my rethinking and now<br></div><div>I don&#39;t see any=
 problem with using empty enums.=C2=A0 I just</div><div>rashly thought that=
 anything with no possible value</div><div>would have to be undefined, but =
there is a value, just like:</div><div><br></div><div>struct empty_struct{}=
;</div><div>union empty_union{};</div><div><br></div><div>have values.</div=
><div><br></div><div>Sorry for noise :(</div><div><br></div><div>-Larry</di=
v></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ad8e2253-66ac-416b-b200-b0d47c58de75%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ad8e2253-66ac-416b-b200-b0d47c58de75=
%40isocpp.org</a>.<br />

------=_Part_4094_1294355688.1543787238289--

------=_Part_4093_1842357115.1543787238288--

.

This is a multi-part message in MIME format.
--------------913A562C87EF390F90EE6AE6
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 02/12/2018 =C3=A0 22:22, philipgins@gmail.com a =C3=A9crit=C2=A0:
> @Vicente:
> I have reworked the introduction=20
> <https://github.com/ginsbach/CppProposal/blob/release_70/ExtendedScopedEn=
umerations.pdf>=20
> and inserted a discussion chapter using the week day example that you=20
> provided, thank you very much for it. Do you think this is clearer now?
>
Yes, it is better. I'll see if I can propose some improvements.

The use of extension could be misleading as other languages uses extends=20
for inheritance.

The systax part could talk about the possible use of <: as a sub-tyte=20
relationship between enums, even if you are not proposing it.

BTW, concerning restriction, the fact that we can express it as a=20
predicate, is not a good rationale to don't have a mechanism to define a=20
type. See how we are introducing types as not_null<Ptr> in the GSL.

More I think on your example and more I believe there is something wrong=20
with it as motivating example. While I agree with you that a Tokenizer=20
has not to use a SyntaxType enum, I don't see why a Parser must mix=20
TokenTypes and SyntaxTypes. A Syntax Node is not a Token Node. We have=20
the token ':' but we don't have an associated syntax type. Having to do=20
the explicit mapping from TokenType to SyntaxType seems to me the best.=20
I don't believe this would pass code review with our standards. What is=20
the cost of not having using this feature on this example? As I say,=20
this implies to do some kind of conversion at some time. This=20
conversions is defined by the user and so must be maintained. It could=20
have a little run-time penalty. BTW, what happens with your example if=20
we add new TokenTypes. I believe we need a better example for=20
extensions. I'll think a little bit on that.


Hopping this helps,

Vicente

--=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/9fa1b055-91e4-3a90-3aba-340efa5db725%40wanadoo.f=
r.

--------------913A562C87EF390F90EE6AE6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 02/12/2018 =C3=A0 22:22,
      <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:philipgins@gmail=
..com">philipgins@gmail.com</a> a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"
      cite=3D"mid:ea51f7a2-d576-4fd0-a182-b8c91f9c3656@isocpp.org">
      <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF=
-8">
      <div dir=3D"ltr">
        <div>@Vicente:</div>
        <div>I have <a
href=3D"https://github.com/ginsbach/CppProposal/blob/release_70/ExtendedSco=
pedEnumerations.pdf"
            moz-do-not-send=3D"true">reworked the introduction</a> and
          inserted a discussion chapter using the week day example that
          you provided, thank you very much for it. Do you think this is
          clearer now?</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <p>Yes, it is better. I'll see if I can propose some improvements.</p>
    <p>The use of extension could be misleading as other languages uses
      extends for inheritance.</p>
    <p>The systax part could talk about the possible use of &lt;: as a
      sub-tyte relationship between enums, even if you are not proposing
      it. <br>
    </p>
    <p>BTW, concerning restriction, the fact that we can express it as a
      predicate, is not a good rationale to don't have a mechanism to
      define a type. See how we are introducing types as
      not_null&lt;Ptr&gt; in the GSL.<br>
    </p>
    <p>More I think on your example and more I believe there is
      something wrong with it as motivating example. While I agree with
      you that a Tokenizer has not to use a SyntaxType enum, I don't see
      why a Parser must mix TokenTypes and SyntaxTypes. A Syntax Node is
      not a Token Node. We have the token ':' but we don't have an
      associated syntax type. Having to do the explicit mapping from
      TokenType to SyntaxType seems to me the best. I don't believe this
      would pass code review with our standards. What is the cost of not
      having using this feature on this example? As I say, this implies
      to do some kind of conversion at some time. This conversions is
      defined by the user and so must be maintained. It could have a
      little run-time penalty. BTW, what happens with your example if we
      add new TokenTypes. I believe we need a better example for
      extensions. I'll think a little bit on that. <br>
    </p>
    <p><br>
    </p>
    <p>Hopping this helps,</p>
    <p>Vicente<br>
    </p>
  </body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9fa1b055-91e4-3a90-3aba-340efa5db725%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9fa1b055-91e4-3a90-3aba-340efa5db725=
%40wanadoo.fr</a>.<br />

--------------913A562C87EF390F90EE6AE6--

.

This is a multi-part message in MIME format.
--------------B4B5556FA782F600CF93BDE7
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 02/12/2018 =C3=A0 22:47, cppljevans@gmail.com a =C3=A9crit=C2=A0:
>
>
> On Sunday, December 2, 2018 at 11:15:38 AM UTC-6, Vicente J. Botet=20
> Escriba wrote:
>
>     Le 02/12/2018 =C3=A0 17:25, cpplj...@gmail.com <javascript:> a =C3=A9=
crit=C2=A0:
>>
>>
>>
>>     OTOH, there's an interesting corner case:
>>
>>     =C2=A0 enum eB{};
>>     =C2=A0 enum eA : eB{a_3};
>>
>>     Now what happens when:
>>
>>     =C2=A0 eB b_0;
>>
>>     is used where an eA is expected?
>>
>     This is the good case, as eB is a sub-type of eA, isn't it?
>>     I don't know, but I'd guess there would be a core dump or
>>     something as unpleasant.
>
>     Why? What am I missing?
>
> [snip]
>
> Nothing.=C2=A0 Your question prompting my rethinking and now
> I don't see any problem with using empty enums.=C2=A0 I just
> rashly thought that anything with no possible value
> would have to be undefined, but there is a value, just like:
>
> struct empty_struct{};
> union empty_union{};
>
> have values.
>
Oh, sorry I should read your code more carefully.

I didn't saw that eB had no enumerators :(

I agree that this is weird and as a corner case, we need to understand=20
what it means.


The problem with enums in C/C++ is that they do too much and too little.

* They can be seen as sum-types in other languages, but they aren't in=20
C/C++. In C/C++ they are integral types, with a limited number of=20
literals (enumerators).

* They don't require to be used only with his enumerators. The range of=20
valid values is unfortunately more complex than that.

* They can be used to define some sort of reduced strong types, e.g for=20
std::byte, to inhibit some unwanted conversions.

On the other side enums are not classes and we cannot define=20
construction or conversion as we have for other used defined types.


Vicente

--=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/a8ead982-285c-87cd-0bac-1d2061bd2dfb%40wanadoo.f=
r.

--------------B4B5556FA782F600CF93BDE7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 02/12/2018 =C3=A0 22:47,
      <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:cppljevans@gmail=
..com">cppljevans@gmail.com</a> a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"
      cite=3D"mid:ad8e2253-66ac-416b-b200-b0d47c58de75@isocpp.org">
      <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF=
-8">
      <div dir=3D"ltr"><br>
        <br>
        On Sunday, December 2, 2018 at 11:15:38 AM UTC-6, Vicente J.
        Botet Escriba wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div text=3D"#000000" bgcolor=3D"#FFFFFF">
            <div>Le 02/12/2018 =C3=A0 17:25, <a href=3D"javascript:"
                target=3D"_blank" gdf-obfuscated-mailto=3D"AB9eAy4vAwAJ"
                rel=3D"nofollow"
                onmousedown=3D"this.href=3D'javascript:';return true;"
                onclick=3D"this.href=3D'javascript:';return true;"
                moz-do-not-send=3D"true">cpplj...@gmail.com</a> a =C3=A9cri=
t=C2=A0:<br>
            </div>
            <blockquote type=3D"cite">
              <div><br>
                <br>
                <br>
                OTOH, there's an interesting corner case:<br>
                <br>
                =C2=A0 enum eB{};<br>
                =C2=A0 enum eA : eB{a_3};<br>
                =C2=A0 <br>
                Now what happens when:<br>
                <br>
                =C2=A0 eB b_0;<br>
                =C2=A0 <br>
                is used where an eA is expected?<br>
                <br>
              </div>
            </blockquote>
            <blockquote type=3D"cite">
              <div dir=3D"ltr"> </div>
            </blockquote>
            This is the good case, as eB is a sub-type of eA, isn't it?
            <blockquote type=3D"cite">
              <div dir=3D"ltr">
                <div>I don't know, but I'd guess there would be a core
                  dump or<br>
                  something as unpleasant.<br>
                </div>
              </div>
            </blockquote>
            <p>Why? What am I missing?</p>
          </div>
        </blockquote>
        <div text=3D"#000000" bgcolor=3D"#FFFFFF">[snip] <br>
        </div>
        <div text=3D"#000000" bgcolor=3D"#FFFFFF"><br>
        </div>
        <div text=3D"#000000" bgcolor=3D"#FFFFFF">Nothing.=C2=A0 Your quest=
ion
          prompting my rethinking and now<br>
        </div>
        <div>I don't see any problem with using empty enums.=C2=A0 I just</=
div>
        <div>rashly thought that anything with no possible value</div>
        <div>would have to be undefined, but there is a value, just
          like:</div>
        <div><br>
        </div>
        <div>struct empty_struct{};</div>
        <div>union empty_union{};</div>
        <div><br>
        </div>
        <div>have values.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <p>Oh, sorry I should read your code more carefully.</p>
    <p>I didn't saw that eB had no enumerators :(<br>
    </p>
    <p>I agree that this is weird and as a corner case, we need to
      understand what it means. <br>
    </p>
    <p><br>
    </p>
    <p>The problem with enums in C/C++ is that they do too much and too
      little.<br>
    </p>
    <p>* They can be seen as sum-types in other languages, but they
      aren't in C/C++. In C/C++ they are integral types, with a limited
      number of literals (enumerators).<br>
    </p>
    <p>* They don't require to be used only with his enumerators. The
      range of valid values is unfortunately more complex than that.<br>
    </p>
    <p>* They can be used to define some sort of reduced strong types,
      e.g for std::byte, to inhibit some unwanted conversions.<br>
    </p>
    On the other side enums are not classes and we cannot define
    construction or conversion as we have for other used defined types.
    <p><br>
    </p>
    Vicente<br>
  </body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a8ead982-285c-87cd-0bac-1d2061bd2dfb%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a8ead982-285c-87cd-0bac-1d2061bd2dfb=
%40wanadoo.fr</a>.<br />

--------------B4B5556FA782F600CF93BDE7--

.

------=_Part_4738_118108760.1543954208051
Content-Type: multipart/alternative;
 boundary="----=_Part_4739_189906317.1543954208051"

------=_Part_4739_189906317.1543954208051
Content-Type: text/plain; charset="UTF-8"



On Sunday, December 2, 2018 at 3:49:17 AM UTC-6, Andrew Tomazos wrote:
>
> Mechnically WHAT you are proposing is pretty clear.  You need to do a
> better job on the WHY.
>
> Concretely, in your motivation section, I would find and highlight some
> examples in real world open source code where availability of this feature,
> if it was used, would make things better.
>
> When we were proposing nested namespaces (which got accepted into C++17)
> we pointed to boost, and showed that they could be applied 5000+ times
> there.
>
> You need to do something similiar, otherwise EWG is just going to ask what
> the problem is this is trying to address.  Proposals are only accepted if
> they are thought to solve an important problem faced by real world C++
> programmers.
>

I thought Vicente's mention about ADA enumeration restriction here:


https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/yxecGn2kOk0/zJYTvNQjAwAJ

was insightful in this regard.  If Philip found how this is useful in
some example ADA programs, and how the corresponding c++ program,
using the existing c++ language, would be difficult, but with his
proposed c++, much easier, that would be
at least a start of the explanation of the WHY.

-regards,
Larry
[snip]

--
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/ec4ca33b-fd59-4ddc-98e5-ade8700c8f39%40isocpp.org.

------=_Part_4739_189906317.1543954208051
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Sunday, December 2, 2018 at 3:49:17 AM UTC-6, A=
ndrew Tomazos wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">Mechnically WHAT you are proposing is pretty clear.=C2=A0 You need=
 to do a better job on the WHY.<div><br></div><div>Concretely, in your moti=
vation section, I would find and highlight some examples in real world open=
 source code where availability of this feature, if it was used, would make=
 things better.<div><br></div><div>When we were proposing nested namespaces=
 (which got accepted into C++17) we pointed to boost, and showed that they =
could be applied 5000+ times there.<br></div><div><br></div><div>You need t=
o do something similiar, otherwise EWG is just going to ask what the proble=
m is this is trying to address.=C2=A0 Proposals are only accepted if they a=
re thought to solve an important problem faced by real world C++ programmer=
s.</div></div></div></blockquote><div><br></div><div>I thought Vicente&#39;=
s mention about ADA enumeration restriction here:</div><div><br></div><div>=
=C2=A0 https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/yxe=
cGn2kOk0/zJYTvNQjAwAJ</div><div><br></div><div>was insightful in this regar=
d.=C2=A0 If Philip found how this is useful in <br></div><div>some example =
ADA programs, and how the corresponding c++ program, <br></div><div>using t=
he existing c++ language, would be difficult, but with his</div><div>propos=
ed c++, much easier, that would be</div><div>at least a start of the explan=
ation of the WHY.</div><div><br></div><div>-regards,</div><div>Larry<br></d=
iv>[snip]<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ec4ca33b-fd59-4ddc-98e5-ade8700c8f39%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ec4ca33b-fd59-4ddc-98e5-ade8700c8f39=
%40isocpp.org</a>.<br />

------=_Part_4739_189906317.1543954208051--

------=_Part_4738_118108760.1543954208051--

.

------=_Part_2210_361880234.1544549720089
Content-Type: multipart/alternative;
 boundary="----=_Part_2211_29814344.1544549720089"

------=_Part_2211_29814344.1544549720089
Content-Type: text/plain; charset="UTF-8"

Hi all,

Thanks everybody for you feedback. I think at this point it's pretty clear
that the remaining big issue is the motivation of the whole proposal, i.e.
I need better examples than the Token/Syntax snippet that I started out
with.
Andrew, Vicente and Larry all pointed that out and I will need some time to
think about it. Some suggestions have been given that I will use as a
starting point.
I will try to revise my draft and get back to you when I have something new
to report.

Best,
Philip

On Tuesday, December 4, 2018 at 8:10:08 PM UTC, cpplj...@gmail.com wrote:
>
>
>
> On Sunday, December 2, 2018 at 3:49:17 AM UTC-6, Andrew Tomazos wrote:
>>
>> Mechnically WHAT you are proposing is pretty clear.  You need to do a
>> better job on the WHY.
>>
>> Concretely, in your motivation section, I would find and highlight some
>> examples in real world open source code where availability of this feature,
>> if it was used, would make things better.
>>
>> When we were proposing nested namespaces (which got accepted into C++17)
>> we pointed to boost, and showed that they could be applied 5000+ times
>> there.
>>
>> You need to do something similiar, otherwise EWG is just going to ask
>> what the problem is this is trying to address.  Proposals are only accepted
>> if they are thought to solve an important problem faced by real world C++
>> programmers.
>>
>
> I thought Vicente's mention about ADA enumeration restriction here:
>
>
> https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/yxecGn2kOk0/zJYTvNQjAwAJ
>
> was insightful in this regard.  If Philip found how this is useful in
> some example ADA programs, and how the corresponding c++ program,
> using the existing c++ language, would be difficult, but with his
> proposed c++, much easier, that would be
> at least a start of the explanation of the WHY.
>
> -regards,
> Larry
> [snip]
>

--
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/1b29a8ce-f1dd-478d-8957-fff4cf499dca%40isocpp.org.

------=_Part_2211_29814344.1544549720089
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi all,</div><div><br></div>Thanks everybody for you =
feedback. I think at this point it&#39;s pretty clear that the remaining bi=
g issue is the motivation of the whole proposal, i.e. I need better example=
s than the Token/Syntax snippet that I started out with.<div>Andrew, Vicent=
e and Larry all pointed that out and I will need some time to think about i=
t. Some suggestions have been given that I will use as a starting point.</d=
iv><div>I will try to revise my draft and get back to you when I have somet=
hing new to report.</div><div><br></div><div>Best,<br>Philip<br><br>On Tues=
day, December 4, 2018 at 8:10:08 PM UTC, cpplj...@gmail.com wrote:<blockquo=
te 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><br>On Sunday, Dec=
ember 2, 2018 at 3:49:17 AM UTC-6, Andrew Tomazos wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">Mechnically WHAT you are proposing =
is pretty clear.=C2=A0 You need to do a better job on the WHY.<div><br></di=
v><div>Concretely, in your motivation section, I would find and highlight s=
ome examples in real world open source code where availability of this feat=
ure, if it was used, would make things better.<div><br></div><div>When we w=
ere proposing nested namespaces (which got accepted into C++17) we pointed =
to boost, and showed that they could be applied 5000+ times there.<br></div=
><div><br></div><div>You need to do something similiar, otherwise EWG is ju=
st going to ask what the problem is this is trying to address.=C2=A0 Propos=
als are only accepted if they are thought to solve an important problem fac=
ed by real world C++ programmers.</div></div></div></blockquote><div><br></=
div><div>I thought Vicente&#39;s mention about ADA enumeration restriction =
here:</div><div><br></div><div>=C2=A0 <a href=3D"https://groups.google.com/=
a/isocpp.org/forum/#!msg/std-proposals/yxecGn2kOk0/zJYTvNQjAwAJ" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.goo=
gle.com/a/isocpp.org/forum/#!msg/std-proposals/yxecGn2kOk0/zJYTvNQjAwAJ&#39=
;;return true;" onclick=3D"this.href=3D&#39;https://groups.google.com/a/iso=
cpp.org/forum/#!msg/std-proposals/yxecGn2kOk0/zJYTvNQjAwAJ&#39;;return true=
;">https://groups.google.com/a/<wbr>isocpp.org/forum/#!msg/std-<wbr>proposa=
ls/yxecGn2kOk0/<wbr>zJYTvNQjAwAJ</a></div><div><br></div><div>was insightfu=
l in this regard.=C2=A0 If Philip found how this is useful in <br></div><di=
v>some example ADA programs, and how the corresponding c++ program, <br></d=
iv><div>using the existing c++ language, would be difficult, but with his</=
div><div>proposed c++, much easier, that would be</div><div>at least a star=
t of the explanation of the WHY.</div><div><br></div><div>-regards,</div><d=
iv>Larry<br></div>[snip]<br></div></blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1b29a8ce-f1dd-478d-8957-fff4cf499dca%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1b29a8ce-f1dd-478d-8957-fff4cf499dca=
%40isocpp.org</a>.<br />

------=_Part_2211_29814344.1544549720089--

------=_Part_2210_361880234.1544549720089--

.