------=_Part_9432_995160895.1513983986332
Content-Type: multipart/alternative;
 boundary="----=_Part_9433_1916340987.1513983986332"

------=_Part_9433_1916340987.1513983986332
Content-Type: text/plain; charset="UTF-8"

 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. Merge chapter 7 into chapter 6.
   8. Get Committee approval for a gratuitous syntax change that brings no
   functionality, edits 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.

Annoying 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/f114e753-c56f-42b1-bc62-2a6fc9650333%40isocpp.org.

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

<div dir=3D"ltr"> realized two days ago that there is no need to invent new=
 syntax to bring strong typedefs into C++. We already have them.<br><br>Ind=
eed,
 we already have a construct that take a type as a parameter, and=20
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=20
from the argument.<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 mea=
ns <i>strong typedef</i>. And now, instead of thinking &quot;<i>enum class =
for creating 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 c=
lass is strong 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. (we=
ll, almost)</li></ul><p>These problems are orthogonal. Fix both, and you ge=
t full-fledged strong typedefs.</p><p><br></p><p>#1<br></p><p><br></p><p>Th=
e first problem 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 underlying type.=20
The only thing that requires the type to be literal is the declaration=20
of enumerators.</p><p><br></p><p>#2</p><p><br></p><p>The second problem=20
finds its solution in paper P0707Rx (metaclasses), when Herb Sutter=20
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=20
struct, union and enums. Here is the recipe: (I may be wrong on any=20
step, it looks too simple)<br></p><ol><li>Add the production rules of <i>en=
um-key</i> to <i>class-key</i></li><li>Verify that <i>enum-head</i> now def=
ines a proper sublanguage of <i>class-head</i><br></li><li>Replace the prod=
uction rules of <i>class-specifier</i> by the following :<br>class-head { e=
numerator-list ; member-specification }<br>class-head { ;(opt) member-speci=
fication(opt) }<br>class-head { enumerator-list ;(opt) }<br>class-head { en=
umerator-list , }</li><li>Verify that <i>enum-specifier</i> now defines a p=
roper sublanguage of <i>class-specifier</i></li><li>Have <i>class-specifier=
 </i>specifiy enumeration types in addition of what it already does.<br></l=
i><li>Get rid of <i>enum-specifier</i> and subsequently orphan production r=
ules altogether.</li><li>Forbid what was forbidden through syntax in C++17 =
by explicitly prosed restrictions. Merge chapter 7 into chapter 6.<br></li>=
<li>Get
 Committee approval for a gratuitous syntax change that brings no=20
functionality, edits boatload of text to the Standard, yet breaks no=20
code.<br></li><li>Take time to think about what to allow for the=20
enumeration types that could have members and be templated if we let=20
them, and for class types that could declare enumerators if we let them.</l=
i><li>Lift restrictions as deemed wise.<br></li></ol>Annoying details comfo=
rtably ignored, I think it&#39;s the way to go. What do you think ?</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/f114e753-c56f-42b1-bc62-2a6fc9650333%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f114e753-c56f-42b1-bc62-2a6fc9650333=
%40isocpp.org</a>.<br />

------=_Part_9433_1916340987.1513983986332--

------=_Part_9432_995160895.1513983986332--

.

------=_Part_9492_439729465.1513986126870
Content-Type: multipart/alternative;
 boundary="----=_Part_9493_1865236300.1513986126870"

------=_Part_9493_1865236300.1513986126870
Content-Type: text/plain; charset="UTF-8"



On Friday, December 22, 2017 at 6:06:26 PM UTC-5, Laurent LA RIZZA wrote:
>
> 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.
>

No.

It was a mistake for the committee to use `enum class` to create strong
typedefs. It would only compound this error to continue this belief.

The problem with strong typedefs has* never* been the question of "what
syntax do I use?" It's always been a matter of what behavior you get in the
myriad of circumstances where you want strong typedef. That is, the
question of how strong of an alias do you want.

`enum class` works as a strong typedef for integral types because there's
pretty much only one level of "strength" as far as integers are concerned.
User-defined types have many possible levels of "strength", and different
people have different needs.

--
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/d6b7768a-c2c7-488c-86b3-8b28e7b2a1c3%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, December 22, 2017 at 6:06:26 PM UTC-5, =
Laurent LA RIZZA wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"> realized two days ago that there is no need to invent new syntax=
 to bring strong typedefs into C++. We already have them.<br><br>Indeed,
 we already have a construct that take a type as a parameter, and=20
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=20
from the argument.<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 mea=
ns <i>strong typedef</i>. And now, instead of thinking &quot;<i>enum class =
for creating 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 c=
lass is strong 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. (we=
ll, almost)</li></ul><p>These problems are orthogonal. Fix both, and you ge=
t full-fledged strong typedefs.</p></div></blockquote><div><br></div><div>N=
o.</div><div><br></div><div>It was a mistake for the committee to use `enum=
 class` to create strong typedefs. It would only compound this error to con=
tinue this belief.</div><div><br></div><div>The problem with strong typedef=
s has<i> never</i> been the question of &quot;what syntax do I use?&quot; I=
t&#39;s always been a matter of what behavior you get in the myriad of circ=
umstances where you want strong typedef. That is, the question of how stron=
g of an alias do you want.</div><div><br></div><div>`enum class` works as a=
 strong typedef for integral types because there&#39;s pretty much only one=
 level of &quot;strength&quot; as far as integers are concerned. User-defin=
ed types have many possible levels of &quot;strength&quot;, and different p=
eople have different needs.</div><div><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/d6b7768a-c2c7-488c-86b3-8b28e7b2a1c3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d6b7768a-c2c7-488c-86b3-8b28e7b2a1c3=
%40isocpp.org</a>.<br />

------=_Part_9493_1865236300.1513986126870--

------=_Part_9492_439729465.1513986126870--

.

------=_Part_10080_1769166666.1514022915364
Content-Type: multipart/alternative;
 boundary="----=_Part_10081_1250765354.1514022915364"

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



Le samedi 23 d=C3=A9cembre 2017 00:42:06 UTC+1, Nicol Bolas a =C3=A9crit :
<snip/>=20

> It was a mistake for the committee to use `enum class` to create strong=
=20
> typedefs. It would only compound this error to continue this belief.
>
>
The committee did not use *enum class* to create strong typedefs. They used=
 *enum=20
class* to create scoped enums from unscoped enums.

The only adopted proposal I know of that links *enum class* to strong=20
typedef is P0138R2. The only justification of the paper is indeed "hey,=20
we're using enum class to create strong typedefs of integral types. Can we=
=20
fix construction please?" Was adoption a mistake? Maybe, I don't know.

This is my point. People already create strong typedefs of integral types=
=20
using *enum class*. I also do. Get over it. We have strong typedefs.=20

The problem with strong typedefs has* never* been the question of "what=20
> syntax do I use?" It's always been a matter of what behavior you get in t=
he=20
> myriad of circumstances where you want strong typedef. That is, the=20
> question of how strong of an alias do you want.
>
> `enum class` works as a strong typedef for integral types because there's=
=20
> pretty much only one level of "strength" as far as integers are concerned=
..=20
> User-defined types have many possible levels of "strength", and different=
=20
> people have different needs.
>

Can you please elaborate the use cases you think of where you would want=20
other aliasing strength than the binary "they're the same type/they're not=
=20
the same type"?
=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/f372e674-f341-4fbb-a1d3-77548284e13e%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>Le samedi 23 d=C3=A9cembre 2017 00:42:06 UTC+1, Ni=
col Bolas a =C3=A9crit=C2=A0:<div>&lt;snip/&gt; <br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div>It was a mistake for the =
committee to use `enum class` to create strong typedefs. It would only comp=
ound this error to continue this belief.</div><div><br></div></div></blockq=
uote><div><br></div><div>The committee did not use <i>enum class</i> to cre=
ate strong typedefs. They used <i>enum class</i> to create scoped enums fro=
m unscoped enums.</div><div><br></div><div>The only adopted proposal I know=
 of that links <i>enum class</i> to strong typedef is P0138R2. The only jus=
tification of the paper is indeed &quot;hey, we&#39;re using enum class to =
create strong typedefs of integral types. Can we fix construction please?&q=
uot; Was adoption a mistake? Maybe, I don&#39;t know.</div><div><br></div><=
div>This is my point. People already create strong typedefs of integral typ=
es using <i>enum class</i>. I also do. Get over it. We have strong typedefs=
.. <br> </div><div><br></div><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></div><div>The problem with strong typedefs has<i> neve=
r</i> been the question of &quot;what syntax do I use?&quot; It&#39;s alway=
s been a matter of what behavior you get in the myriad of circumstances whe=
re you want strong typedef. That is, the question of how strong of an alias=
 do you want.</div><div><br></div><div>`enum class` works as a strong typed=
ef for integral types because there&#39;s pretty much only one level of &qu=
ot;strength&quot; as far as integers are concerned. User-defined types have=
 many possible levels of &quot;strength&quot;, and different people have di=
fferent needs.</div></div></blockquote><div><br></div><div>Can you please e=
laborate the use cases you think of where you would want other aliasing str=
ength than the binary &quot;they&#39;re the same type/they&#39;re not the s=
ame type&quot;?<br></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/f372e674-f341-4fbb-a1d3-77548284e13e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f372e674-f341-4fbb-a1d3-77548284e13e=
%40isocpp.org</a>.<br />

------=_Part_10081_1250765354.1514022915364--

------=_Part_10080_1769166666.1514022915364--

.

------=_Part_10780_1735402885.1514043461539
Content-Type: multipart/alternative;
 boundary="----=_Part_10781_485976906.1514043461540"

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



On Saturday, December 23, 2017 at 4:55:15 AM UTC-5, Laurent LA RIZZA wrote:
>
>
>
> Le samedi 23 d=C3=A9cembre 2017 00:42:06 UTC+1, Nicol Bolas a =C3=A9crit =
:
> <snip/>=20
>
>> It was a mistake for the committee to use `enum class` to create strong=
=20
>> typedefs. It would only compound this error to continue this belief.
>>
>>
> The committee did not use *enum class* to create strong typedefs. They=20
> used *enum class* to create scoped enums from unscoped enums.=20
>

> The only adopted proposal I know of that links *enum class* to strong=20
> typedef is P0138R2. The only justification of the paper is indeed "hey,=
=20
> we're using enum class to create strong typedefs of integral types. Can w=
e=20
> fix construction please?" Was adoption a mistake? Maybe, I don't know.
>

Yes, that was exactly what I was referring to, and yes, *it was a mistake*.

This is my point. People already create strong typedefs of integral types=
=20
> using *enum class*. I also do. Get over it. We have strong typedefs.
>

Compounding a mistake with another mistake is absurd.


> The problem with strong typedefs has* never* been the question of "what=
=20
>> syntax do I use?" It's always been a matter of what behavior you get in =
the=20
>> myriad of circumstances where you want strong typedef. That is, the=20
>> question of how strong of an alias do you want.
>>
>> `enum class` works as a strong typedef for integral types because there'=
s=20
>> pretty much only one level of "strength" as far as integers are concerne=
d.=20
>> User-defined types have many possible levels of "strength", and differen=
t=20
>> people have different needs.
>>
>
> Can you please elaborate the use cases you think of where you would want=
=20
> other aliasing strength than the binary "they're the same type/they're no=
t=20
> the same type"?
>

Go read every strong typedef proposal that has ever been proposed. They do=
=20
a good job of covering the myriad of possible ways people want to deal with=
=20
such things.

However, as a simple example, let's say you have a class A, and you make a=
=20
strong typedef of it called B. Can B do everything that A could do? For=20
example, if A was Swappable, that means A probably has a non-member `swap`=
=20
function. Does B automatically get one? Should it? If A was addable to=20
integers via non-member `operator+`, should B be addable too?

And if you can't automatically get the non-member interfaces of A, then=20
what good is B?

--=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/e95936a3-2bc0-4a32-bd96-54ea39da308b%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Saturday, December 23, 2017 at 4:55:15 AM UTC-5=
, Laurent LA RIZZA wrote:<blockquote 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>Le samedi 23 d=C3=A9cembre 2017 00:42:06 UTC+1, Nicol B=
olas a =C3=A9crit=C2=A0:<div>&lt;snip/&gt; <br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div>It was a mistake for the committee =
to use `enum class` to create strong typedefs. It would only compound this =
error to continue this belief.</div><div><br></div></div></blockquote><div>=
<br></div><div>The committee did not use <i>enum class</i> to create strong=
 typedefs. They used <i>enum class</i> to create scoped enums from unscoped=
 enums.=C2=A0</div></div></blockquote><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div><br></div><div>The only adopted proposal I kn=
ow of that links <i>enum class</i> to strong typedef is P0138R2. The only j=
ustification of the paper is indeed &quot;hey, we&#39;re using enum class t=
o create strong typedefs of integral types. Can we fix construction please?=
&quot; Was adoption a mistake? Maybe, I don&#39;t know.</div></div></blockq=
uote><div><br></div><div>Yes, that was exactly what I was referring to, and=
 yes, <i>it was a mistake</i>.</div><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr"><div>This is my point. People already=
 create strong typedefs of integral types using <i>enum class</i>. I also d=
o. Get over it. We have strong typedefs.<br></div></div></blockquote><div><=
br></div><div>Compounding a mistake with another mistake is absurd.</div><d=
iv><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div></div><div> </div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div>The problem with strong typedefs has<i> never</i> =
been the question of &quot;what syntax do I use?&quot; It&#39;s always been=
 a matter of what behavior you get in the myriad of circumstances where you=
 want strong typedef. That is, the question of how strong of an alias do yo=
u want.</div><div><br></div><div>`enum class` works as a strong typedef for=
 integral types because there&#39;s pretty much only one level of &quot;str=
ength&quot; as far as integers are concerned. User-defined types have many =
possible levels of &quot;strength&quot;, and different people have differen=
t needs.</div></div></blockquote><div><br></div><div>Can you please elabora=
te the use cases you think of where you would want other aliasing strength =
than the binary &quot;they&#39;re the same type/they&#39;re not the same ty=
pe&quot;?<br></div></div></blockquote><div><br></div><div>Go read every str=
ong typedef proposal that has ever been proposed. They do a good job of cov=
ering the myriad of possible ways people want to deal with such things.</di=
v><div><br></div><div>However, as a simple example, let&#39;s say you have =
a class A, and you make a strong typedef of it called B. Can B do everythin=
g that A could do? For example, if A was Swappable, that means A probably h=
as a non-member `swap` function. Does B automatically get one? Should it? I=
f A was addable to integers via non-member `operator+`, should B be addable=
 too?</div><div><br></div><div>And if you can&#39;t automatically get the n=
on-member interfaces of A, then what good is B?</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/e95936a3-2bc0-4a32-bd96-54ea39da308b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e95936a3-2bc0-4a32-bd96-54ea39da308b=
%40isocpp.org</a>.<br />

------=_Part_10781_485976906.1514043461540--

------=_Part_10780_1735402885.1514043461539--

.

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

On 23 December 2017 at 09:55, Laurent LA RIZZA <the.ultimate.koala@gmail.co=
m
> wrote:

> Le samedi 23 d=C3=A9cembre 2017 00:42:06 UTC+1, Nicol Bolas a =C3=A9crit =
:
> <snip/>
>
>> It was a mistake for the committee to use `enum class` to create strong
>> typedefs. It would only compound this error to continue this belief.
>>
>>
> The committee did not use *enum class* to create strong typedefs. They
> used *enum class* to create scoped enums from unscoped enums.
>
> The only adopted proposal I know of that links *enum class* to strong
> typedef is P0138R2. The only justification of the paper is indeed "hey,
> we're using enum class to create strong typedefs of integral types. Can w=
e
> fix construction please?" Was adoption a mistake? Maybe, I don't know.
>
> This is my point. People already create strong typedefs of integral types
> using *enum class*. I also do. Get over it. We have strong typedefs.
>

