Topic: Enum class methods proposal
Author: yanpaso@gmail.com
Date: Sat, 21 May 2016 15:56:57 -0700 (PDT)
Raw View
------=_Part_3222_45277975.1463871417298
Content-Type: multipart/alternative;
boundary="----=_Part_3223_828733226.1463871417298"
------=_Part_3223_828733226.1463871417298
Content-Type: text/plain; charset=UTF-8
High!
Java have excellent features for enums: enums may have both static and
nonstatic methods. If enum class had methods' support, then the name would
be more clear and we would benefit. I suggest only public methods and no
inheritance. Code example:
enum class Direction
{
left
{
Direction opposite(){
return right;
}
},
right
{
Direction opposite(){
return left;
}
}
const char* toString()
{
return "right"; //automatically generated
}
static size_t size()
{
return 2; //automatically generated
}
std::string getString()
{
return std::string(this->toString());
}
std::vector getCollection(); // support for "for each loop" or getting
iterable collection would be graet too :)
};
--
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/c2ea84c3-89e5-4140-b4c7-4a6386432130%40isocpp.org.
------=_Part_3223_828733226.1463871417298
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">High!<div><br></div><div>Java have excellent features for =
enums: enums may have both static and nonstatic methods. If enum class had =
methods' support, then the name would be more clear and we would benefi=
t. I suggest only public methods and no inheritance. Code example:</div><di=
v><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187);=
word-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><div class=3D"subprettyprint=
">enum class Direction</div><div class=3D"subprettyprint">{</div><div class=
=3D"subprettyprint"><span class=3D"Apple-tab-span" style=3D"white-space:pre=
"> </span>left</div><div class=3D"subprettyprint"><span class=3D"Apple-tab-=
span" style=3D"white-space:pre"> </span>{</div><div class=3D"subprettyprint=
"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>Directi=
on opposite(){</div><div class=3D"subprettyprint"><span class=3D"Apple-tab-=
span" style=3D"white-space:pre"> </span>return right;</div><div class=3D"=
subprettyprint"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> =
</span>}</div><div class=3D"subprettyprint"><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"> </span>},</div><div class=3D"subprettyprint"><sp=
an class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>right</div><d=
iv class=3D"subprettyprint"><span class=3D"Apple-tab-span" style=3D"white-s=
pace:pre"> </span>{</div><div class=3D"subprettyprint"><span class=3D"Apple=
-tab-span" style=3D"white-space:pre"> </span>Direction opposite(){</div><d=
iv class=3D"subprettyprint"><span class=3D"Apple-tab-span" style=3D"white-s=
pace:pre"> </span>return left;</div><div class=3D"subprettyprint"><span c=
lass=3D"Apple-tab-span" style=3D"white-space:pre"> </span>}</div><div clas=
s=3D"subprettyprint"><span class=3D"Apple-tab-span" style=3D"white-space:pr=
e"> </span>}</div><div class=3D"subprettyprint"><span class=3D"Apple-tab-sp=
an" style=3D"white-space:pre"> </span>const char* toString()</div><div clas=
s=3D"subprettyprint"><span class=3D"Apple-tab-span" style=3D"white-space:pr=
e"> </span>{</div><div class=3D"subprettyprint"><span class=3D"Apple-tab-sp=
an" style=3D"white-space:pre"> </span>return "right"; //automati=
cally generated</div><div class=3D"subprettyprint"><span class=3D"Apple-tab=
-span" style=3D"white-space:pre"> </span>}</div><div class=3D"subprettyprin=
t"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>static =
size_t size()</div><div class=3D"subprettyprint"><span class=3D"Apple-tab-s=
pan" style=3D"white-space:pre"> </span>{</div><div class=3D"subprettyprint"=
><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>return 2=
; //automatically generated</div><div class=3D"subprettyprint"><span class=
=3D"Apple-tab-span" style=3D"white-space:pre"> </span>}</div><div class=3D"=
subprettyprint"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> <=
/span>std::string getString()</div><div class=3D"subprettyprint"><span clas=
s=3D"Apple-tab-span" style=3D"white-space:pre"> </span>{</div><div class=3D=
"subprettyprint"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> =
</span>return std::string(this->toString());</div><div class=3D"subpret=
typrint"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>}=
<br><span class=3D"Apple-tab-span" style=3D"white-space: pre;"> </span>std:=
:vector getCollection(); // support for "for each loop" or gettin=
g iterable collection would be graet too :)<br></div><div class=3D"subprett=
yprint">};</div></div></code></div><div><br></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/c2ea84c3-89e5-4140-b4c7-4a6386432130%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c2ea84c3-89e5-4140-b4c7-4a6386432130=
%40isocpp.org</a>.<br />
------=_Part_3223_828733226.1463871417298--
------=_Part_3222_45277975.1463871417298--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 21 May 2016 20:43:56 -0700 (PDT)
Raw View
------=_Part_806_893226989.1463888636218
Content-Type: multipart/alternative;
boundary="----=_Part_807_210706322.1463888636218"
------=_Part_807_210706322.1463888636218
Content-Type: text/plain; charset=UTF-8
OK, what you've done here is stick two proposals together for no good
reason.
If we want to have the ability to convert an enumerator into a string, or
to get the "size" of an enum, those should be things that work just as well
on non-class `enum`s as `enum class`.
Also, those things should be *constexpr*. This is 2016; let's stop treating
constexpr like it's something experimental.
The other proposal is adding member functions to `enum classes`.
Personally, I see no need for this. Is there a reason why these can't just
be namespace-scoped functions? With the exception of adding member
functions to the actual enumerators (which is insane), you don't really
benefit from making these things class members.
--
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/9fa5abf0-cc17-4e68-b5e9-7b06b746ab02%40isocpp.org.
------=_Part_807_210706322.1463888636218
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">OK, what you've done here is stick two proposals toget=
her for no good reason.<br><br>If we want to have the ability to convert an=
enumerator into a string, or to get the "size" of an enum, those=
should be things that work just as well on non-class `enum`s as `enum clas=
s`.<br><br>Also, those things should be <i>constexpr</i>. This is 2016; let=
's stop treating constexpr like it's something experimental.<br><br=
>The other proposal is adding member functions to `enum classes`. Personall=
y, I see no need for this. Is there a reason why these can't just be na=
mespace-scoped functions? With the exception of adding member functions to =
the actual enumerators (which is insane), you don't really benefit from=
making these things class members.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/9fa5abf0-cc17-4e68-b5e9-7b06b746ab02%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9fa5abf0-cc17-4e68-b5e9-7b06b746ab02=
%40isocpp.org</a>.<br />
------=_Part_807_210706322.1463888636218--
------=_Part_806_893226989.1463888636218--
.
Author: jensa <jens.muaddib@gmail.com>
Date: Mon, 23 May 2016 02:24:51 -0700 (PDT)
Raw View
------=_Part_1656_529633666.1463995491936
Content-Type: multipart/alternative;
boundary="----=_Part_1657_1162834518.1463995491937"
------=_Part_1657_1162834518.1463995491937
Content-Type: text/plain; charset=UTF-8
Being able to have methods in enums would help the IDE to provide
reasonable suggestions when typing a name of an enum variable. I think C++
would benefit a lot from being more tool-friendly.
Cheers,
Jens
Am Sonntag, 22. Mai 2016 05:43:56 UTC+2 schrieb Nicol Bolas:
>
> OK, what you've done here is stick two proposals together for no good
> reason.
>
> If we want to have the ability to convert an enumerator into a string, or
> to get the "size" of an enum, those should be things that work just as well
> on non-class `enum`s as `enum class`.
>
> Also, those things should be *constexpr*. This is 2016; let's stop
> treating constexpr like it's something experimental.
>
> The other proposal is adding member functions to `enum classes`.
> Personally, I see no need for this. Is there a reason why these can't just
> be namespace-scoped functions? With the exception of adding member
> functions to the actual enumerators (which is insane), you don't really
> benefit from making these things class members.
>
--
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/a84a65ee-c920-4613-9ea0-41889ab9b7a6%40isocpp.org.
------=_Part_1657_1162834518.1463995491937
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Being able to have methods in enums would help the IDE to =
provide reasonable suggestions when typing a name of an enum variable. I th=
ink C++ would benefit a lot from being more tool-friendly.<br><br>Cheers,<b=
r>=C2=A0 Jens<br><br>Am Sonntag, 22. Mai 2016 05:43:56 UTC+2 schrieb Nicol =
Bolas:<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">OK, wha=
t you've done here is stick two proposals together for no good reason.<=
br><br>If we want to have the ability to convert an enumerator into a strin=
g, or to get the "size" of an enum, those should be things that w=
ork just as well on non-class `enum`s as `enum class`.<br><br>Also, those t=
hings should be <i>constexpr</i>. This is 2016; let's stop treating con=
stexpr like it's something experimental.<br><br>The other proposal is a=
dding member functions to `enum classes`. Personally, I see no need for thi=
s. Is there a reason why these can't just be namespace-scoped functions=
? With the exception of adding member functions to the actual enumerators (=
which is insane), you don't really benefit from making these things cla=
ss members.<br></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/a84a65ee-c920-4613-9ea0-41889ab9b7a6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a84a65ee-c920-4613-9ea0-41889ab9b7a6=
%40isocpp.org</a>.<br />
------=_Part_1657_1162834518.1463995491937--
------=_Part_1656_529633666.1463995491936--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 23 May 2016 08:01:19 -0700 (PDT)
Raw View
------=_Part_1409_959620681.1464015679386
Content-Type: multipart/alternative;
boundary="----=_Part_1410_1876271739.1464015679386"
------=_Part_1410_1876271739.1464015679386
Content-Type: text/plain; charset=UTF-8
On Monday, May 23, 2016 at 5:24:52 AM UTC-4, jensa wrote:
>
> Being able to have methods in enums would help the IDE to provide
> reasonable suggestions when typing a name of an enum variable. I think C++
> would benefit a lot from being more tool-friendly.
>
I use and appreciate auto-completion. However, I would much rather we have
a generalize transformation of `x.Y()` into `Y(x)` (aka: the original
impetus of Unified Call Syntax... which they ditched) than to add this
narrow feature to enum classes. That would fix this problem for enum
classes, non-class enums, and *every other type* where you want to
externally add to the public interface and still get auto-completion.
--
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/f95f5860-87b6-44b4-a48f-240dfa2eec7c%40isocpp.org.
------=_Part_1410_1876271739.1464015679386
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, May 23, 2016 at 5:24:52 AM UTC-4, jensa wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Being able to =
have methods in enums would help the IDE to provide reasonable suggestions =
when typing a name of an enum variable. I think C++ would benefit a lot fro=
m being more tool-friendly.</div></blockquote><div><br>I use and appreciate=
auto-completion. However, I would much rather we have a generalize transfo=
rmation of `x.Y()` into `Y(x)` (aka: the original impetus of Unified Call S=
yntax... which they ditched) than to add this narrow feature to enum classe=
s. That would fix this problem for enum classes, non-class enums, and <i>ev=
ery other type</i> where you want to externally add to the public interface=
and still get auto-completion.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/f95f5860-87b6-44b4-a48f-240dfa2eec7c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f95f5860-87b6-44b4-a48f-240dfa2eec7c=
%40isocpp.org</a>.<br />
------=_Part_1410_1876271739.1464015679386--
------=_Part_1409_959620681.1464015679386--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 23 May 2016 10:21:48 -0500
Raw View
--001a1143ce7c1cdb5d0533840200
Content-Type: text/plain; charset=UTF-8
On 23 May 2016 at 10:01, Nicol Bolas <jmckesson@gmail.com> wrote:
> Being able to have methods in enums would help the IDE to provide
>> reasonable suggestions when typing a name of an enum variable. I think C++
>> would benefit a lot from being more tool-friendly.
>>
>
> I use and appreciate auto-completion. However, I would much rather we have
> a generalize transformation of `x.Y()` into `Y(x)` (aka: the original
> impetus of Unified Call Syntax... which they ditched) than to add this
> narrow feature to enum classes. That would fix this problem for enum
> classes, non-class enums, and *every other type* where you want to
> externally add to the public interface and still get auto-completion.
>
Unlike the claims made in that original Unified Call Syntax paper, doing
this would likely be IDE-hostile, as you'd be going from a closed set of
member functions to including an open set of free functions, especially
unconstrained templates. This was one of the arguments made against that
original proposal.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
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/CAGg_6%2BNZ8-4oAukwLKX3P77G9QBUMx6SmKcKqOw2%2B7mM1DqJqQ%40mail.gmail.com.
--001a1143ce7c1cdb5d0533840200
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 23 May 2016 at 10:01, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailt=
o:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span>=
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Being able to hav=
e methods in enums would help the IDE to provide reasonable suggestions whe=
n typing a name of an enum variable. I think C++ would benefit a lot from b=
eing more tool-friendly.</div></blockquote></span><div><br>I use and apprec=
iate auto-completion. However, I would much rather we have a generalize tra=
nsformation of `x.Y()` into `Y(x)` (aka: the original impetus of Unified Ca=
ll Syntax... which they ditched) than to add this narrow feature to enum cl=
asses. That would fix this problem for enum classes, non-class enums, and <=
i>every other type</i> where you want to externally add to the public inter=
face and still get auto-completion.</div></div></blockquote><div>=C2=A0</di=
v></div>Unlike the claims made in that original Unified Call Syntax paper, =
doing this would likely be IDE-hostile, as you'd be going from a closed=
set of member functions to including an open set of free functions, especi=
ally unconstrained templates.=C2=A0 This was one of the arguments made agai=
nst that original proposal.<br>-- <br><div class=3D"gmail_signature"><div d=
ir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=
=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">=
nevin@eviloverlord.com</a>> =C2=A0+1-847-691-1404</div></div></div></div=
></div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAGg_6%2BNZ8-4oAukwLKX3P77G9QBUMx6SmK=
cKqOw2%2B7mM1DqJqQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNZ8-=
4oAukwLKX3P77G9QBUMx6SmKcKqOw2%2B7mM1DqJqQ%40mail.gmail.com</a>.<br />
--001a1143ce7c1cdb5d0533840200--
.