------=_Part_9223_1478646832.1513981402932
Content-Type: multipart/alternative;
 boundary="----=_Part_9224_952140036.1513981402932"

------=_Part_9224_952140036.1513981402932
Content-Type: text/plain; charset="UTF-8"

I realized two days ago that there is no need to invent new syntax to bring
strong typedefs into C++. We already have them.

Indeed, we already have a construct that take a type as a parameter, and
creates a new type, gives it a new name, uses the passed argument as its
implementation, and this new type is not implicitly convertible to and from
the argument.

It's *enum class*.

However I look at it now, I can't consider it otherwise. *enum class *is
and means *strong typedef*. And now, instead of thinking "*enum class for
creating strong typedefs is no good. enum class is for creating strong
enums. We have to invent something else.*", I think "*enum class is strong
typedef*". And C++17 *strong typedef* sucks in two ways :

   - You can only apply *strong typedef* to integral types.
   - You can only add free functions as additional behaviour. (well, almost)

These problems are orthogonal. Fix both, and you get full-fledged strong
typedefs.


#1


The first problem can be fixed simply by allowing any type as the
underlying type of an *enum*. If the type is not literal, you can still use
it as underlying type. The only thing that requires the type to be literal
is the declaration of enumerators.


#2


The second problem finds its solution in paper P0707Rx (metaclasses), when
Herb Sutter thanks Dennis Ritchie twice for his insight of using the same
syntax for structs ans unions. Let's go further and use the same syntax for
struct, union and enums. Here is the recipe: (I may be wrong on any step,
it looks too simple)


   1. Add the production rules of *enum-key* to *class-key*
   2. Verify that *enum-head* now defines a proper sublanguage of
   *class-head*
   3. Replace the production rules of *class-specifier* by the following :
   class-head { enumerator-list ; member-specification }
   class-head { ;(opt) member-specification(opt) }
   class-head { enumerator-list ;(opt) }
   class-head { enumerator-list , }
   4. Verify that *enum-specifier* now defines a proper sublanguage of
   *class-specifier*
   5. Have *class-specifier *specifiy enumeration types in addition of what
   it already does.
   6. Get rid of *enum-specifier* and subsequently orphan production rules
   altogether.
   7. Forbid what was forbidden through syntax in C++17 by explicitly
   prosed restrictions.
   8. Get Committee approval for a gratuitous syntax change that brings no
   functionality, adds boatload of text to the Standard, yet breaks no code.
   9. Take time to think about what to allow for the enumeration types that
   could have members and be templated if we let them, and for class types
   that could declare enumerators if we let them.
   10. Lift restrictions as deemed wise.

Details comfortably ignored, I think it's the way to go. What do you think ?

--
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/3cfe53ce-0b2c-4bbf-9ea5-5073d11c9924%40isocpp.org.

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

<div dir=3D"ltr">I realized two days ago that there is no need to invent ne=
w syntax to bring strong typedefs into C++. We already have them.<br><br>In=
deed, we already have a construct that take a type as a parameter, and crea=
tes a new type, gives it a new name, uses the passed argument as its implem=
entation, and this new type is not implicitly convertible to and from the a=
rgument.<br><br>It&#39;s <i>enum class</i>.<br><br>However I look at it now=
, I can&#39;t consider it otherwise. <i>enum class </i>is and means <i>stro=
ng typedef</i>. And now, instead of thinking &quot;<i>enum class for creati=
ng strong typedefs is no good. enum class is for creating strong enums. We =
have to invent something else.</i>&quot;, I think &quot;<i>enum class is st=
rong typedef</i>&quot;. And C++17 <i>strong typedef</i> sucks in two ways :=
<br><ul><li>You can only apply <i>strong typedef</i> to integral types.</li=
><li>You can only add free functions as additional behaviour. (well, almost=
)</li></ul><p>These problems are orthogonal. Fix both, and you get full-fle=
dged strong typedefs.</p><p><br></p><p>#1<br></p><p><br></p><p>The first pr=
oblem can be fixed simply by allowing any type as the underlying type of an=
 <i>enum</i>. If the type is not literal, you can still use it as underlyin=
g type. The only thing that requires the type to be literal is the declarat=
ion of enumerators.</p><p><br></p><p>#2</p><p><br></p><p>The second problem=
 finds its solution in paper P0707Rx (metaclasses), when Herb Sutter thanks=
 Dennis Ritchie twice for his insight of using the same syntax for structs =
ans unions. Let&#39;s go further and use the same syntax for struct, union =
and enums. Here is the recipe: (I may be wrong on any step, it looks too si=
mple)<br></p><p></p><ol><li>Add the production rules of <i>enum-key</i> to =
<i>class-key</i></li><li>Verify that <i>enum-head</i> now defines a proper =
sublanguage of <i>class-head</i><br></li><li>Replace the production rules o=
f <i>class-specifier</i> by the following :<br>class-head { enumerator-list=
 ; member-specification }<br>class-head { ;(opt) member-specification(opt) =
}<br>class-head { enumerator-list ;(opt) }<br>class-head { enumerator-list =
, }</li><li>Verify that <i>enum-specifier</i> now defines a proper sublangu=
age of <i>class-specifier</i></li><li>Have <i>class-specifier </i>specifiy =
enumeration types in addition of what it already does.<br><i></i></li><li>G=
et rid of <i>enum-specifier</i> and subsequently orphan production rules al=
together.</li><li>Forbid what was forbidden through syntax in C++17 by expl=
icitly prosed restrictions.</li><li>Get Committee approval for a gratuitous=
 syntax change that brings no functionality, adds boatload of text to the S=
tandard, yet breaks no code.<br></li><li>Take time to think about what to a=
llow for the enumeration types that could have members and be templated if =
we let them, and for class types that could declare enumerators if we let t=
hem.</li><li>Lift restrictions as deemed wise.<br></li></ol><p>Details comf=
ortably ignored, I think it&#39;s the way to go. What do you think ?<br></p=
></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/3cfe53ce-0b2c-4bbf-9ea5-5073d11c9924%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3cfe53ce-0b2c-4bbf-9ea5-5073d11c9924=
%40isocpp.org</a>.<br />

------=_Part_9224_952140036.1513981402932--

------=_Part_9223_1478646832.1513981402932--

.