We don't have good ones, though; look at the library portion of the <=3D>
design (particularly, p0515r3 section 3) for an example of what we're
missing. "enum class" was considered as a way of making
std::strong_ordering and friends be strong typedefs for int, but they don't
work. In that particular case the problem is that we wish to permit certain
kinds of conversion between std::strong_ordering and its related classes,
but that is not possible when using enum class to define a "strong typedef"=
..


> The problem with strong typedefs has* never* been the question of "what
>> syntax do I use?" It's always been a matter of what behavior you get in =
the
>> myriad of circumstances where you want strong typedef. That is, the
>> question of how strong of an alias do you want.
>>
>> `enum class` works as a strong typedef for integral types because there'=
s
>> pretty much only one level of "strength" as far as integers are concerne=
d.
>> User-defined types have many possible levels of "strength", and differen=
t
>> people have different needs.
>>
>
> Can you please elaborate the use cases you think of where you would want
> other aliasing strength than the binary "they're the same type/they're no=
t
> the same type"?
>
>
> --
> 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/f372e674-f341-4fbb-
> a1d3-77548284e13e%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f372e674-f3=
41-4fbb-a1d3-77548284e13e%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/CAOfiQqknWTHF3zUaxR40Uc4aR0L_rmcymzHLkUiZH4kmxvv=
G6g%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
3 December 2017 at 09:55, Laurent LA RIZZA <span dir=3D"ltr">&lt;<a href=3D=
"mailto:the.ultimate.koala@gmail.com" target=3D"_blank">the.ultimate.koala@=
gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr">Le samedi 23 d=C3=A9cembre 2017 00:42:06 UTC+1,=
 Nicol Bolas a =C3=A9crit=C2=A0:<div>&lt;snip/&gt; <br></div><span class=3D=
"gmail-"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><div>It was a mistake for the committee to use `enum class` to create stro=
ng typedefs. It would only compound this error to continue this belief.</di=
v><div><br></div></div></blockquote><div><br></div></span><div>The committe=
e did not use <i>enum class</i> to create strong typedefs. They used <i>enu=
m class</i> to create scoped enums from unscoped enums.</div><div><br></div=
><div>The only adopted proposal I know of that links <i>enum class</i> to s=
trong typedef is P0138R2. The only justification of the paper is indeed &qu=
ot;hey, we&#39;re using enum class to create strong typedefs of integral ty=
pes. Can we fix construction please?&quot; Was adoption a mistake? Maybe, I=
 don&#39;t know.</div><div><br></div><div>This is my point. People already =
create strong typedefs of integral types using <i>enum class</i>. I also do=
.. Get over it. We have strong typedefs.=C2=A0</div></div></blockquote><div>=
<br></div><div>We don&#39;t have good ones, though; look at the library por=
tion of the &lt;=3D&gt; design (particularly, p0515r3 section 3) for an exa=
mple of what we&#39;re missing. &quot;enum class&quot; was considered as a =
way of making std::strong_ordering and friends be strong typedefs for int, =
but they don&#39;t work. In that particular case the problem is that we wis=
h to permit certain kinds of conversion between std::strong_ordering and it=
s related classes, but that is not possible when using enum class to define=
 a &quot;strong typedef&quot;.</div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex"><div dir=3D"ltr"><span class=3D"gmail-"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div></div><div=
>The problem with strong typedefs has<i> never</i> been the question of &qu=
ot;what syntax do I use?&quot; It&#39;s always been a matter of what behavi=
or you get in the myriad of circumstances where you want strong typedef. Th=
at is, the question of how strong of an alias do you want.</div><div><br></=
div><div>`enum class` works as a strong typedef for integral types because =
there&#39;s pretty much only one level of &quot;strength&quot; as far as in=
tegers are concerned. User-defined types have many possible levels of &quot=
;strength&quot;, and different people have different needs.</div></div></bl=
ockquote><div><br></div></span><div>Can you please elaborate the use cases =
you think of where you would want other aliasing strength than the binary &=
quot;they&#39;re the same type/they&#39;re not the same type&quot;?<br></di=
v><div>=C2=A0</div></div><span class=3D"gmail-">

<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@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f372e674-f341-4fbb-a1d3-77548284e13e%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/f372=
e674-f341-4fbb-<wbr>a1d3-77548284e13e%40isocpp.org</a><wbr>.<br>
</blockquote></div><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/CAOfiQqknWTHF3zUaxR40Uc4aR0L_rmcymzHL=
kUiZH4kmxvvG6g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqknWTHF3zUa=
xR40Uc4aR0L_rmcymzHLkUiZH4kmxvvG6g%40mail.gmail.com</a>.<br />

--001a11c185ea0165da056104c1cc--

.

------=_Part_5488_1234003181.1514048142335
Content-Type: multipart/alternative;
 boundary="----=_Part_5489_524707835.1514048142335"

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



Le samedi 23 d=C3=A9cembre 2017 16:37:41 UTC+1, Nicol Bolas a =C3=A9crit :
=20

> Can we fix construction please?" Was adoption a mistake? Maybe, I don't=
=20
>> know.
>>
>
> Yes, that was exactly what I was referring to, and yes, *it was a mistake=
*
> .
>
> I still don't know, that does not change the fact that even before that=
=20
"mistake", people were using *enum class* to create strong typedefs of=20
integral types. We have strong typedefs in C++17.
=20

> This is my point. People already create strong typedefs of integral types=
=20
>> using *enum class*. I also do. Get over it. We have strong typedefs.
>>
>
> Compounding a mistake with another mistake is absurd.
>

Same answer. Adoption of P0138R2 is irrelevant to my-mine-and-only-of-me=20
statement that we have strong typedefs in C++17. It being a mistake is your=
=20
opinion, not a fact.

>
>
>> Can you please elaborate the use cases you think of where you would want=
=20
>> other aliasing strength than the binary "they're the same type/they're n=
ot=20
>> the same type"?
>>
>
> Go read every strong typedef proposal that has ever been proposed. They d=
o=20
> a good job of covering the myriad of possible ways people want to deal wi=
th=20
> such things.
>

I have done (a long time ago), and will do again. I thank you for=20
expressing your opinions on my ideas.=20

>
> However, as a simple example, let's say you have a class A, and you make =
a=20
> strong typedef of it called B.
>

OK, so :

* enum class B : A {};*

Can B do everything that A could do?=20
>

No. It can be explicitly convertible to and from *A* (with and without=20
variable numbers of ampersands, but I haven't thought it through) If A is=
=20
literal, you can define named constants of type B. You can add also add=20
member non-variables.
 =20

> For example, if A was Swappable, that means A probably has a non-member=
=20
> `swap` function.=20
>

*enum class B : A {*
*public :*

*  friend void swap(B&, B&) =3D default;*
*};*

Does B automatically get one?
>

No.

Should it?=20
>

No.

If A was addable to integers via non-member `operator+`, should B be=20
> addable too?
>
> No, but :

*enum class B : A {*
*public :*

*  friend B operator+(const B&, int) =3D default;*
*};*

And if you can't automatically get the non-member interfaces of A, then=20
> what good is B?
>
=20
B is a distinct type from A, explicitly convertible to and from it. B is=20
stored the same way as A. It is as copyable, movable, assignable and=20
destructible as A, except the signatures get B in lieu of A.

You can't even have them non-automatically in C++17, since you can't define=
=20
B if A is not an integral type.

A question for you : if using enum class for creating strong aliases of=20
integral types in C++17 is a mistake, how do you create strong aliases of=
=20
integral types in C++17?

--=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/2667d45a-3db6-4994-ac1f-e8c2880700c8%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>Le samedi 23 d=C3=A9cembre 2017 16:37:41 UTC+1, Ni=
col Bolas a =C3=A9crit=C2=A0:<div>=C2=A0</div><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"><blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div>Can we fix construction please?&quot; Was adoption a mi=
stake? Maybe, I don&#39;t know.</div></div></blockquote><div><br></div><div=
>Yes, that was exactly what I was referring to, and yes, <i>it was a mistak=
e</i>.</div><div><br></div></div></blockquote><div>I still don&#39;t know, =
that does not change the fact that even before that &quot;mistake&quot;, pe=
ople were using <i>enum class</i> to create strong typedefs of integral typ=
es. We have strong typedefs in C++17.<br></div><div>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div>This is my point. People a=
lready create strong typedefs of integral types using <i>enum class</i>. I =
also do. Get over it. We have strong typedefs.<br></div></div></blockquote>=
<div><br></div><div>Compounding a mistake with another mistake is absurd.</=
div></div></blockquote><div><br></div><div>Same answer. Adoption of P0138R2=
 is irrelevant to my-mine-and-only-of-me statement that we have strong type=
defs in C++17. It being a mistake is your opinion, not a fact.<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div> </=
div><div></div><br><div>Can you please elaborate the use cases you think of=
 where you would want other aliasing strength than the binary &quot;they&#3=
9;re the same type/they&#39;re not the same type&quot;?<br></div></div></bl=
ockquote><div><br></div><div>Go read every strong typedef proposal that has=
 ever been proposed. They do a good job of covering the myriad of possible =
ways people want to deal with such things.</div></div></blockquote><div><br=
></div><div>I have done (a long time ago), and will do again. I thank you f=
or expressing your opinions on my ideas. <br></div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><div>However, as a sim=
ple example, let&#39;s say you have a class A, and you make a strong typede=
f of it called B.</div></div></blockquote><div><br></div><div>OK, so :</div=
><div><br></div><div><b> enum class B : A {};</b></div><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Can B do ever=
ything that A could do? </div></div></blockquote><div><br></div><div>No. It=
 can be explicitly convertible to and from <b>A</b> (with and without varia=
ble numbers of ampersands, but I haven&#39;t thought it through) If A is li=
teral, you can define named constants of type B. You can add also add membe=
r non-variables.</div><div>=C2=A0 <br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div>For example, if A was Swappable, that m=
eans A probably has a non-member `swap` function. </div></div></blockquote>=
<div><br></div><div><b>enum class B : A {</b></div><div><b>public :</b></di=
v><div><b>=C2=A0 friend void swap(B&amp;, B&amp;) =3D default;<br></b></div=
><div><b>};</b></div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div>Does B automatically get one?</div></div></bloc=
kquote><div><br></div><div>No.</div><div> <br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><div> Should it? </div></div></block=
quote><div><br></div><div>No.</div><div> <br></div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr"><div>If A was addable to integers via=
 non-member `operator+`, should B be addable too?</div><div><br></div></div=
></blockquote><div>No, but :</div><div><br> </div><div><div><b>enum class B=
 : A {</b></div><div><b>public :</b></div><div><b>=C2=A0 friend B operator+=
(const B&amp;, int) =3D default;<br></b></div><div><b>};</b></div><div><br>=
</div></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div></div><div>And if you can&#39;t automatically get the non-member interf=
aces of A, then what good is B?</div></div></blockquote><div>=C2=A0</div><d=
iv>B is a distinct type from A, explicitly convertible to and from it. B is=
 stored the same way as A. It is as copyable, movable, assignable and destr=
uctible as A, except the signatures get B in lieu of A.<br></div><div><br><=
/div><div>You can&#39;t even have them non-automatically in C++17, since yo=
u can&#39;t define B if A is not an integral type.</div><div><br></div><div=
>A question for you : if using enum class for creating strong aliases of in=
tegral types in C++17 is a mistake, how do you create strong aliases of int=
egral types in C++17?<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/2667d45a-3db6-4994-ac1f-e8c2880700c8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2667d45a-3db6-4994-ac1f-e8c2880700c8=
%40isocpp.org</a>.<br />

------=_Part_5489_524707835.1514048142335--

------=_Part_5488_1234003181.1514048142335--

.

------=_Part_10967_714264682.1514049280119
Content-Type: multipart/alternative;
 boundary="----=_Part_10968_1908959332.1514049280120"

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

On Saturday, December 23, 2017 at 11:55:42 AM UTC-5, Laurent LA RIZZA wrote=
:
>
>
>
> Le samedi 23 d=C3=A9cembre 2017 16:37:41 UTC+1, Nicol Bolas a =C3=A9crit =
:
> =20
>
>> Can we fix construction please?" Was adoption a mistake? Maybe, I don't=
=20
>>> know.
>>>
>>
>> Yes, that was exactly what I was referring to, and yes, *it was a=20
>> mistake*.
>>
>> I still don't know, that does not change the fact that even before that=
=20
> "mistake", people were using *enum class* to create strong typedefs of=20
> integral types.
>

People also used template instantiation to do compile-time computations.=20
C++ programmers are willing to use any feature for any purpose, so long as=
=20
it works. That doesn't mean we should enshrine it as the right idea. If=20
people want to do compile-time computations, we should give them functions=
=20
that run at compile-time, not make them jump through hoops of type=20
instantiation and so forth.

You're basically saying, "we have template metaprogramming; why not add=20
more to that, instead of bothering with this whole `constexpr` function=20
thing?" Or "we have SFINAE; why not add more to that, instead of bothering=
=20
with this whole `requires` thing?"

We have strong typedefs in C++17.
>

No, we have* hacks* in C++17.

This is my point. People already create strong typedefs of integral types=
=20
>>> using *enum class*. I also do. Get over it. We have strong typedefs.
>>>
>>
>> Compounding a mistake with another mistake is absurd.
>>
>
> Same answer. Adoption of P0138R2 is irrelevant to my-mine-and-only-of-me=
=20
> statement that we have strong typedefs in C++17. It being a mistake is yo=
ur=20
> opinion, not a fact.
>

If you weren't interested in the opinions of others, I don't know why you=
=20
felt the need to post here.


>>
>>> Can you please elaborate the use cases you think of where you would wan=
t=20
>>> other aliasing strength than the binary "they're the same type/they're =
not=20
>>> the same type"?
>>>
>>
>> Go read every strong typedef proposal that has ever been proposed. They=
=20
>> do a good job of covering the myriad of possible ways people want to dea=
l=20
>> with such things.
>>
>
> I have done (a long time ago), and will do again. I thank you for=20
> expressing your opinions on my ideas.=20
>
>>
>> However, as a simple example, let's say you have a class A, and you make=
=20
>> a strong typedef of it called B.
>>
>
> OK, so :
>
> * enum class B : A {};*
>
> Can B do everything that A could do?=20
>>
>
> No. It can be explicitly convertible to and from *A* (with and without=20
> variable numbers of ampersands, but I haven't thought it through) If A is=
=20
> literal, you can define named constants of type B. You can add also add=
=20
> member non-variables.
>  =20
>
>> For example, if A was Swappable, that means A probably has a non-member=
=20
>> `swap` function.=20
>>
>
> *enum class B : A {*
> *public :*
>
> *  friend void swap(B&, B&) =3D default;*
> *};*
>
> Does B automatically get one?
>>
>
> No.
>
> Should it?=20
>>
>
> No.
>
> If A was addable to integers via non-member `operator+`, should B be=20
>> addable too?
>>
>> No, but :
>
> *enum class B : A {*
> *public :*
>
> *  friend B operator+(const B&, int) =3D default;*
> *};*
>
> And if you can't automatically get the non-member interfaces of A, then=
=20
>> what good is B?
>>
> =20
> B is a distinct type from A, explicitly convertible to and from it. B is=
=20
> stored the same way as A. It is as copyable, movable, assignable and=20
> destructible as A, except the signatures get B in lieu of A.
>

But it's not actually an alias of `A`, since it cannot do what `A` does.

My point is that C++ has no mechanism to identify free functions that are a=
=20
fundamental part of a class's interface from free functions which are not.=
=20
And without that, making proper strong aliases becomes a maintenance=20
burden. If someone adds a new free function interface to A, you have to add=
=20
a `friend` declaration to* every* strong alias of it in order to pick up=20
that behavior.

My* other* point is that you're spending way too much time on the syntax=20
(insisting on overloading "enum class" for things that aren't enumerators)=
=20
and not enough on the *actually useful* parts of the feature. For example,=
=20
this is the first thing you've mentioned about this `=3D default` syntax fo=
r=20
inheriting functionality from the class being aliased. That's a *really=20
important* part of the proposal, and yet you didn't even mention that in=20
your initial post, instead spending time trying to justify "enum class" as=
=20
the correct induction syntax.

Why do you care so much that it gets called "enum class" instead of, like,*=
=20
anything else*?

You can't even have them non-automatically in C++17, since you can't define=
=20
> B if A is not an integral type.
>
> A question for you : if using enum class for creating strong aliases of=
=20
> integral types in C++17 is a mistake, how do you create strong aliases of=
=20
> integral types in C++17?
>

The same way I did in C++14: with an actual class. It's verbose, but at=20
least it isn't stupid looking and confusing.

--=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/1af8df58-c309-4404-9428-eefd9aa92a81%40isocpp.or=
g.

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

<div dir=3D"ltr">On Saturday, December 23, 2017 at 11:55:42 AM UTC-5, Laure=
nt LA RIZZA wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><br><br>Le samedi 23 d=C3=A9cembre 2017 16:37:41 UTC+1, Nicol Bolas a =
=C3=A9crit=C2=A0:<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><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"ltr">=
<div>Can we fix construction please?&quot; Was adoption a mistake? Maybe, I=
 don&#39;t know.</div></div></blockquote><div><br></div><div>Yes, that was =
exactly what I was referring to, and yes, <i>it was a mistake</i>.</div><di=
v><br></div></div></blockquote><div>I still don&#39;t know, that does not c=
hange the fact that even before that &quot;mistake&quot;, people were using=
 <i>enum class</i> to create strong typedefs of integral types.</div></div>=
</blockquote><div><br></div><div>People also used template instantiation to=
 do compile-time computations. C++ programmers are willing to use any featu=
re for any purpose, so long as it works. That doesn&#39;t mean we should en=
shrine it as the right idea. If people want to do compile-time computations=
, we should give them functions that run at compile-time, not make them jum=
p through hoops of type instantiation and so forth.</div><div><br></div><di=
v>You&#39;re basically saying, &quot;we have template metaprogramming; why =
not add more to that, instead of bothering with this whole `constexpr` func=
tion thing?&quot; Or &quot;we have SFINAE; why not add more to that, instea=
d of bothering with this whole `requires` thing?&quot;</div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>We have =
strong typedefs in C++17.</div></div></blockquote><div><br></div><div>No, w=
e have<i> hacks</i> in C++17.</div><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div>This is my point. People already create strong typedefs of=
 integral types using <i>enum class</i>. I also do. Get over it. We have st=
rong typedefs.<br></div></div></blockquote><div><br></div><div>Compounding =
a mistake with another mistake is absurd.</div></div></blockquote><div><br>=
</div><div>Same answer. Adoption of P0138R2 is irrelevant to my-mine-and-on=
ly-of-me statement that we have strong typedefs in C++17. It being a mistak=
e is your opinion, not a fact.<br></div></div></blockquote><div><br></div><=
div>If you weren&#39;t interested in the opinions of others, I don&#39;t kn=
ow why you felt the need to post here.</div><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><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"><div><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div></div><div> </div><div></div><br>=
<div>Can you please elaborate the use cases you think of where you would wa=
nt other aliasing strength than the binary &quot;they&#39;re the same type/=
they&#39;re not the same type&quot;?<br></div></div></blockquote><div><br><=
/div><div>Go read every strong typedef proposal that has ever been proposed=
.. They do a good job of covering the myriad of possible ways people want to=
 deal with such things.</div></div></blockquote><div><br></div><div>I have =
done (a long time ago), and will do again. I thank you for expressing your =
opinions on my ideas. <br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div><br></div><div>However, as a simple example, let&#39;s s=
ay you have a class A, and you make a strong typedef of it called B.</div><=
/div></blockquote><div><br></div><div>OK, so :</div><div><br></div><div><b>=
 enum class B : A {};</b></div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div>Can B do everything that A could do? </div=
></div></blockquote><div><br></div><div>No. It can be explicitly convertibl=
e to and from <b>A</b> (with and without variable numbers of ampersands, bu=
t I haven&#39;t thought it through) If A is literal, you can define named c=
onstants of type B. You can add also add member non-variables.</div><div>=
=C2=A0 <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><=
div>For example, if A was Swappable, that means A probably has a non-member=
 `swap` function. </div></div></blockquote><div><br></div><div><b>enum clas=
s B : A {</b></div><div><b>public :</b></div><div><b>=C2=A0 friend void swa=
p(B&amp;, B&amp;) =3D default;<br></b></div><div><b>};</b></div><div><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Does B au=
tomatically get one?</div></div></blockquote><div><br></div><div>No.</div><=
div> <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v> Should it? </div></div></blockquote><div><br></div><div>No.</div><div> <=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>If A=
 was addable to integers via non-member `operator+`, should B be addable to=
o?</div><div><br></div></div></blockquote><div>No, but :</div><div><br> </d=
iv><div><div><b>enum class B : A {</b></div><div><b>public :</b></div><div>=
<b>=C2=A0 friend B operator+(const B&amp;, int) =3D default;<br></b></div><=
div><b>};</b></div><div><br></div></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div></div><div>And if you can&#39;t automatically ge=
t the non-member interfaces of A, then what good is B?</div></div></blockqu=
ote><div>=C2=A0</div><div>B is a distinct type from A, explicitly convertib=
le to and from it. B is stored the same way as A. It is as copyable, movabl=
e, assignable and destructible as A, except the signatures get B in lieu of=
 A.<br></div></div></blockquote><div><br></div><div>But it&#39;s not actual=
ly an alias of `A`, since it cannot do what `A` does.</div><div><br></div><=
div>My point is that C++ has no mechanism to identify free functions that a=
re a fundamental part of a class&#39;s interface from free functions which =
are not. And without that, making proper strong aliases becomes a maintenan=
ce burden. If someone adds a new free function interface to A, you have to =
add a `friend` declaration to<i> every</i> strong alias of it in order to p=
ick up that behavior.</div><div><i><br></i></div><div>My<i> other</i> point=
 is that you&#39;re spending way too much time on the syntax (insisting on =
overloading &quot;enum class&quot; for things that aren&#39;t enumerators) =
and not enough on the <i>actually useful</i> parts of the feature. For exam=
ple, this is the first thing you&#39;ve mentioned about this `=3D default` =
syntax for inheriting functionality from the class being aliased. That&#39;=
s a <i>really important</i> part of the proposal, and yet you didn&#39;t ev=
en mention that in your initial post, instead spending time trying to justi=
fy &quot;enum class&quot; as the correct induction syntax.</div><div><br></=
div><div>Why do you care so much that it gets called &quot;enum class&quot;=
 instead of, like,<i> anything else</i>?</div><div><i><br></i></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>You =
can&#39;t even have them non-automatically in C++17, since you can&#39;t de=
fine B if A is not an integral type.</div><div><br></div><div>A question fo=
r you : if using enum class for creating strong aliases of integral types i=
n C++17 is a mistake, how do you create strong aliases of integral types in=
 C++17?<br></div></div></blockquote><div><br></div><div>The same way I did =
in C++14: with an actual class. It&#39;s verbose, but at least it isn&#39;t=
 stupid looking and confusing.</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/1af8df58-c309-4404-9428-eefd9aa92a81%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1af8df58-c309-4404-9428-eefd9aa92a81=
%40isocpp.org</a>.<br />

------=_Part_10968_1908959332.1514049280120--

------=_Part_10967_714264682.1514049280119--

.

------=_Part_11033_594033150.1514049316126
Content-Type: multipart/alternative;
 boundary="----=_Part_11034_1984459731.1514049316126"

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



Le samedi 23 d=C3=A9cembre 2017 17:52:12 UTC+1, Richard Smith a =C3=A9crit =
:
>
> On 23 December 2017 at 09:55, Laurent LA RIZZA <the.ultim...@gmail.com=20
> <javascript:>> wrote:
>
>>
>>
>> This is my point. People already create strong typedefs of integral type=
s=20
>> using *enum class*. I also do. Get over it. We have strong typedefs.=20
>>
>
> We don't have good ones, though;=20
>

That's what I said in my OP. I claim that we have them, but they suck in=20
two specific ways. That's why I proposed to fix them.

look at the library portion of the <=3D> design (particularly, p0515r3=20
> section 3) for an example of what we're missing. "enum class" was=20
> considered as a way of making std::strong_ordering and friends be strong=
=20
> typedefs for int, but they don't work. In that particular case the proble=
m=20
> is that we wish to permit certain kinds of conversion between=20
> std::strong_ordering and its related classes, but that is not possible wh=
en=20
> using enum class to define a "strong typedef".
>
>>
>> ... in C++17. Now, with what I propose, conversions would look like this=
 :

enum class strong_equality : int {
  equal =3D 0,
  equivalent =3D equal,
  nonequal =3D 1,
  nonequivalent =3D nonequal;
public:
  operator weak_equality(strong_equality se) const {
    return (weak_equality)(int)se;
  }
};

And M. Smith, you might be the appropriate person to tell me whether the #2=
=20
rough outline in my OP is feasible (or specific reasons for which it is=20
not). Can you please have a look?

--=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/71ffc937-0268-43d4-a60a-5a566f269d56%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>Le samedi 23 d=C3=A9cembre 2017 17:52:12 UTC+1, Ri=
chard Smith a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div><div class=3D"gmail_quote">On 23 December 2017 at 09=
:55, Laurent LA RIZZA <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"Un0jSD6zBwAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;">the.ultim...@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"=
ltr"><br><div><br></div><div>This is my point. People already create strong=
 typedefs of integral types using <i>enum class</i>. I also do. Get over it=
.. We have strong typedefs.=C2=A0</div></div></blockquote><div><br></div><di=
v>We don&#39;t have good ones, though; </div></div></div></div></blockquote=
><div><br></div><div>That&#39;s what I said in my OP. I claim that we have =
them, but they suck in two specific ways. That&#39;s why I proposed to fix =
them.</div><div> <br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote"><div>look at the library port=
ion of the &lt;=3D&gt; design (particularly, p0515r3 section 3) for an exam=
ple of what we&#39;re missing. &quot;enum class&quot; was considered as a w=
ay of making std::strong_ordering and friends be strong typedefs for int, b=
ut they don&#39;t work. In that particular case the problem is that we wish=
 to permit certain kinds of conversion between std::strong_ordering and its=
 related classes, but that is not possible when using enum class to define =
a &quot;strong typedef&quot;.</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><br></blockquote></div></div></div></blockquote><div>... in C++1=
7. Now, with what I propose, conversions would look like this :</div><div><=
br></div><div>enum class strong_equality : int {</div><div>=C2=A0 equal =3D=
 0,</div><div>=C2=A0 equivalent =3D equal,</div><div>=C2=A0 nonequal =3D 1,=
</div><div>=C2=A0 nonequivalent =3D nonequal;</div><div>public:</div><div>=
=C2=A0 operator weak_equality(strong_equality se) const {</div><div>=C2=A0=
=C2=A0=C2=A0 return (weak_equality)(int)se;<br></div><div>=C2=A0 }<br></div=
><div>};</div><div><br></div><div>And M. Smith, you might be the appropriat=
e person to tell me whether the #2 rough outline in my OP is feasible (or s=
pecific reasons for which it is not). Can you please have a look?<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/71ffc937-0268-43d4-a60a-5a566f269d56%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/71ffc937-0268-43d4-a60a-5a566f269d56=
%40isocpp.org</a>.<br />

------=_Part_11034_1984459731.1514049316126--

------=_Part_11033_594033150.1514049316126--

.

------=_Part_5251_1053855762.1514050046774
Content-Type: multipart/alternative;
 boundary="----=_Part_5252_1679963327.1514050046774"

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



On Saturday, December 23, 2017 at 12:15:16 PM UTC-5, Laurent LA RIZZA wrote=
:
>
>
>
> Le samedi 23 d=C3=A9cembre 2017 17:52:12 UTC+1, Richard Smith a =C3=A9cri=
t :
>>
>> On 23 December 2017 at 09:55, Laurent LA RIZZA <the.ultim...@gmail.com>=
=20
>> wrote:
>>
>>>
>>>
>>> This is my point. People already create strong typedefs of integral=20
>>> types using *enum class*. I also do. Get over it. We have strong=20
>>> typedefs.=20
>>>
>>
>> We don't have good ones, though;=20
>>
>
> That's what I said in my OP. I claim that we have them, but they suck in=
=20
> two specific ways. That's why I proposed to fix them.
>
> look at the library portion of the <=3D> design (particularly, p0515r3=20
>> section 3) for an example of what we're missing. "enum class" was=20
>> considered as a way of making std::strong_ordering and friends be strong=
=20
>> typedefs for int, but they don't work. In that particular case the probl=
em=20
>> is that we wish to permit certain kinds of conversion between=20
>> std::strong_ordering and its related classes, but that is not possible w=
hen=20
>> using enum class to define a "strong typedef".
>>
>>>
>>> ... in C++17. Now, with what I propose, conversions would look like thi=
s=20
> :
>
> enum class strong_equality : int {
>   equal =3D 0,
>   equivalent =3D equal,
>   nonequal =3D 1,
>   nonequivalent =3D nonequal;
> public:
>   operator weak_equality(strong_equality se) const {
>     return (weak_equality)(int)se;
>   }
> };
>

I don't see how that's an improvement over what we got in the standard:

class strong_equality
{
  int value;

  strong_equality(int val) : value{val} {}

public:
  constexpr static strong_equality equal =3D {0};
  constexpr static strong_equality equivalent =3D equal;
  constexpr static strong_equality nonequal =3D {1};
  constexpr static strong_equality nonequivalent =3D nonequal;

  operator weak_equality() const {
    return weak_equality{value};
  }
};

Sure, it's shorter... slightly. But it's a lot more explicit about what=20
it's doing. It does not at any point pretend that it is an enumeration.=20
Which is kind of important; in your case, `is_enum_v<strong_equality>` is=
=20
true; in my case, it is not.

And M. Smith, you might be the appropriate person to tell me whether the #2=
=20
> rough outline in my OP is feasible (or specific reasons for which it is=
=20
> not).
>

It's not. You cannot take an entire primary classification of types and=20
make them something else. Enumerators are a distinct set of types from=20
class types, fundamental types, and so forth. Making them into class types=
=20
is not a viable process at this point; it'd require too many changes and=20
may not even be backwards compatible.
=20

> Can you please have a look?
>

--=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/51eb7a52-b605-411c-8817-048e9e37a8ec%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Saturday, December 23, 2017 at 12:15:16 PM UTC-=
5, Laurent LA RIZZA wrote:<blockquote 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>Le samedi 23 d=C3=A9cembre 2017 17:52:12 UTC+1, Richar=
d Smith a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote">On 23 December 2017 at 09:55, Laur=
ent LA RIZZA <span dir=3D"ltr">&lt;<a rel=3D"nofollow">the.ultim...@gmail.c=
om</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr"><br><div><br></div><div>This is my point. People alread=
y create strong typedefs of integral types using <i>enum class</i>. I also =
do. Get over it. We have strong typedefs.=C2=A0</div></div></blockquote><di=
v><br></div><div>We don&#39;t have good ones, though; </div></div></div></d=
iv></blockquote><div><br></div><div>That&#39;s what I said in my OP. I clai=
m that we have them, but they suck in two specific ways. That&#39;s why I p=
roposed to fix them.</div><div> <br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>look at the li=
brary portion of the &lt;=3D&gt; design (particularly, p0515r3 section 3) f=
or an example of what we&#39;re missing. &quot;enum class&quot; was conside=
red as a way of making std::strong_ordering and friends be strong typedefs =
for int, but they don&#39;t work. In that particular case the problem is th=
at we wish to permit certain kinds of conversion between std::strong_orderi=
ng and its related classes, but that is not possible when using enum class =
to define a &quot;strong typedef&quot;.</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><br></blockquote></div></div></div></blockquote><div>..=
.. in C++17. Now, with what I propose, conversions would look like this :</d=
iv><div><br></div><div>enum class strong_equality : int {</div><div>=C2=A0 =
equal =3D 0,</div><div>=C2=A0 equivalent =3D equal,</div><div>=C2=A0 nonequ=
al =3D 1,</div><div>=C2=A0 nonequivalent =3D nonequal;</div><div>public:</d=
iv><div>=C2=A0 operator weak_equality(strong_equality se) const {</div><div=
>=C2=A0=C2=A0=C2=A0 return (weak_equality)(int)se;<br></div><div>=C2=A0 }<b=
r></div><div>};</div></div></blockquote><div><br></div><div>I don&#39;t see=
 how that&#39;s an improvement over what we got in the standard:</div><div>=
<br></div><div>class strong_equality</div><div>{</div><div>=C2=A0 int value=
;</div><div><br></div><div>=C2=A0 strong_equality(int val) : value{val} {}<=
/div><div><br></div><div>public:</div><div><div style=3D"background-color: =
transparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: non=
e; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: s=
tretch; border-image-slice: 100%; border-image-source: none; border-image-w=
idth: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; borde=
r-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style:=
 none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-t=
op-style: none; border-top-width: 0px; color: rgb(34, 34, 34); font-family:=
 &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-s=
ize: 13px; font-style: normal; font-variant: normal; font-weight: 400; lett=
er-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px=
; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padd=
ing-right: 0px; padding-top: 0px; text-align: left; text-decoration: none; =
text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; whi=
te-space: normal; word-spacing: 0px;">=C2=A0 constexpr static strong_equali=
ty=C2=A0<span style=3D"background-color: transparent; border-bottom-color: =
rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; borde=
r-image-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; =
border-image-source: none; border-image-width: 1; border-left-color: rgb(34=
, 34, 34); border-left-style: none; border-left-width: 0px; border-right-co=
lor: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; bo=
rder-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: =
0px; color: rgb(34, 34, 34); display: inline; float: none; font-family: &am=
p;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size:=
 13px; font-style: normal; font-variant: normal; font-weight: 400; letter-s=
pacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; ma=
rgin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-=
right: 0px; padding-top: 0px; text-align: left; text-decoration: none; text=
-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-s=
pace: normal; word-spacing: 0px;">equal =3D {0};</span></div><div style=3D"=
background-color: transparent; border-bottom-color: rgb(34, 34, 34); border=
-bottom-style: none; border-bottom-width: 0px; border-image-outset: 0; bord=
er-image-repeat: stretch; border-image-slice: 100%; border-image-source: no=
ne; border-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-=
style: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34); b=
order-right-style: none; border-right-width: 0px; border-top-color: rgb(34,=
 34, 34); border-top-style: none; border-top-width: 0px; color: rgb(34, 34,=
 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,=
sans-serif; font-size: 13px; font-style: normal; font-variant: normal; font=
-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px;=
 margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; paddi=
ng-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; text-=
decoration: none; text-indent: 0px; text-transform: none; -webkit-text-stro=
ke-width: 0px; white-space: normal; word-spacing: 0px;">=C2=A0 constexpr st=
atic strong_equality=C2=A0<span style=3D"display: inline !important; float:=
 none; background-color: transparent; color: rgb(34, 34, 34); font-family: =
&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-s=
tyle: normal; font-variant: normal; font-weight: 400; letter-spacing: norma=
l; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px; t=
ext-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; w=
ord-spacing: 0px;">equivalent </span><span style=3D"background-color: trans=
parent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; bo=
rder-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stretc=
h; border-image-slice: 100%; border-image-source: none; border-image-width:=
 1; border-left-color: rgb(34, 34, 34); border-left-style: none; border-lef=
t-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: none=
; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-st=
yle: none; border-top-width: 0px; color: rgb(34, 34, 34); display: inline; =
float: none; font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp=
;quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: norma=
l; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-lef=
t: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px=
; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left=
; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-te=
xt-stroke-width: 0px; white-space: normal; word-spacing: 0px;">=3D equal;</=
span></div><div style=3D"margin: 0px; padding: 0px; border: 0px rgb(34, 34,=
 34); border-image: none; text-align: left; color: rgb(34, 34, 34); text-tr=
ansform: none; text-indent: 0px; letter-spacing: normal; font-size: 13px; f=
ont-variant: normal; word-spacing: 0px; white-space: normal; orphans: 2; -w=
ebkit-text-stroke-width: 0px; background-color: transparent;"><div style=3D=
"background-color: transparent; border-bottom-color: rgb(34, 34, 34); borde=
r-bottom-style: none; border-bottom-width: 0px; border-image-outset: 0; bor=
der-image-repeat: stretch; border-image-slice: 100%; border-image-source: n=
one; border-image-width: 1; border-left-color: rgb(34, 34, 34); border-left=
-style: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34); =
border-right-style: none; border-right-width: 0px; border-top-color: rgb(34=
, 34, 34); border-top-style: none; border-top-width: 0px; color: rgb(34, 34=
, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;=
,sans-serif; font-size: 13px; font-style: normal; font-variant: normal; fon=
t-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px=
; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; padd=
ing-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; text=
-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-str=
oke-width: 0px; white-space: normal; word-spacing: 0px;">=C2=A0 constexpr s=
tatic strong_equality=C2=A0<span style=3D"display: inline !important; float=
: none; background-color: transparent; color: rgb(34, 34, 34); font-family:=
 &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-=
style: normal; font-variant: normal; font-weight: 400; letter-spacing: norm=
al; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px; =
text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; =
word-spacing: 0px;">nonequal </span><span style=3D"background-color: transp=
arent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; bor=
der-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stretch=
; border-image-slice: 100%; border-image-source: none; border-image-width: =
1; border-left-color: rgb(34, 34, 34); border-left-style: none; border-left=
-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: none;=
 border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-sty=
le: none; border-top-width: 0px; color: rgb(34, 34, 34); display: inline; f=
loat: none; font-size: 13px; font-style: normal; font-variant: normal; font=
-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px;=
 margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; paddi=
ng-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; text-=
decoration: none; text-indent: 0px; text-transform: none; -webkit-text-stro=
ke-width: 0px; white-space: normal; word-spacing: 0px;">=3D {1};</span></di=
v><div style=3D"background-color: transparent; border-bottom-color: rgb(34,=
 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-image=
-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; border-=
image-source: none; border-image-width: 1; border-left-color: rgb(34, 34, 3=
4); border-left-style: none; border-left-width: 0px; border-right-color: rg=
b(34, 34, 34); border-right-style: none; border-right-width: 0px; border-to=
p-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; co=
lor: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helv=
etica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-varia=
nt: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; m=
argin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bo=
ttom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-al=
ign: left; text-decoration: none; text-indent: 0px; text-transform: none; -=
webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">=C2=
=A0 constexpr static strong_equality=C2=A0<span style=3D"display: inline !i=
mportant; float: none; background-color: transparent; color: rgb(34, 34, 34=
); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-si=
ze: 13px; font-style: normal; font-variant: normal; font-weight: 400; lette=
r-spacing: normal; orphans: 2; text-align: left; text-decoration: none; tex=
t-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-=
space: normal; word-spacing: 0px;">nonequivalent </span><span style=3D"back=
ground-color: transparent; border-bottom-color: rgb(34, 34, 34); border-bot=
tom-style: none; border-bottom-width: 0px; border-image-outset: 0; border-i=
mage-repeat: stretch; border-image-slice: 100%; border-image-source: none; =
border-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-styl=
e: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34); borde=
r-right-style: none; border-right-width: 0px; border-top-color: rgb(34, 34,=
 34); border-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34)=
; display: inline; float: none; font-size: 13px; font-style: normal; font-v=
ariant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0p=
x; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; paddin=
g-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; tex=
t-align: left; text-decoration: none; text-indent: 0px; text-transform: non=
e; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"=
>=3D nonequal;</span></div><div style=3D"background-color: transparent; bor=
der-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom=
-width: 0px; border-image-outset: 0; border-image-repeat: stretch; border-i=
mage-slice: 100%; border-image-source: none; border-image-width: 1; border-=
left-color: rgb(34, 34, 34); border-left-style: none; border-left-width: 0p=
x; border-right-color: rgb(34, 34, 34); border-right-style: none; border-ri=
ght-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; =
border-top-width: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial=
&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-=
style: normal; font-variant: normal; font-weight: 400; letter-spacing: norm=
al; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0p=
x; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; =
padding-top: 0px; text-align: left; text-decoration: none; text-indent: 0px=
; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal=
; word-spacing: 0px;"><span style=3D"background-color: transparent; border-=
bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-wid=
th: 0px; border-image-outset: 0; border-image-repeat: stretch; border-image=
-slice: 100%; border-image-source: none; border-image-width: 1; border-left=
-color: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; b=
order-right-color: rgb(34, 34, 34); border-right-style: none; border-right-=
width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; bord=
er-top-width: 0px; color: rgb(34, 34, 34); display: inline; float: none; fo=
nt-size: 13px; font-style: normal; font-variant: normal; font-weight: 400; =
letter-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right:=
 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; =
padding-right: 0px; padding-top: 0px; text-align: left; text-decoration: no=
ne; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px;=
 white-space: normal; word-spacing: 0px;"><br></span></div><div style=3D"ma=
rgin: 0px; padding: 0px; border: 0px rgb(34, 34, 34); border-image: none; t=
ext-align: left; color: rgb(34, 34, 34); text-transform: none; text-indent:=
 0px; letter-spacing: normal; font-size: 13px; font-variant: normal; word-s=
pacing: 0px; white-space: normal; orphans: 2; -webkit-text-stroke-width: 0p=
x; background-color: transparent;"><span style=3D"margin: 0px; padding: 0px=
; border: 0px rgb(34, 34, 34); border-image: none; text-align: left; color:=
 rgb(34, 34, 34); text-transform: none; text-indent: 0px; letter-spacing: n=
ormal; font-size: 13px; font-variant: normal; word-spacing: 0px; display: i=
nline; white-space: normal; orphans: 2; float: none; -webkit-text-stroke-wi=
dth: 0px; background-color: transparent;"><div style=3D"background-color: t=
ransparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none=
; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: st=
retch; border-image-slice: 100%; border-image-source: none; border-image-wi=
dth: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; border=
-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: =
none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-to=
p-style: none; border-top-width: 0px; color: rgb(34, 34, 34); font-family: =
&amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-si=
ze: 13px; font-style: normal; font-variant: normal; font-weight: 400; lette=
r-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px;=
 margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; paddi=
ng-right: 0px; padding-top: 0px; text-align: left; text-decoration: none; t=
ext-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; whit=
e-space: normal; word-spacing: 0px;">=C2=A0 operator weak_equality() const =
{</div><div style=3D"background-color: transparent; border-bottom-color: rg=
b(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-=
image-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; bo=
rder-image-source: none; border-image-width: 1; border-left-color: rgb(34, =
34, 34); border-left-style: none; border-left-width: 0px; border-right-colo=
r: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; bord=
er-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0p=
x; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot=
;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-=
variant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0=
px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; paddi=
ng-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; te=
xt-align: left; text-decoration: none; text-indent: 0px; text-transform: no=
ne; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;=
">=C2=A0=C2=A0=C2=A0 return weak_equality{value};<br style=3D"background-at=
tachment: scroll; background-clip: border-box; background-color: transparen=
t; background-image: none; background-origin: padding-box; background-posit=
ion-x: 0%; background-position-y: 0%; background-repeat: repeat; background=
-size: auto; border-bottom-color: rgb(34, 34, 34); border-bottom-style: non=
e; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: s=
tretch; border-image-slice: 100%; border-image-source: none; border-image-w=
idth: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; borde=
r-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style:=
 none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-t=
op-style: none; border-top-width: 0px; color: rgb(34, 34, 34); font-family:=
 &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-s=
ize: 13px; height: auto; margin-bottom: 0px; margin-left: 0px; margin-right=
: 0px; margin-top: 0px; min-width: 0px; overflow: visible; overflow-x: visi=
ble; overflow-y: visible; padding-bottom: 0px; padding-left: 0px; padding-r=
ight: 0px; padding-top: 0px;"></div><div style=3D"background-color: transpa=
rent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; bord=
er-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stretch;=
 border-image-slice: 100%; border-image-source: none; border-image-width: 1=
; border-left-color: rgb(34, 34, 34); border-left-style: none; border-left-=
width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: none; =
border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-styl=
e: none; border-top-width: 0px; color: rgb(34, 34, 34); font-family: &amp;q=
uot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13=
px; font-style: normal; font-variant: normal; font-weight: 400; letter-spac=
ing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margi=
n-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-rig=
ht: 0px; padding-top: 0px; text-align: left; text-decoration: none; text-in=
dent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-spac=
e: normal; word-spacing: 0px;">=C2=A0 }<br style=3D"background-attachment: =
scroll; background-clip: border-box; background-color: transparent; backgro=
und-image: none; background-origin: padding-box; background-position-x: 0%;=
 background-position-y: 0%; background-repeat: repeat; background-size: aut=
o; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-=
bottom-width: 0px; border-image-outset: 0; border-image-repeat: stretch; bo=
rder-image-slice: 100%; border-image-source: none; border-image-width: 1; b=
order-left-color: rgb(34, 34, 34); border-left-style: none; border-left-wid=
th: 0px; border-right-color: rgb(34, 34, 34); border-right-style: none; bor=
der-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: =
none; border-top-width: 0px; color: rgb(34, 34, 34); font-family: &amp;quot=
;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px;=
 height: auto; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; mar=
gin-top: 0px; min-width: 0px; overflow: visible; overflow-x: visible; overf=
low-y: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px;=
 padding-top: 0px;"></div></span></div>};</div><div style=3D"margin: 0px; p=
adding: 0px; border: 0px rgb(34, 34, 34); border-image: none; text-align: l=
eft; color: rgb(34, 34, 34); text-transform: none; text-indent: 0px; letter=
-spacing: normal; font-size: 13px; font-variant: normal; word-spacing: 0px;=
 white-space: normal; orphans: 2; -webkit-text-stroke-width: 0px; backgroun=
d-color: transparent;"><br></div><div style=3D"margin: 0px; padding: 0px; b=
order: 0px rgb(34, 34, 34); border-image: none; text-align: left; color: rg=
b(34, 34, 34); text-transform: none; text-indent: 0px; letter-spacing: norm=
al; font-size: 13px; font-variant: normal; word-spacing: 0px; white-space: =
normal; orphans: 2; -webkit-text-stroke-width: 0px; background-color: trans=
parent;">Sure, it&#39;s shorter... slightly. But it&#39;s a lot more explic=
it about what it&#39;s doing. It does not at any point pretend that it is a=
n enumeration. Which is kind of important; in your case, `is_enum_v&lt;stro=
ng_equality&gt;` is true; in my case, it is not.</div></div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>And M. S=
mith, you might be the appropriate person to tell me whether the #2 rough o=
utline in my OP is feasible (or specific reasons for which it is not).</div=
></div></blockquote><div><br></div><div>It&#39;s not. You cannot take an en=
tire primary classification of types and make them something else. Enumerat=
ors are a distinct set of types from class types, fundamental types, and so=
 forth. Making them into class types is not a viable process at this point;=
 it&#39;d require too many changes and may not even be backwards compatible=
..</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div>Can you please have a look?<br></div></div></blockquote></d=
iv>

<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/51eb7a52-b605-411c-8817-048e9e37a8ec%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/51eb7a52-b605-411c-8817-048e9e37a8ec=
%40isocpp.org</a>.<br />

------=_Part_5252_1679963327.1514050046774--

------=_Part_5251_1053855762.1514050046774--

.

------=_Part_11051_1124818031.1514053135502
Content-Type: multipart/alternative;
 boundary="----=_Part_11052_1426134613.1514053135502"

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



Le samedi 23 d=C3=A9cembre 2017 18:27:26 UTC+1, Nicol Bolas a =C3=A9crit :
>
> in your case, `is_enum_v<strong_equality>` is true; in my case, it is not=
..
>
>
That is entirely true. But I think I invalidated the stated reason why enum=
=20
class was not used to create a strong typedefs in this paper.


> You cannot take an entire primary classification of types and make them=
=20
> something else. Enumerators are a distinct set of types from class types,=
=20
> fundamental types, and so forth.=20
>

Yes. At step 9 of my recipe, they still are. I'm just trying to have=20
class/struct/unions parsed uniformly, to make it easier to add missing=20
features on both sides.

--=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/0ae954e2-5405-4246-92a0-663d2bf1cd18%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>Le samedi 23 d=C3=A9cembre 2017 18:27:26 UTC+1, Ni=
col Bolas a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div style=3D"margin:0px;padding:0px;border:0px rgb(34,34,3=
4);text-align:left;color:rgb(34,34,34);text-transform:none;text-indent:0px;=
letter-spacing:normal;font-size:13px;font-variant:normal;word-spacing:0px;w=
hite-space:normal;background-color:transparent">in your case, `is_enum_v&lt=
;strong_equality&gt;` is true; in my case, it is not.</div><div><br></div><=
/div></blockquote><div><br></div><div>That is entirely true. But I think I =
invalidated the stated reason why enum class was not used to create a stron=
g typedefs in this paper.<br></div><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><div></div><br><div>You cannot take an=
 entire primary classification of types and make them something else. Enume=
rators are a distinct set of types from class types, fundamental types, and=
 so forth. </div></div></blockquote><div><br></div><div>Yes. At step 9 of m=
y recipe, they still are. I&#39;m just trying to have class/struct/unions p=
arsed uniformly, to make it easier to add missing features on both sides.</=
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/0ae954e2-5405-4246-92a0-663d2bf1cd18%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0ae954e2-5405-4246-92a0-663d2bf1cd18=
%40isocpp.org</a>.<br />

------=_Part_11052_1426134613.1514053135502--

------=_Part_11051_1124818031.1514053135502--

.

------=_Part_11119_973296637.1514056618824
Content-Type: multipart/alternative;
 boundary="----=_Part_11120_160693571.1514056618825"

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



On Saturday, December 23, 2017 at 1:18:55 PM UTC-5, Laurent LA RIZZA wrote:
>
>
>
> Le samedi 23 d=C3=A9cembre 2017 18:27:26 UTC+1, Nicol Bolas a =C3=A9crit =
:
>>
>> in your case, `is_enum_v<strong_equality>` is true; in my case, it is no=
t.
>>
>>
> That is entirely true. But I think I invalidated the stated reason why=20
> enum class was not used to create a strong typedefs in this paper.
>

.... how? `enum class`* cannot* do what you did; the standard doesn't allow=
=20
that.

Now, you can say that, if your proposal is adopted, you* could* use `enum=
=20
class` for the results of `operator<=3D>`. But until your proposal is=20
actually adopted, the reasons that `operator<=3D>` didn't use them are stil=
l=20
quite valid. So you've invalidated nothing.

And even then, your proposal isn't good enough. Why? Because=20
`strong_equality{10}` would still have to be legal code for your `enum=20
class`.

Oh, I'm sure you'll now add some syntax to your "proposal" that explicitly=
=20
disables such conversion (perhaps an `=3D delete` constructor or some such)=
..=20
But that's just another reminder that `enum class` is the* wrong tool* for=
=20
strong aliases. You're trying to hijack an existing syntax rather than*=20
creating* a good one.

There is no reason to use `enum class` for inducing a strong alias than any=
=20
other syntax.

--=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/96c8e5c9-a323-4161-8d49-894ba4ba3684%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Saturday, December 23, 2017 at 1:18:55 PM UTC-5=
, Laurent LA RIZZA wrote:<blockquote 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>Le samedi 23 d=C3=A9cembre 2017 18:27:26 UTC+1, Nicol B=
olas a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><div style=3D"margin:0px;padding:0px;border:0px rgb(34,34,34);text-al=
ign:left;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spa=
cing:normal;font-size:13px;font-variant:normal;word-spacing:0px;white-space=
:normal;background-color:transparent">in your case, `is_enum_v&lt;strong_eq=
uality&gt;` is true; in my case, it is not.</div><div><br></div></div></blo=
ckquote><div><br></div><div>That is entirely true. But I think I invalidate=
d the stated reason why enum class was not used to create a strong typedefs=
 in this paper.<br></div></div></blockquote><div><br></div><div>... how? `e=
num class`<i> cannot</i> do what you did; the standard doesn&#39;t allow th=
at.</div><div><br></div><div>Now, you can say that, if your proposal is ado=
pted, you<i> could</i> use `enum class` for the results of `operator&lt;=3D=
&gt;`. But until your proposal is actually adopted, the reasons that `opera=
tor&lt;=3D&gt;` didn&#39;t use them are still quite valid. So you&#39;ve in=
validated nothing.</div><div><br></div><div>And even then, your proposal is=
n&#39;t good enough. Why? Because `strong_equality{10}` would still have to=
 be legal code for your `enum class`.</div><div><br></div><div>Oh, I&#39;m =
sure you&#39;ll now add some syntax to your &quot;proposal&quot; that expli=
citly disables such conversion (perhaps an `=3D delete` constructor or some=
 such). But that&#39;s just another reminder that `enum class` is the<i> wr=
ong tool</i> for strong aliases. You&#39;re trying to hijack an existing sy=
ntax rather than<i> creating</i> a good one.</div><div><br></div><div>There=
 is no reason to use `enum class` for inducing a strong alias than any othe=
r syntax.</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/96c8e5c9-a323-4161-8d49-894ba4ba3684%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/96c8e5c9-a323-4161-8d49-894ba4ba3684=
%40isocpp.org</a>.<br />

------=_Part_11120_160693571.1514056618825--

------=_Part_11119_973296637.1514056618824--

.

------=_Part_11380_863580853.1514061220989
Content-Type: multipart/alternative;
 boundary="----=_Part_11381_194800073.1514061220989"

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



Le samedi 23 d=C3=A9cembre 2017 20:16:58 UTC+1, Nicol Bolas a =C3=A9crit :
>
>
>
> On Saturday, December 23, 2017 at 1:18:55 PM UTC-5, Laurent LA RIZZA wrot=
e:
>>
>>
>>
>> Le samedi 23 d=C3=A9cembre 2017 18:27:26 UTC+1, Nicol Bolas a =C3=A9crit=
 :
>>>
>>> in your case, `is_enum_v<strong_equality>` is true; in my case, it is=
=20
>>> not.
>>>
>>>
>> That is entirely true. But I think I invalidated the stated reason why=
=20
>> enum class was not used to create a strong typedefs in this paper.
>>
>
> ... how? `enum class`* cannot* do what you did; the standard doesn't=20
> allow that.
>
> Now, you can say that, if your proposal is adopted, you* could* use `enum=
=20
> class` for the results of `operator<=3D>`. But until your proposal is=20
> actually adopted, the reasons that `operator<=3D>` didn't use them are st=
ill=20
> quite valid. So you've invalidated nothing.
>
> And even then, your proposal isn't good enough. Why? Because=20
> `strong_equality{10}` would still have to be legal code for your `enum=20
> class`.
>
> Oh, I'm sure you'll now add some syntax to your "proposal" that explicitl=
y=20
> disables such conversion (perhaps an `=3D delete` constructor or some suc=
h).
>

Correct. Good to read that, besides my consistent failure to convey my=20
ideas clearly, you still can trace through the same path of thought that I=
=20
followed. It must not be thinking so absurdly after all.

But that's just another reminder that `enum class` is the* wrong tool* for=
=20
> strong aliases.
>

No. That's actually a reminder that `enum class` and `enum` need to go from=
=20
half-baked to well-done, or be deprecated altogether.

You're trying to hijack an existing syntax rather than* creating* a good=20
> one.
>
>
No. I'm trying to demonstrate that the syntax for class types and=20
enumeration types can be made the same. (although I am not entirely happy=
=20
with what I proposed in my OP)

There is no reason to use `enum class` for inducing a strong alias than any=
=20
> other syntax.
>

Correct also. So let's not do that. Leave strong typedefs aside. Instead,=
=20
let's do two things :

#1 I'd like to be able to enumerate named constants (=C2=A710.2) of any lit=
eral=20
type, not just integral types. I could declare inline const constexpr=20
member variables in a class type, but I don't want users to be able to form=
=20
a reference to them. I want purely symbolic constants. Only enumeration=20
types provide such named constants. The functionality of named constants is=
=20
IHMO-cool. Two solutions : either invent something new and ultimately=20
deprecate enums that are still part of C, or lift the restrictions on the=
=20
underlying types of enumeration types. If I aim to ultimately deprecate=20
enumeration types, then I aim to toss away the very existing functionality=
=20
I am looking for. And since literal types are only required to declare the=
=20
enumerators and not the type itself, just allow any type as underlying type=
..

#2 I am not entirely happy with the current state of the metaclasses=20
proposal (P0707R2). The proposal includes an enum_class metaclass example=
=20
that uses your technique (static constexpr member variables) to define the=
=20
symbolic constants. Well, where did the IMHO-cool "named constants"=20
functionality from C disappear? The metaclasses proposal won't let you=20
define named constants in a class type because class types can't have any.=
=20
Instead, if we could make enumeration type- and class type declarations=20
uniform (backward-compatibly), we could define user-defined types declared=
=20
with class, struct, enum, enum class/struct  with a metaclass each.

--=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/95baafa9-bedc-42bf-89aa-7589ceb30283%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>Le samedi 23 d=C3=A9cembre 2017 20:16:58 UTC+1, Ni=
col Bolas a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><br><br>On Saturday, December 23, 2017 at 1:18:55 PM UTC-5,=
 Laurent LA RIZZA wrote:<blockquote 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>Le samedi 23 d=C3=A9cembre 2017 18:27:26 UTC+1, Nicol Bolas a=
 =C3=A9crit=C2=A0:<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"ltr">=
<div style=3D"margin:0px;padding:0px;border:0px rgb(34,34,34);text-align:le=
ft;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spacing:n=
ormal;font-size:13px;font-variant:normal;word-spacing:0px;white-space:norma=
l;background-color:transparent">in your case, `is_enum_v&lt;strong_equality=
&gt;` is true; in my case, it is not.</div><div><br></div></div></blockquot=
e><div><br></div><div>That is entirely true. But I think I invalidated the =
stated reason why enum class was not used to create a strong typedefs in th=
is paper.<br></div></div></blockquote><div><br></div><div>... how? `enum cl=
ass`<i> cannot</i> do what you did; the standard doesn&#39;t allow that.</d=
iv><div><br></div><div>Now, you can say that, if your proposal is adopted, =
you<i> could</i> use `enum class` for the results of `operator&lt;=3D&gt;`.=
 But until your proposal is actually adopted, the reasons that `operator&lt=
;=3D&gt;` didn&#39;t use them are still quite valid. So you&#39;ve invalida=
ted nothing.</div><div><br></div><div>And even then, your proposal isn&#39;=
t good enough. Why? Because `strong_equality{10}` would still have to be le=
gal code for your `enum class`.</div><div><br></div><div>Oh, I&#39;m sure y=
ou&#39;ll now add some syntax to your &quot;proposal&quot; that explicitly =
disables such conversion (perhaps an `=3D delete` constructor or some such)=
..</div></div></blockquote><div><br></div><div>Correct. Good to read that, b=
esides my consistent failure to convey my ideas clearly, you still can trac=
e through the same path of thought that I followed. It must not be thinking=
 so absurdly after all.</div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div>But that&#39;s just another reminder th=
at `enum class` is the<i> wrong tool</i> for strong aliases.</div></div></b=
lockquote><div><br></div><div>No. That&#39;s actually a reminder that `enum=
 class` and `enum` need to go from half-baked to well-done, or be deprecate=
d altogether.</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div>You&#39;re trying to hijack an existing syntax =
rather than<i> creating</i> a good one.</div><div><br></div></div></blockqu=
ote><div><br></div><div>No. I&#39;m trying to demonstrate that the syntax f=
or class types and enumeration types can be made the same. (although I am n=
ot entirely happy with what I proposed in my OP)<br></div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div=
>There is no reason to use `enum class` for inducing a strong alias than an=
y other syntax.</div></div></blockquote><div><br></div><div>Correct also. S=
o let&#39;s not do that. Leave strong typedefs aside. Instead, let&#39;s do=
 two things :</div><div><br></div><div>#1 I&#39;d like to be able to enumer=
ate named constants (=C2=A710.2) of any literal type, not just integral typ=
es. I could declare inline const constexpr member variables in a class type=
, but I don&#39;t want users to be able to form a reference to them. I want=
 purely symbolic constants. Only enumeration types provide such named const=
ants. The functionality of named constants is IHMO-cool. Two solutions : ei=
ther invent something new and ultimately deprecate enums that are still par=
t of C, or lift the restrictions on the underlying types of enumeration typ=
es. If I aim to ultimately deprecate enumeration types, then I aim to toss =
away the very existing functionality I am looking for. And since literal ty=
pes are only required to declare the enumerators and not the type itself, j=
ust allow any type as underlying type.<br></div><div><br></div><div>#2 I am=
 not entirely happy with the current state of the metaclasses proposal (P07=
07R2). The proposal includes an enum_class metaclass example that uses your=
 technique (static constexpr member variables) to define the symbolic const=
ants. Well, where did the IMHO-cool &quot;named constants&quot; functionali=
ty from C disappear? The metaclasses proposal won&#39;t let you define name=
d constants in a class type because class types can&#39;t have any. Instead=
, if we could make enumeration type- and class type declarations uniform (b=
ackward-compatibly), we could define user-defined types declared with class=
, struct, enum, enum class/struct=C2=A0 with a metaclass each.<br></div></d=
iv>

<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/95baafa9-bedc-42bf-89aa-7589ceb30283%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/95baafa9-bedc-42bf-89aa-7589ceb30283=
%40isocpp.org</a>.<br />

------=_Part_11381_194800073.1514061220989--

------=_Part_11380_863580853.1514061220989--

.

------=_Part_11489_1275591890.1514064458317
Content-Type: multipart/alternative;
 boundary="----=_Part_11490_573482818.1514064458317"

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



On Saturday, December 23, 2017 at 3:33:41 PM UTC-5, Laurent LA RIZZA wrote:
>
>
>
> Le samedi 23 d=C3=A9cembre 2017 20:16:58 UTC+1, Nicol Bolas a =C3=A9crit =
:
>>
>>
>>
>> On Saturday, December 23, 2017 at 1:18:55 PM UTC-5, Laurent LA RIZZA=20
>> wrote:
>>>
>>>
>>>
>>> Le samedi 23 d=C3=A9cembre 2017 18:27:26 UTC+1, Nicol Bolas a =C3=A9cri=
t :
>>>>
>>>> in your case, `is_enum_v<strong_equality>` is true; in my case, it is=
=20
>>>> not.
>>>>
>>>>
>>> That is entirely true. But I think I invalidated the stated reason why=
=20
>>> enum class was not used to create a strong typedefs in this paper.
>>>
>>
>> ... how? `enum class`* cannot* do what you did; the standard doesn't=20
>> allow that.
>>
>> Now, you can say that, if your proposal is adopted, you* could* use=20
>> `enum class` for the results of `operator<=3D>`. But until your proposal=
 is=20
>> actually adopted, the reasons that `operator<=3D>` didn't use them are s=
till=20
>> quite valid. So you've invalidated nothing.
>>
>> And even then, your proposal isn't good enough. Why? Because=20
>> `strong_equality{10}` would still have to be legal code for your `enum=
=20
>> class`.
>>
>> Oh, I'm sure you'll now add some syntax to your "proposal" that=20
>> explicitly disables such conversion (perhaps an `=3D delete` constructor=
 or=20
>> some such).
>>
>
> Correct. Good to read that, besides my consistent failure to convey my=20
> ideas clearly, you still can trace through the same path of thought that =
I=20
> followed. It must not be thinking so absurdly after all.
>

My point was that your idea is not fully formed; it's a sketch of an idea.=
=20
Every time someone points out that part of your sketch hasn't been filled=
=20
in, you hastily color it in with crayon.

But that's just another reminder that `enum class` is the* wrong tool* for=
=20
>> strong aliases.
>>
>
> No. That's actually a reminder that `enum class` and `enum` need to go=20
> from half-baked to well-done, or be deprecated altogether.
>

Or we can just leave the perfectly useful idea of enumerators right where=
=20
it is. There is nothing "half-baked" about them; they do exactly what they=
=20
need to, and they do that thing quite well.

You're trying to hijack an existing syntax rather than* creating* a good=20
>> one.
>>
>
> No. I'm trying to demonstrate that the syntax for class types and=20
> enumeration types can be made the same. (although I am not entirely happy=
=20
> with what I proposed in my OP)
>

So what if they* could* be? That doesn't mean they* should* be.

There is no reason to use `enum class` for inducing a strong alias than any=
=20
>> other syntax.
>>
>
> Correct also. So let's not do that. Leave strong typedefs aside. Instead,=
=20
> let's do two things :
>
> #1 I'd like to be able to enumerate named constants (=C2=A710.2) of any l=
iteral=20
> type, not just integral types. I could declare inline const constexpr=20
> member variables in a class type, but I don't want users to be able to fo=
rm=20
> a reference to them.
>

Why would you care if users reference them or not? Do you really think=20
that's going to impact the compiled result so much?

I want purely symbolic constants. Only enumeration types provide such named=
=20
> constants. The functionality of named constants is IHMO-cool. Two solutio=
ns=20
> : either invent something new and ultimately deprecate enums that are sti=
ll=20
> part of C, or lift the restrictions on the underlying types of enumeratio=
n=20
> types. If I aim to ultimately deprecate enumeration types,
>

.... why would C++ ever need to deprecate a perfectly useful, entirely=20
reasonable, easily understood, and* widely used* piece of functionality=20
like enumerations? What would it gain users to have to rewrite all of their=
=20
code just to get the* exact same behavior* they had before?

Deprecating enumerations achieves nothing positive for the language. It=20
doesn't even reclaim keywords or syntax for future use. It's an idea that=
=20
has only downsides.

then I aim to toss away the very existing functionality I am looking for.=
=20
> And since literal types are only required to declare the enumerators and=
=20
> not the type itself, just allow any type as underlying type.
>
> #2 I am not entirely happy with the current state of the metaclasses=20
> proposal (P0707R2). The proposal includes an enum_class metaclass example=
=20
> that uses your technique (static constexpr member variables) to define th=
e=20
> symbolic constants. Well, where did the IMHO-cool "named constants"=20
> functionality from C disappear?
>

Nowhere. The `enum_class` metaclass is merely a proof-of-concept that shows=
=20
the potential of the metaclasses proposal. It is not a suggestion that=20
`enum class` or `enum` ought to be removed or shouldn't have been=20
standardized; it merely shows that metaclasses can get you 99% of what they=
=20
already provide.

The metaclasses proposal won't let you define named constants in a class=20
> type because class types can't have any. Instead, if we could make=20
> enumeration type- and class type declarations uniform=20
> (backward-compatibly), we could define user-defined types declared with=
=20
> class, struct, enum, enum class/struct  with a metaclass each.
>

--=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/c0941909-658b-46a1-9b00-7e82aec76044%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Saturday, December 23, 2017 at 3:33:41 PM UTC-5=
, Laurent LA RIZZA wrote:<blockquote 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>Le samedi 23 d=C3=A9cembre 2017 20:16:58 UTC+1, Nicol B=
olas a =C3=A9crit=C2=A0:<blockquote 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 Saturday, December 23, 2017 at 1:18:55 PM UTC-5, Laurent L=
A RIZZA wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>=
<br>Le samedi 23 d=C3=A9cembre 2017 18:27:26 UTC+1, Nicol Bolas a =C3=A9cri=
t=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div style=
=3D"margin:0px;padding:0px;border:0px rgb(34,34,34);text-align:left;color:r=
gb(34,34,34);text-transform:none;text-indent:0px;letter-spacing:normal;font=
-size:13px;font-variant:normal;word-spacing:0px;white-space:normal;backgrou=
nd-color:transparent">in your case, `is_enum_v&lt;strong_equality&gt;` is t=
rue; in my case, it is not.</div><div><br></div></div></blockquote><div><br=
></div><div>That is entirely true. But I think I invalidated the stated rea=
son why enum class was not used to create a strong typedefs in this paper.<=
br></div></div></blockquote><div><br></div><div>... how? `enum class`<i> ca=
nnot</i> do what you did; the standard doesn&#39;t allow that.</div><div><b=
r></div><div>Now, you can say that, if your proposal is adopted, you<i> cou=
ld</i> use `enum class` for the results of `operator&lt;=3D&gt;`. But until=
 your proposal is actually adopted, the reasons that `operator&lt;=3D&gt;` =
didn&#39;t use them are still quite valid. So you&#39;ve invalidated nothin=
g.</div><div><br></div><div>And even then, your proposal isn&#39;t good eno=
ugh. Why? Because `strong_equality{10}` would still have to be legal code f=
or your `enum class`.</div><div><br></div><div>Oh, I&#39;m sure you&#39;ll =
now add some syntax to your &quot;proposal&quot; that explicitly disables s=
uch conversion (perhaps an `=3D delete` constructor or some such).</div></d=
iv></blockquote><div><br></div><div>Correct. Good to read that, besides my =
consistent failure to convey my ideas clearly, you still can trace through =
the same path of thought that I followed. It must not be thinking so absurd=
ly after all.</div></div></blockquote><div><br></div><div>My point was that=
 your idea is not fully formed; it&#39;s a sketch of an idea. Every time so=
meone points out that part of your sketch hasn&#39;t been filled in, you ha=
stily color it in with crayon.</div><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div>But that&#39;s just another reminder that `enum cl=
ass` is the<i> wrong tool</i> for strong aliases.</div></div></blockquote><=
div><br></div><div>No. That&#39;s actually a reminder that `enum class` and=
 `enum` need to go from half-baked to well-done, or be deprecated altogethe=
r.</div></div></blockquote><div><br></div><div>Or we can just leave the per=
fectly useful idea of enumerators right where it is. There is nothing &quot=
;half-baked&quot; about them; they do exactly what they need to, and they d=
o that thing quite well.</div><div><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div>You&#39;re trying to hijack an existing syntax rather th=
an<i> creating</i> a good one.<br></div></div></blockquote><div><br></div><=
div>No. I&#39;m trying to demonstrate that the syntax for class types and e=
numeration types can be made the same. (although I am not entirely happy wi=
th what I proposed in my OP)<br></div></div></blockquote><div><br></div><di=
v>So what if they<i> could</i> be? That doesn&#39;t mean they<i> should</i>=
 be.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>T=
here is no reason to use `enum class` for inducing a strong alias than any =
other syntax.</div></div></blockquote><div><br></div><div>Correct also. So =
let&#39;s not do that. Leave strong typedefs aside. Instead, let&#39;s do t=
wo things :</div><div><br></div><div>#1 I&#39;d like to be able to enumerat=
e named constants (=C2=A710.2) of any literal type, not just integral types=
.. I could declare inline const constexpr member variables in a class type, =
but I don&#39;t want users to be able to form a reference to them.</div></d=
iv></blockquote><div><br></div><div>Why would you care if users reference t=
hem or not? Do you really think that&#39;s going to impact the compiled res=
ult so much?</div><div><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr"><div>I want purely symbolic constants. Only enumeration=
 types provide such named constants. The functionality of named constants i=
s IHMO-cool. Two solutions : either invent something new and ultimately dep=
recate enums that are still part of C, or lift the restrictions on the unde=
rlying types of enumeration types. If I aim to ultimately deprecate enumera=
tion types,</div></div></blockquote><div><br></div><div>... why would C++ e=
ver need to deprecate a perfectly useful, entirely reasonable, easily under=
stood, and<i> widely used</i> piece of functionality like enumerations? Wha=
t would it gain users to have to rewrite all of their code just to get the<=
i> exact same behavior</i> they had before?</div><div><br></div><div>Deprec=
ating enumerations achieves nothing positive for the language. It doesn&#39=
;t even reclaim keywords or syntax for future use. It&#39;s an idea that ha=
s only downsides.</div><div><i><br></i></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><div>then I aim to toss away the very exist=
ing functionality I am looking for. And since literal types are only requir=
ed to declare the enumerators and not the type itself, just allow any type =
as underlying type.<br></div><div><br></div><div>#2 I am not entirely happy=
 with the current state of the metaclasses proposal (P0707R2). The proposal=
 includes an enum_class metaclass example that uses your technique (static =
constexpr member variables) to define the symbolic constants. Well, where d=
id the IMHO-cool &quot;named constants&quot; functionality from C disappear=
?</div></div></blockquote><div><br></div><div>Nowhere. The `enum_class` met=
aclass is merely a proof-of-concept that shows the potential of the metacla=
sses proposal. It is not a suggestion that `enum class` or `enum` ought to =
be removed or shouldn&#39;t have been standardized; it merely shows that me=
taclasses can get you 99% of what they already provide.</div><div><br></div=
><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>The met=
aclasses proposal won&#39;t let you define named constants in a class type =
because class types can&#39;t have any. Instead, if we could make enumerati=
on type- and class type declarations uniform (backward-compatibly), we coul=
d define user-defined types declared with class, struct, enum, enum class/s=
truct=C2=A0 with a metaclass each.<br></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/c0941909-658b-46a1-9b00-7e82aec76044%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c0941909-658b-46a1-9b00-7e82aec76044=
%40isocpp.org</a>.<br />

------=_Part_11490_573482818.1514064458317--

------=_Part_11489_1275591890.1514064458317--

.

------=_Part_11495_1099309273.1514067353336
Content-Type: multipart/alternative;
 boundary="----=_Part_11496_1942205091.1514067353336"

------=_Part_11496_1942205091.1514067353336
Content-Type: text/plain; charset="UTF-8"


Nicol Bolas : OK, you win.

--
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/c98d0912-0f74-4970-a1c4-893743f797b8%40isocpp.org.

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

<div dir=3D"ltr"><br>Nicol Bolas : OK, you win.<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/c98d0912-0f74-4970-a1c4-893743f797b8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c98d0912-0f74-4970-a1c4-893743f797b8=
%40isocpp.org</a>.<br />

------=_Part_11496_1942205091.1514067353336--

------=_Part_11495_1099309273.1514067353336--

.

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

Le 23/12/2017 =C3=A0 18:14, Nicol Bolas a =C3=A9crit=C2=A0:
> On Saturday, December 23, 2017 at 11:55:42 AM UTC-5, Laurent LA RIZZA=20
> wrote:
>
>
>
>     Le samedi 23 d=C3=A9cembre 2017 16:37:41 UTC+1, Nicol Bolas a =C3=A9c=
rit=C2=A0:
>
>             Can we fix construction please?" Was adoption a mistake?
>             Maybe, I don't know.
>
>
>         Yes, that was exactly what I was referring to, and yes, /it
>         was a mistake/.
>
>     I still don't know, that does not change the fact that even before
>     that "mistake", people were using /enum class/ to create strong
>     typedefs of integral types.
>
>
> People also used template instantiation to do compile-time=20
> computations. C++ programmers are willing to use any feature for any=20
> purpose, so long as it works. That doesn't mean we should enshrine it=20
> as the right idea. If people want to do compile-time computations, we=20
> should give them functions that run at compile-time, not make them=20
> jump through hoops of type instantiation and so forth.
>
> You're basically saying, "we have template metaprogramming; why not=20
> add more to that, instead of bothering with this whole `constexpr`=20
> function thing?" Or "we have SFINAE; why not add more to that, instead=20
> of bothering with this whole `requires` thing?"
I believe all of us want some simplified form to build strong types (in=20
particular those based on an underlying type).
enum class is the closest construct we have in C++17, so it is not weird=20
to start from them.

Let use another syntax then
*new class B : A {};*

>
>     We have strong typedefs in C++17.
>
>
I wouldn't use the term strong typedefs, but strong types.
> No, we have/hacks/ in C++17.
enum class defines a new strong type, different from its underlying=20
type. This is not a hack IMO.
>
> <snip>
>
>
>
>             Can you please elaborate the use cases you think of where
>             you would want other aliasing strength than the binary
>             "they're the same type/they're not the same type"?
>
>
>         Go read every strong typedef proposal that has ever been
>         proposed. They do a good job of covering the myriad of
>         possible ways people want to deal with such things.
>
>
>     I have done (a long time ago), and will do again. I thank you for
>     expressing your opinions on my ideas.
>
>
>         However, as a simple example, let's say you have a class A,
>         and you make a strong typedef of it called B.
>
>
>     OK, so :
>
>     *enum class B : A {};*
>
>         Can B do everything that A could do?
>
>
>     No. It can be explicitly convertible to and from *A* (with and
>     without variable numbers of ampersands, but I haven't thought it
>     through) If A is literal, you can define named constants of type
>     B. You can add also add member non-variables.
>
Literals of type A cannot be literals of type B, clearly.

While I can find useful a new strong type is explicitly convertible to=20
the underlying type, I believe that sometimes the new strong type could=20
be implicitly convertible to the underlying type, or even that the=20
explicit conversion is not required, as e.g. chrono::duration. Have you=20
considered this case? What about having only the explicit construction=20
and a the ability to get the underlying representation using a specific=20
function, e.g. underlying?

*new class B : A {};*

*new class B : A {
public:
 =C2=A0=C2=A0=C2=A0 operator A() =3D default;
};*

*new class B : A {
public:
 =C2=A0=C2=A0=C2=A0 explicit operator A() =3D default;
};*



>
>         For example, if A was Swappable, that means A probably has a
>         non-member `swap` function.
>
>
>     *enum class B : A {*
>     *public :*
>     *=C2=A0 friend void swap(B&, B&) =3D default;
>     *
>     *};*
>
>         Does B automatically get one?
>
>
>     No.
>
>         Should it?
>
>
>     No.
>
>         If A was addable to integers via non-member `operator+`,
>         should B be addable too?
>
>     No, but :
>
>     *enum class B : A {*
>     *public :*
>     *=C2=A0 friend B operator+(const B&, int) =3D default;
>     *
>     *};*
>
>         And if you can't automatically get the non-member interfaces
>         of A, then what good is B?
>
>     B is a distinct type from A, explicitly convertible to and from
>     it. B is stored the same way as A. It is as copyable, movable,
>     assignable and destructible as A, except the signatures get B in
>     lieu of A.
>
>

Lets see what can be done today without any new language change. There=20
are some libraries proposing some kind of strong type helpers. E.g.


template <class Tag, class UT =3D int>
using strong_id =3D new_type<Tag, UT
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , meta_mixin::comparable<>
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , meta_mixin::hashable<>
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , meta_mixin::streamable<>
 >;

would define an identifier that is comparable, hashable and streamable.=20
(See=20
https://github.com/viboes/std-make/blob/master/include/experimental/fundame=
ntal/v3/strong/strong_id.hpp=20
and the same folder for more examples)

This needs of course the definition of meta_mixin::comparable<> that=20
implement via a library the =3Ddefault trampolines.


How the new language feature could take in account the ability to=20
compose the inherited functionalities?
I believe metaclasses could help on this, but I have not tried anything=20
with.

> But it's not actually an alias of `A`, since it cannot do what `A` does.
Why do you want `B` to be an alias of `A`?
>
> My point is that C++ has no mechanism to identify free functions that=20
> are a fundamental part of a class's interface from free functions=20
> which are not. And without that, making proper strong aliases becomes=20
> a maintenance burden. If someone adds a new free function interface to=20
> A, you have to add a `friend` declaration to/every/ strong alias of it=20
> in order to pick up that behavior.
A strong type is a type that defines its operations, independently of=20
the operations provided by its representation.
> /
> /
> My/other/ point is that you're spending way too much time on the=20
> syntax (insisting on overloading "enum class" for things that aren't=20
> enumerators) and not enough on the /actually useful/ parts of the=20
> feature. For example, this is the first thing you've mentioned about=20
> this `=3D default` syntax for inheriting functionality from the class=20
> being aliased.
There is no alias.
> That's a /really important/ part of the proposal, and yet you didn't=20
> even mention that in your initial post, instead spending time trying=20
> to justify "enum class" as the correct induction syntax.
>
> Why do you care so much that it gets called "enum class" instead of,=20
> like,/anything else/?
I agree, the syntax is not so important, but at the end we need it and=20
if possible we should take in account the current language, so that the=20
new feature extends properly the current one.
> /
> /
>
>     You can't even have them non-automatically in C++17, since you
>     can't define B if A is not an integral type.
>
>     A question for you : if using enum class for creating strong
>     aliases of integral types in C++17 is a mistake, how do you create
>     strong aliases of integral types in C++17?
>
>
> The same way I did in C++14: with an actual class. It's verbose, but=20
> at least it isn't stupid looking and confusing.
Lets explore both alternatives.

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/6bbf17a6-bde2-1057-0699-18fed96c7e3f%40wanadoo.f=
r.

--------------EA5F778783460364435F6616
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 23/12/2017 =C3=A0 18:14, Nicol Bolas =
a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"
      cite=3D"mid:1af8df58-c309-4404-9428-eefd9aa92a81@isocpp.org">
      <div dir=3D"ltr">On Saturday, December 23, 2017 at 11:55:42 AM
        UTC-5, Laurent LA RIZZA wrote:
        <blockquote 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>
            Le samedi 23 d=C3=A9cembre 2017 16:37:41 UTC+1, Nicol Bolas a
            =C3=A9crit=C2=A0:
            <div>=C2=A0</div>
            <blockquote class=3D"gmail_quote"
              style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
              solid;padding-left:1ex">
              <div dir=3D"ltr">
                <blockquote class=3D"gmail_quote"
                  style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
                  solid;padding-left:1ex">
                  <div dir=3D"ltr">
                    <div>Can we fix construction please?" Was adoption a
                      mistake? Maybe, I don't know.</div>
                  </div>
                </blockquote>
                <div><br>
                </div>
                <div>Yes, that was exactly what I was referring to, and
                  yes, <i>it was a mistake</i>.</div>
                <div><br>
                </div>
              </div>
            </blockquote>
            <div>I still don't know, that does not change the fact that
              even before that "mistake", people were using <i>enum
                class</i> to create strong typedefs of integral types.</div=
>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>People also used template instantiation to do compile-time
          computations. C++ programmers are willing to use any feature
          for any purpose, so long as it works. That doesn't mean we
          should enshrine it as the right idea. If people want to do
          compile-time computations, we should give them functions that
          run at compile-time, not make them jump through hoops of type
          instantiation and so forth.</div>
        <div><br>
        </div>
        <div>You're basically saying, "we have template metaprogramming;
          why not add more to that, instead of bothering with this whole
          `constexpr` function thing?" Or "we have SFINAE; why not add
          more to that, instead of bothering with this whole `requires`
          thing?"</div>
      </div>
    </blockquote>
    I believe all of us want some simplified form to build strong types
    (in particular those based on an underlying type).<br>
    enum class is the closest construct we have in C++17, so it is not
    weird to start from them.<br>
    <br>
    Let use another syntax then<br>
    <div><b> new class B : A {};</b></div>
    <br>
    <blockquote type=3D"cite"
      cite=3D"mid:1af8df58-c309-4404-9428-eefd9aa92a81@isocpp.org">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div dir=3D"ltr">
            <div>We have strong typedefs in C++17.</div>
          </div>
        </blockquote>
        <div><br>
        </div>
      </div>
    </blockquote>
    I wouldn't use the term strong typedefs, but strong types.<br>
    <blockquote type=3D"cite"
      cite=3D"mid:1af8df58-c309-4404-9428-eefd9aa92a81@isocpp.org">
      <div dir=3D"ltr">
        <div>No, we have<i> hacks</i> in C++17.</div>
      </div>
    </blockquote>
    enum class defines a new strong type, different from its underlying
    type. This is not a hack IMO.<br>
    <blockquote type=3D"cite"
      cite=3D"mid:1af8df58-c309-4404-9428-eefd9aa92a81@isocpp.org">
      <div dir=3D"ltr">
        <div><br>
        </div>
        &lt;snip&gt;
        <div><br>
        </div>
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div dir=3D"ltr">
            <blockquote class=3D"gmail_quote"
              style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
              solid;padding-left:1ex">
              <div dir=3D"ltr">
                <div><br>
                </div>
                <blockquote class=3D"gmail_quote"
                  style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
                  solid;padding-left:1ex">
                  <div dir=3D"ltr">
                    <div> </div>
                    <br>
                    <div>Can you please elaborate the use cases you
                      think of where you would want other aliasing
                      strength than the binary "they're the same
                      type/they're not the same type"?<br>
                    </div>
                  </div>
                </blockquote>
                <div><br>
                </div>
                <div>Go read every strong typedef proposal that has ever
                  been proposed. They do a good job of covering the
                  myriad of possible ways people want to deal with such
                  things.</div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>I have done (a long time ago), and will do again. I
              thank you for expressing your opinions on my ideas. <br>
            </div>
            <blockquote class=3D"gmail_quote"
              style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
              solid;padding-left:1ex">
              <div dir=3D"ltr">
                <div><br>
                </div>
                <div>However, as a simple example, let's say you have a
                  class A, and you make a strong typedef of it called B.</d=
iv>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>OK, so :</div>
            <div><br>
            </div>
            <div><b> enum class B : A {};</b></div>
            <div><br>
            </div>
            <blockquote class=3D"gmail_quote"
              style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
              solid;padding-left:1ex">
              <div dir=3D"ltr">
                <div>Can B do everything that A could do? </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>No. It can be explicitly convertible to and from <b>A</b>
              (with and without variable numbers of ampersands, but I
              haven't thought it through) If A is literal, you can
              define named constants of type B. You can add also add
              member non-variables.</div>
          </div>
        </blockquote>
      </div>
    </blockquote>
    Literals of type A cannot be literals of type B, clearly.<br>
    <br>
    While I can find useful a new strong type is explicitly convertible
    to the underlying type, I believe that sometimes the new strong type
    could be implicitly convertible to the underlying type, or even that
    the explicit conversion is not required, as e.g. chrono::duration.
    Have you considered this case? What about having only the explicit
    construction and a the ability to get the underlying representation
    using a specific function, e.g. underlying?<br>
    <br>
    <div><b> new class B : A {};</b></div>
    <div><br>
      <div><b> new class B : A {<br>
          public:<br>
          =C2=A0=C2=A0=C2=A0 operator A() =3D default;<br>
          };</b></div>
      <div><br>
        <div><b> new class B : A {<br>
            public:<br>
            =C2=A0=C2=A0=C2=A0 explicit operator A() =3D default;<br>
            };</b></div>
        <div><br>
        </div>
      </div>
    </div>
    <br>
    <br>
    <blockquote type=3D"cite"
      cite=3D"mid:1af8df58-c309-4404-9428-eefd9aa92a81@isocpp.org">
      <div dir=3D"ltr">
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div dir=3D"ltr">
            <div>=C2=A0 <br>
            </div>
            <blockquote class=3D"gmail_quote"
              style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
              solid;padding-left:1ex">
              <div dir=3D"ltr">
                <div>For example, if A was Swappable, that means A
                  probably has a non-member `swap` function. </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div><b>enum class B : A {</b></div>
            <div><b>public :</b></div>
            <div><b>=C2=A0 friend void swap(B&amp;, B&amp;) =3D default;<br=
>
              </b></div>
            <div><b>};</b></div>
            <div><br>
            </div>
            <blockquote class=3D"gmail_quote"
              style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
              solid;padding-left:1ex">
              <div dir=3D"ltr">
                <div>Does B automatically get one?</div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>No.</div>
            <div> <br>
            </div>
            <blockquote class=3D"gmail_quote"
              style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
              solid;padding-left:1ex">
              <div dir=3D"ltr">
                <div> Should it? </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>No.</div>
            <div> <br>
            </div>
            <blockquote class=3D"gmail_quote"
              style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
              solid;padding-left:1ex">
              <div dir=3D"ltr">
                <div>If A was addable to integers via non-member
                  `operator+`, should B be addable too?</div>
                <div><br>
                </div>
              </div>
            </blockquote>
            <div>No, but :</div>
            <div><br>
            </div>
            <div>
              <div><b>enum class B : A {</b></div>
              <div><b>public :</b></div>
              <div><b>=C2=A0 friend B operator+(const B&amp;, int) =3D defa=
ult;<br>
                </b></div>
              <div><b>};</b></div>
              <div><br>
              </div>
            </div>
            <blockquote class=3D"gmail_quote"
              style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
              solid;padding-left:1ex">
              <div dir=3D"ltr">
                <div>And if you can't automatically get the non-member
                  interfaces of A, then what good is B?</div>
              </div>
            </blockquote>
            <div>=C2=A0</div>
            <div>B is a distinct type from A, explicitly convertible to
              and from it. B is stored the same way as A. It is as
              copyable, movable, assignable and destructible as A,
              except the signatures get B in lieu of A.<br>
            </div>
          </div>
        </blockquote>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
    Lets see what can be done today without any new language change.
    There are some libraries proposing some kind of strong type helpers.
    E.g.<br>
    <br>
    <br>
    template &lt;class Tag, class UT =3D int&gt;<br>
    using strong_id =3D new_type&lt;Tag, UT<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , meta_mixin::comparable&lt;&gt;<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , meta_mixin::hashable&lt;&gt;<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , meta_mixin::streamable&lt;&gt;<br>
    &gt;;<br>
    <br>
    would define an identifier that is comparable, hashable and
    streamable. (See
<a class=3D"moz-txt-link-freetext" href=3D"https://github.com/viboes/std-ma=
ke/blob/master/include/experimental/fundamental/v3/strong/strong_id.hpp">ht=
tps://github.com/viboes/std-make/blob/master/include/experimental/fundament=
al/v3/strong/strong_id.hpp</a>
    and the same folder for more examples)<br>
    <br>
    This needs of course the definition of
    meta_mixin::comparable&lt;&gt; that implement via a library the
    =3Ddefault trampolines.<br>
    <br>
    <br>
    How the new language feature could take in account the ability to
    compose the inherited functionalities?<br>
    I believe metaclasses could help on this, but I have not tried
    anything with.<br>
    <br>
    <blockquote type=3D"cite"
      cite=3D"mid:1af8df58-c309-4404-9428-eefd9aa92a81@isocpp.org">
      <div dir=3D"ltr">
        <div>But it's not actually an alias of `A`, since it cannot do
          what `A` does.</div>
      </div>
    </blockquote>
    Why do you want `B` to be an alias of `A`?<br>
    <blockquote type=3D"cite"
      cite=3D"mid:1af8df58-c309-4404-9428-eefd9aa92a81@isocpp.org">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>My point is that C++ has no mechanism to identify free
          functions that are a fundamental part of a class's interface
          from free functions which are not. And without that, making
          proper strong aliases becomes a maintenance burden. If someone
          adds a new free function interface to A, you have to add a
          `friend` declaration to<i> every</i> strong alias of it in
          order to pick up that behavior.</div>
      </div>
    </blockquote>
    A strong type is a type that defines its operations, independently
    of the operations provided by its representation.<br>
    <blockquote type=3D"cite"
      cite=3D"mid:1af8df58-c309-4404-9428-eefd9aa92a81@isocpp.org">
      <div dir=3D"ltr">
        <div><i><br>
          </i></div>
        <div>My<i> other</i> point is that you're spending way too much
          time on the syntax (insisting on overloading "enum class" for
          things that aren't enumerators) and not enough on the <i>actually
            useful</i> parts of the feature. For example, this is the
          first thing you've mentioned about this `=3D default` syntax for
          inheriting functionality from the class being aliased. </div>
      </div>
    </blockquote>
    There is no alias.<br>
    <blockquote type=3D"cite"
      cite=3D"mid:1af8df58-c309-4404-9428-eefd9aa92a81@isocpp.org">
      <div dir=3D"ltr">
        <div>That's a <i>really important</i> part of the proposal, and
          yet you didn't even mention that in your initial post, instead
          spending time trying to justify "enum class" as the correct
          induction syntax.</div>
        <div><br>
        </div>
        <div>Why do you care so much that it gets called "enum class"
          instead of, like,<i> anything else</i>?</div>
      </div>
    </blockquote>
    I agree, the syntax is not so important, but at the end we need it
    and if possible we should take in account the current language, so
    that the new feature extends properly the current one.<br>
    <blockquote type=3D"cite"
      cite=3D"mid:1af8df58-c309-4404-9428-eefd9aa92a81@isocpp.org">
      <div dir=3D"ltr">
        <div><i><br>
          </i></div>
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div dir=3D"ltr">
            <div>You can't even have them non-automatically in C++17,
              since you can't define B if A is not an integral type.</div>
            <div><br>
            </div>
            <div>A question for you : if using enum class for creating
              strong aliases of integral types in C++17 is a mistake,
              how do you create strong aliases of integral types in
              C++17?<br>
            </div>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>The same way I did in C++14: with an actual class. It's
          verbose, but at least it isn't stupid looking and confusing.</div=
>
      </div>
    </blockquote>
    Lets explore both alternatives.<br>
    <br>
    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/6bbf17a6-bde2-1057-0699-18fed96c7e3f%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6bbf17a6-bde2-1057-0699-18fed96c7e3f=
%40wanadoo.fr</a>.<br />

--------------EA5F778783460364435F6616--

.

------=_Part_30525_496949097.1514651427407
Content-Type: multipart/alternative;
 boundary="----=_Part_30526_392542379.1514651427408"

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

On Saturday, December 30, 2017 at 6:29:29 AM UTC-5, Vicente J. Botet=20
Escriba wrote:
>
> Le 23/12/2017 =C3=A0 18:14, Nicol Bolas a =C3=A9crit :
>
> On Saturday, December 23, 2017 at 11:55:42 AM UTC-5, Laurent LA RIZZA=20
> wrote:=20
>>
>>
>>
>> Le samedi 23 d=C3=A9cembre 2017 16:37:41 UTC+1, Nicol Bolas a =C3=A9crit=
 :=20
>> =20
>>
>>> Can we fix construction please?" Was adoption a mistake? Maybe, I don't=
=20
>>>> know.
>>>>
>>>
>>> Yes, that was exactly what I was referring to, and yes, *it was a=20
>>> mistake*.
>>>
>>> I still don't know, that does not change the fact that even before that=
=20
>> "mistake", people were using *enum class* to create strong typedefs of=
=20
>> integral types.
>>
>
> People also used template instantiation to do compile-time computations.=
=20
> C++ programmers are willing to use any feature for any purpose, so long a=
s=20
> it works. That doesn't mean we should enshrine it as the right idea. If=
=20
> people want to do compile-time computations, we should give them function=
s=20
> that run at compile-time, not make them jump through hoops of type=20
> instantiation and so forth.
>
> You're basically saying, "we have template metaprogramming; why not add=
=20
> more to that, instead of bothering with this whole `constexpr` function=
=20
> thing?" Or "we have SFINAE; why not add more to that, instead of botherin=
g=20
> with this whole `requires` thing?"
>
> I believe all of us want some simplified form to build strong types (in=
=20
> particular those based on an underlying type).
> enum class is the closest construct we have in C++17, so it is not weird=
=20
> to start from them.
>

Yes, it is weird to start from them. Enumerations are strongly typed=20
because it helps prevent errors. It stops you from accidentally using the=
=20
wrong enumerator in the wrong place, and it stops you from accidentally=20
pretending that an integer is an enumerator value. That's why enumerations=
=20
are strongly typed.

That underlying types of enumerations are similar in concept to the=20
relationship between a strong alias and the type it is based on is=20
essentially a coincidence. They may be similar in form, but they're=20
completely dissimilar in function.

Let use another syntax then
> * new class B : A {};*
>
>
> We have strong typedefs in C++17.
>>
>
> I wouldn't use the term strong typedefs, but strong types.
>
> No, we have* hacks* in C++17.
>
> enum class defines a new strong type, different from its underlying type.=
=20
> This is not a hack IMO.
>

That's not the hack part. The hack part is allowing `enumeration{integer}`=
=20
to work on empty enumerations. Normally, to convert an integer to a strong=
=20
enum type, you have to explicitly do a cast. Constructor syntax explicitly=
=20
is disallowed. Until C++17, where it is allowed for empty enumerations.
=20

>  =20
>
> For example, if A was Swappable, that means A probably has a non-member=
=20
>>> `swap` function.=20
>>>
>>
>> *enum class B : A {*
>> *public :*
>>
>> *  friend void swap(B&, B&) =3D default; *
>> *};*
>>
>> Does B automatically get one?
>>>
>>
>> No.
>>
>> Should it?=20
>>>
>>
>> No.
>>
>> If A was addable to integers via non-member `operator+`, should B be=20
>>> addable too?
>>>
>>> No, but :
>>
>> *enum class B : A {*
>> *public :*
>>
>> *  friend B operator+(const B&, int) =3D default; *
>> *};*
>>
>> And if you can't automatically get the non-member interfaces of A, then=
=20
>>> what good is B?
>>>
>> =20
>> B is a distinct type from A, explicitly convertible to and from it. B is=
=20
>> stored the same way as A. It is as copyable, movable, assignable and=20
>> destructible as A, except the signatures get B in lieu of A.
>>
>
>
> Lets see what can be done today without any new language change. There ar=
e=20
> some libraries proposing some kind of strong type helpers. E.g.
>
>
> template <class Tag, class UT =3D int>
> using strong_id =3D new_type<Tag, UT
>       , meta_mixin::comparable<>
>       , meta_mixin::hashable<>
>       , meta_mixin::streamable<>
> >;
>
> would define an identifier that is comparable, hashable and streamable.=
=20
> (See=20
> https://github.com/viboes/std-make/blob/master/include/experimental/funda=
mental/v3/strong/strong_id.hpp=20
> and the same folder for more examples)
>
> This needs of course the definition of meta_mixin::comparable<> that=20
> implement via a library the =3Ddefault trampolines.
>

The problem with trampolines is that they're only half-solutions. They only=
=20
work if you can identify up-front all of the interfaces you want to forward=
..

The ability to forward arbitrary interfaces is not available.
=20

> How the new language feature could take in account the ability to compose=
=20
> the inherited functionalities?
> I believe metaclasses could help on this, but I have not tried anything=
=20
> with.
>
> But it's not actually an alias of `A`, since it cannot do what `A` does.
>
> Why do you want `B` to be an alias of `A`?
>

.... because that's the premise of the discussion. We're talking about the=
=20
behavior of strong aliases. Therefore, such a discussion involves two=20
types, with one of them being a strong alias of the other.

I don't know what you mean with this question.

>
> My point is that C++ has no mechanism to identify free functions that are=
=20
> a fundamental part of a class's interface from free functions which are=
=20
> not. And without that, making proper strong aliases becomes a maintenance=
=20
> burden. If someone adds a new free function interface to A, you have to a=
dd=20
> a `friend` declaration to* every* strong alias of it in order to pick up=
=20
> that behavior.
>
> A strong type is a type that defines its operations, independently of the=
=20
> operations provided by its representation.
>

Then what you are talking about is a *subobject*, not an alias. A strong=20
alias is a type that behaves to a large degree like an existing type, while=
=20
still being a distinct type (and thus different from a `using name =3D type=
;`=20
alias) that can add new operations or change existing ones.

The very concept of an alias is that the new typename's properties are=20
defined primarily by an existing type. With weak aliases, they are the same=
=20
type with a different name. With strong aliases, they are a distinct type.=
=20
With subobjects, you're creating a distinct type, but its relationship with=
=20
any other type is entirely a matter of how it is implemented.

That's not an alias.

>

--=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/85488fc2-852c-4ffb-b67e-4220662869e9%40isocpp.or=
g.

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

<div dir=3D"ltr">On Saturday, December 30, 2017 at 6:29:29 AM UTC-5, Vicent=
e 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 bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>Le 23/12/2017 =C3=A0 18:14, Nicol Bolas a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">On Saturday, December 23, 2017 at 11:55:42 AM
        UTC-5, Laurent LA RIZZA wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
          <div dir=3D"ltr"><br>
            <br>
            Le samedi 23 d=C3=A9cembre 2017 16:37:41 UTC+1, Nicol Bolas a
            =C3=A9crit=C2=A0:
            <div>=C2=A0</div>
            <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div dir=3D"ltr">
                <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
                  <div dir=3D"ltr">
                    <div>Can we fix construction please?&quot; Was adoption=
 a
                      mistake? Maybe, I don&#39;t know.</div>
                  </div>
                </blockquote>
                <div><br>
                </div>
                <div>Yes, that was exactly what I was referring to, and
                  yes, <i>it was a mistake</i>.</div>
                <div><br>
                </div>
              </div>
            </blockquote>
            <div>I still don&#39;t know, that does not change the fact that
              even before that &quot;mistake&quot;, people were using <i>en=
um
                class</i> to create strong typedefs of integral types.</div=
>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>People also used template instantiation to do compile-time
          computations. C++ programmers are willing to use any feature
          for any purpose, so long as it works. That doesn&#39;t mean we
          should enshrine it as the right idea. If people want to do
          compile-time computations, we should give them functions that
          run at compile-time, not make them jump through hoops of type
          instantiation and so forth.</div>
        <div><br>
        </div>
        <div>You&#39;re basically saying, &quot;we have template metaprogra=
mming;
          why not add more to that, instead of bothering with this whole
          `constexpr` function thing?&quot; Or &quot;we have SFINAE; why no=
t add
          more to that, instead of bothering with this whole `requires`
          thing?&quot;</div>
      </div>
    </blockquote>
    I believe all of us want some simplified form to build strong types
    (in particular those based on an underlying type).<br>
    enum class is the closest construct we have in C++17, so it is not
    weird to start from them.<br></div></blockquote><div><br></div><div>Yes=
, it is weird to start from them. Enumerations are strongly typed because i=
t helps prevent errors. It stops you from accidentally using the wrong enum=
erator in the wrong place, and it stops you from accidentally pretending th=
at an integer is an enumerator value. That&#39;s why enumerations are stron=
gly typed.</div><div><br></div><div>That underlying types of enumerations a=
re similar in concept to the relationship between a strong alias and the ty=
pe it is based on is essentially a coincidence. They may be similar in form=
, but they&#39;re completely dissimilar in function.</div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D=
"#000000">Let use another syntax then<br>
    <div><b> new class B : A {};</b></div>
    <br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
          <div dir=3D"ltr">
            <div>We have strong typedefs in C++17.</div>
          </div>
        </blockquote>
        <div><br>
        </div>
      </div>
    </blockquote>
    I wouldn&#39;t use the term strong typedefs, but strong types.<br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>No, we have<i> hacks</i> in C++17.</div>
      </div>
    </blockquote>
    enum class defines a new strong type, different from its underlying
    type. This is not a hack IMO.<br></div></blockquote><div><br></div><div=
>That&#39;s not the hack part. The hack part is allowing `enumeration{integ=
er}` to work on empty enumerations. Normally, to convert an integer to a st=
rong enum type, you have to explicitly do a cast. Constructor syntax explic=
itly is disallowed. Until C++17, where it is allowed for empty enumerations=
..</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div b=
gcolor=3D"#FFFFFF" text=3D"#000000">
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>=C2=A0=C2=A0<br></div></div></blockquote><blockquote type=3D"c=
ite"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div>
            </div>
            <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div dir=3D"ltr">
                <div>For example, if A was Swappable, that means A
                  probably has a non-member `swap` function. </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div><b>enum class B : A {</b></div>
            <div><b>public :</b></div>
            <div><b>=C2=A0 friend void swap(B&amp;, B&amp;) =3D default;<br=
>
              </b></div>
            <div><b>};</b></div>
            <div><br>
            </div>
            <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div dir=3D"ltr">
                <div>Does B automatically get one?</div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>No.</div>
            <div> <br>
            </div>
            <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div dir=3D"ltr">
                <div> Should it? </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>No.</div>
            <div> <br>
            </div>
            <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div dir=3D"ltr">
                <div>If A was addable to integers via non-member
                  `operator+`, should B be addable too?</div>
                <div><br>
                </div>
              </div>
            </blockquote>
            <div>No, but :</div>
            <div><br>
            </div>
            <div>
              <div><b>enum class B : A {</b></div>
              <div><b>public :</b></div>
              <div><b>=C2=A0 friend B operator+(const B&amp;, int) =3D defa=
ult;<br>
                </b></div>
              <div><b>};</b></div>
              <div><br>
              </div>
            </div>
            <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div dir=3D"ltr">
                <div>And if you can&#39;t automatically get the non-member
                  interfaces of A, then what good is B?</div>
              </div>
            </blockquote>
            <div>=C2=A0</div>
            <div>B is a distinct type from A, explicitly convertible to
              and from it. B is stored the same way as A. It is as
              copyable, movable, assignable and destructible as A,
              except the signatures get B in lieu of A.<br>
            </div>
          </div>
        </blockquote>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
    Lets see what can be done today without any new language change.
    There are some libraries proposing some kind of strong type helpers.
    E.g.<br>
    <br>
    <br>
    template &lt;class Tag, class UT =3D int&gt;<br>
    using strong_id =3D new_type&lt;Tag, UT<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , meta_mixin::comparable&lt;&gt;<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , meta_mixin::hashable&lt;&gt;<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , meta_mixin::streamable&lt;&gt;<br>
    &gt;;<br>
    <br>
    would define an identifier that is comparable, hashable and
    streamable. (See
<a onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A=
%2F%2Fgithub.com%2Fviboes%2Fstd-make%2Fblob%2Fmaster%2Finclude%2Fexperiment=
al%2Ffundamental%2Fv3%2Fstrong%2Fstrong_id.hpp\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNHnCJBjotNu1iBzOOuOhCZq5OQUuQ&#39;;return true;" onclick=3D"this=
..href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fvib=
oes%2Fstd-make%2Fblob%2Fmaster%2Finclude%2Fexperimental%2Ffundamental%2Fv3%=
2Fstrong%2Fstrong_id.hpp\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnCJBjotNu=
1iBzOOuOhCZq5OQUuQ&#39;;return true;" href=3D"https://github.com/viboes/std=
-make/blob/master/include/experimental/fundamental/v3/strong/strong_id.hpp"=
 target=3D"_blank" rel=3D"nofollow">https://github.com/viboes/std-<wbr>make=
/blob/master/include/<wbr>experimental/fundamental/v3/<wbr>strong/strong_id=
..hpp</a>
    and the same folder for more examples)<br>
    <br>
    This needs of course the definition of
    meta_mixin::comparable&lt;&gt; that implement via a library the
    =3Ddefault trampolines.<br></div></blockquote><div><br></div><div>The p=
roblem with trampolines is that they&#39;re only half-solutions. They only =
work if you can identify up-front all of the interfaces you want to forward=
..</div><div><br></div><div>The ability to forward arbitrary interfaces is n=
ot available.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">How the new language featur=
e could take in account the ability to
    compose the inherited functionalities?<br>
    I believe metaclasses could help on this, but I have not tried
    anything with.<br>
    <br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>But it&#39;s not actually an alias of `A`, since it cannot do
          what `A` does.</div>
      </div>
    </blockquote>
    Why do you want `B` to be an alias of `A`?<br></div></blockquote><div><=
br></div><div>... because that&#39;s the premise of the discussion. We&#39;=
re talking about the behavior of strong aliases. Therefore, such a discussi=
on involves two types, with one of them being a strong alias of the other.<=
/div><div><br></div><div>I don&#39;t know what you mean with this question.=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF"=
 text=3D"#000000">
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>My point is that C++ has no mechanism to identify free
          functions that are a fundamental part of a class&#39;s interface
          from free functions which are not. And without that, making
          proper strong aliases becomes a maintenance burden. If someone
          adds a new free function interface to A, you have to add a
          `friend` declaration to<i> every</i> strong alias of it in
          order to pick up that behavior.</div>
      </div>
    </blockquote>
    A strong type is a type that defines its operations, independently
    of the operations provided by its representation.<br></div></blockquote=
><div><br></div><div>Then what you are talking about is a <i>subobject</i>,=
 not an alias. A strong alias is a type that behaves to a large degree like=
 an existing type, while still being a distinct type (and thus different fr=
om a `using name =3D type;` alias) that can add new operations or change ex=
isting ones.</div><div><br></div><div>The very concept of an alias is that =
the new typename&#39;s properties are defined primarily by an existing type=
.. With weak aliases, they are the same type with a different name. With str=
ong aliases, they are a distinct type. With subobjects, you&#39;re creating=
 a distinct type, but its relationship with any other type is entirely a ma=
tter of how it is implemented.</div><div><br></div><div>That&#39;s not an a=
lias.<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D=
"#FFFFFF" text=3D"#000000">
  </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/85488fc2-852c-4ffb-b67e-4220662869e9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/85488fc2-852c-4ffb-b67e-4220662869e9=
%40isocpp.org</a>.<br />

------=_Part_30526_392542379.1514651427408--

------=_Part_30525_496949097.1514651427407--

.