------=_Part_3895_726651581.1456000127248
Content-Type: multipart/alternative;
 boundary="----=_Part_3896_1760875957.1456000127248"

------=_Part_3896_1760875957.1456000127248
Content-Type: text/plain; charset=UTF-8

p0138r1 (http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0138r1.pdf)
proposes that C++ loosen the conversion rules for the strong enum feature
for enums with no values. The use case involves some of the "warts" with
using strong enums as an opaque typedef for integral types, e.g.

enum class foo : uint32 {};

void stuff(foo);



stuff(foo{42}); // required today



stuff({42}); // doesn't work today; p0138 proposes to make this work

The proposal claims that this change is orthogonal to opaque typedefs,  yet
its only motivating use case is to lessen the burden of not having opaque
typedefs.

My primary worry is that the proposal is weaking strong enums for the wrong
reasons.

A secondary worry is that the proposal as worded does not even actually
solve the perceived problem for many existing variants of the trick. The
strong enum trick often (in my experience) comes in a slightly different
form:

enum class foo : uint32 { none = 0; };

void stuff(foo = foo::none); // to avoid the same problem p0138 is trying
to avoid

stuff({42}); // doesn't work today, and still won't work under p0138 as
enum foo has an enumeration value


Existing hacks for the strong enum abuse that exist today breaks the
proposed "hack" presented by p0138.

I'm not outright opposed to this change to strong enums, but it seems to me
to be a change with fairly poor motivation.

I'd personally prefer that we just consider the above strong enum trick
what it really is: an abuse of an unrelated language feature motivated by
the continued lack of true opaque typedefs.

--
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/107c99b2-54d3-4163-9182-525a4c812f89%40isocpp.org.

------=_Part_3896_1760875957.1456000127248
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">p0138r1 (http://open-std.org/JTC1/SC22/WG21/docs/papers/20=
16/p0138r1.pdf) proposes that C++ loosen the conversion rules for the stron=
g enum feature for enums with no values. The use case involves some of the =
&quot;warts&quot; with using strong enums as an opaque typedef for integral=
 types, e.g.<br><div><br></div><blockquote style=3D"margin: 0 0 0 40px; bor=
der: none; padding: 0px;"><div>enum class foo : uint32 {};</div><div><br></=
div><div>void stuff(foo);</div></blockquote><div>=C2=A0</div><blockquote st=
yle=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>stuff(foo{42})=
; // required today =C2=A0</div></blockquote><div>=C2=A0</div><blockquote s=
tyle=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>stuff({42}); =
// doesn&#39;t work today; p0138 proposes to make this work</div><div><br><=
/div></blockquote><div>The proposal claims that this change is orthogonal t=
o opaque typedefs, =C2=A0yet its only motivating use case is to lessen the =
burden of not having opaque typedefs.</div><div><br></div><div>My primary w=
orry is that the proposal is weaking strong enums for the wrong reasons.</d=
iv><div><br></div><div>A secondary worry is that the proposal as worded doe=
s not even actually solve the perceived problem for many existing variants =
of the trick. The strong enum trick often (in my experience) comes in a sli=
ghtly different form:</div><div><br></div><blockquote style=3D"margin: 0 0 =
0 40px; border: none; padding: 0px;"><div>enum class foo : uint32 { none =
=3D 0; };</div><div><br></div><div>void stuff(foo =3D foo::none); // to avo=
id the same problem p0138 is trying to avoid</div><div><br></div><div>stuff=
({42}); // doesn&#39;t work today, and still won&#39;t work under p0138 as =
enum foo has an enumeration value</div></blockquote><div><br></div><div>Exi=
sting hacks for the strong enum abuse that exist today breaks the proposed =
&quot;hack&quot; presented by p0138.</div><div><br></div><div>I&#39;m not o=
utright opposed to this change to strong enums, but it seems to me to be a =
change with fairly poor motivation.</div><div><br></div><div>I&#39;d person=
ally prefer that we just consider the above strong enum trick what it reall=
y is: an abuse of an unrelated language feature motivated by the continued =
lack of true opaque typedefs.<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/107c99b2-54d3-4163-9182-525a4c812f89%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/107c99b2-54d3-4163-9182-525a4c812f89=
%40isocpp.org</a>.<br />

------=_Part_3896_1760875957.1456000127248--
------=_Part_3895_726651581.1456000127248--

.

------=_Part_5272_1219553479.1456004293760
Content-Type: multipart/alternative;
 boundary="----=_Part_5273_1302195354.1456004293760"

------=_Part_5273_1302195354.1456004293760
Content-Type: text/plain; charset=UTF-8

On Saturday, February 20, 2016 at 3:28:47 PM UTC-5, Sean Middleditch wrote:
>
> I'd personally prefer that we just consider the above strong enum trick
> what it really is: an abuse of an unrelated language feature motivated by
> the continued lack of true opaque typedefs.
>

I'm in complete agreement, but the committee seems to not mind this sort of
thing, in the absence of strong typedefs. Sadly, nobody seems to be able to
agree on an approach to making actual strong typedefs, so this abuse is
probably the best we'll get.

--
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/7cf0b8e3-1112-4c50-8758-a2708b314ebc%40isocpp.org.

------=_Part_5273_1302195354.1456004293760
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, February 20, 2016 at 3:28:47 PM UTC-5, Sean M=
iddleditch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div></div><div>I&#39;d personally prefer that we just consider the abo=
ve strong enum trick what it really is: an abuse of an unrelated language f=
eature motivated by the continued lack of true opaque typedefs.<br></div></=
div></blockquote><div><br>I&#39;m in complete agreement, but the committee =
seems to not mind this sort of thing, in the absence of strong typedefs. Sa=
dly, nobody seems to be able to agree on an approach to making actual stron=
g typedefs, so this abuse is probably the best we&#39;ll get. <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/7cf0b8e3-1112-4c50-8758-a2708b314ebc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7cf0b8e3-1112-4c50-8758-a2708b314ebc=
%40isocpp.org</a>.<br />

------=_Part_5273_1302195354.1456004293760--
------=_Part_5272_1219553479.1456004293760--

.

On 20 February 2016 at 23:38, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Saturday, February 20, 2016 at 3:28:47 PM UTC-5, Sean Middleditch wrote:
>>
>> I'd personally prefer that we just consider the above strong enum trick
>> what it really is: an abuse of an unrelated language feature motivated by
>> the continued lack of true opaque typedefs.
>
>
> I'm in complete agreement, but the committee seems to not mind this sort of
> thing, in the absence of strong typedefs. Sadly, nobody seems to be able to
> agree on an approach to making actual strong typedefs, so this abuse is
> probably the best we'll get.


Correct. In the Evolution discussion about that proposal, it was suggested that
strong typedefs would be an alternative solution to the problem. Such
suggestions
were rejected, because none of the strong typedef proposals have thus far been
acceptable to Evolution.

--
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/CAFk2RUbi%2BLR0UdAmGhZNqcins5JuHxQVu4QGi0uZ48EzG5qf0A%40mail.gmail.com.

.

On Sat, Feb 20, 2016 at 1:41 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> Correct. In the Evolution discussion about that proposal, it was suggested that
> strong typedefs would be an alternative solution to the problem. Such
> suggestions
> were rejected, because none of the strong typedef proposals have thus far been
> acceptable to Evolution.

Does that that EWG has set precedent that small tweaks to make such
short-sighted misuses more ergonomic are worthwhile?


I personally am starting to notice a lot more fallout from the
increased pace of C++ standard development and under-baked language or
library changes, and am increasingly in strong favor of a far more
granular approach to C++ evolution.

I'd be way more okay with p0138 for example if anyone wanting the
feature had to declare `using experimental::p138r1;` in any scopes
utilizing the syntax change.

Basically, I really really like HTML5's or Rust's per-feature opt-in
mechanism for experiemental/"unstable" evolutions... that approach
makes it a lot safer to quickly evolve and gather wide implementation
and user feedback without getting stuck with insufficiently
battle-tested designs. Far more so than the very coarse-grained "all
or nothing" -std=c++1z implementation approach or the Technical
Specification approach as those are only practical for "chunky"
changes like Modules or Concepts or big rolled-up balls like Library
Fundamentals.

And wow did I ever just veer off-topic. Squirrel-brain strikes again.

>
> --
> You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/C9dRIVwxTZ0/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CAFk2RUbi%2BLR0UdAmGhZNqcins5JuHxQVu4QGi0uZ48EzG5qf0A%40mail.gmail.com.



--
Sean Middleditch
http://seanmiddleditch.com

--
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/CALQmNFgK9%3DEK82zg2Nyv6xXq8mCXfXsvG04hXMD3cR3FVNBEcQ%40mail.gmail.com.

.

On 20 February 2016 at 23:59, Sean Middleditch <sean@middleditch.us> wrote:
> On Sat, Feb 20, 2016 at 1:41 PM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>> Correct. In the Evolution discussion about that proposal, it was suggested that
>> strong typedefs would be an alternative solution to the problem. Such
>> suggestions
>> were rejected, because none of the strong typedef proposals have thus far been
>> acceptable to Evolution.
>
> Does that that EWG has set precedent that small tweaks to make such
> short-sighted misuses more ergonomic are worthwhile?

Not in general, no.

> I personally am starting to notice a lot more fallout from the
> increased pace of C++ standard development and under-baked language or
> library changes, and am increasingly in strong favor of a far more
> granular approach to C++ evolution.

That is a valid concern that we must watch for.

> I'd be way more okay with p0138 for example if anyone wanting the
> feature had to declare `using experimental::p138r1;` in any scopes
> utilizing the syntax change.

Changing the language dialect per-namespace or via some other such
mechanics has been floated as an idea, but never proposed. The response
to such ideas was not welcoming.

> Basically, I really really like HTML5's or Rust's per-feature opt-in
> mechanism for experiemental/"unstable" evolutions... that approach
> makes it a lot safer to quickly evolve and gather wide implementation
> and user feedback without getting stuck with insufficiently
> battle-tested designs. Far more so than the very coarse-grained "all

Or python's "from __future__ import". Such mechanisms don't work all
that well for getting wide user feedback, actually. And I somewhat doubt
they work all that much better than using a -std=c++1z, coarse as that
is. And hey, you can always use -std=c++1z on a per-file basis. I know,
it has its problems.

--
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/CAFk2RUawjKPEs8q_3ffuXvOpcndSh%2BV2Jqq4bAq3VGwCP9X7yA%40mail.gmail.com.

.

------=_Part_5145_295448877.1456006597170
Content-Type: multipart/alternative;
 boundary="----=_Part_5146_1997462290.1456006597170"

------=_Part_5146_1997462290.1456006597170
Content-Type: text/plain; charset=UTF-8

On Saturday, February 20, 2016 at 4:59:48 PM UTC-5, Sean Middleditch wrote:
>
> On Sat, Feb 20, 2016 at 1:41 PM, Ville Voutilainen
> <ville.vo...@gmail.com <javascript:>> wrote:
> > Correct. In the Evolution discussion about that proposal, it was
> suggested that
> > strong typedefs would be an alternative solution to the problem. Such
> > suggestions
> > were rejected, because none of the strong typedef proposals have thus
> far been
> > acceptable to Evolution.
>
> Does that that EWG has set precedent that small tweaks to make such
> short-sighted misuses more ergonomic are worthwhile?
>
>
> I personally am starting to notice a lot more fallout from the
> increased pace of C++ standard development and under-baked language or
> library changes, and am increasingly in strong favor of a far more
> granular approach to C++ evolution.
>
> I'd be way more okay with p0138 for example if anyone wanting the
> feature had to declare `using experimental::p138r1;` in any scopes
> utilizing the syntax change.
>
> Basically, I really really like HTML5's or Rust's per-feature opt-in
> mechanism for experiemental/"unstable" evolutions... that approach
> makes it a lot safer to quickly evolve and gather wide implementation
> and user feedback without getting stuck with insufficiently
> battle-tested designs. Far more so than the very coarse-grained "all
> or nothing" -std=c++1z implementation approach or the Technical
> Specification approach as those are only practical for "chunky"
> changes like Modules or Concepts or big rolled-up balls like Library
> Fundamentals.
>

I think the problem with that approach is that people will write code that
depends on it.

Your HTML5 pretty much stands alone. It's yours, on your website, generated
by your server-side scripts. So you decide what to use and what not to use;
that's between you and your users.

C++ is used for libraries in many cases. Some products are an amalgam of
dozens of different projects. So if one of those chooses to use a small,
optional feature of C++... everyone else has to as well (if the project
isn't shipped as a DLL/SO). And if you can't afford to make everyone do
that, then the feature may as well not exist.

It's hard enough to deal with the fragmentation that the current TS system
is giving. Adding fine-grained features like that will only make it worse.

--
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/7dfb5924-762a-4241-ab1b-3bc5d79936c2%40isocpp.org.

------=_Part_5146_1997462290.1456006597170
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, February 20, 2016 at 4:59:48 PM UTC-5, Sean M=
iddleditch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Sat, Feb 2=
0, 2016 at 1:41 PM, Ville Voutilainen
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
WDkTF4oqAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">ville.vo...@gmail.com</a>&gt; wrote:
<br>&gt; Correct. In the Evolution discussion about that proposal, it was s=
uggested that
<br>&gt; strong typedefs would be an alternative solution to the problem. S=
uch
<br>&gt; suggestions
<br>&gt; were rejected, because none of the strong typedef proposals have t=
hus far been
<br>&gt; acceptable to Evolution.
<br>
<br>Does that that EWG has set precedent that small tweaks to make such
<br>short-sighted misuses more ergonomic are worthwhile?
<br>
<br>
<br>I personally am starting to notice a lot more fallout from the
<br>increased pace of C++ standard development and under-baked language or
<br>library changes, and am increasingly in strong favor of a far more
<br>granular approach to C++ evolution.
<br>
<br>I&#39;d be way more okay with p0138 for example if anyone wanting the
<br>feature had to declare `using experimental::p138r1;` in any scopes
<br>utilizing the syntax change.
<br>
<br>Basically, I really really like HTML5&#39;s or Rust&#39;s per-feature o=
pt-in
<br>mechanism for experiemental/&quot;unstable&quot; evolutions... that app=
roach
<br>makes it a lot safer to quickly evolve and gather wide implementation
<br>and user feedback without getting stuck with insufficiently
<br>battle-tested designs. Far more so than the very coarse-grained &quot;a=
ll
<br>or nothing&quot; -std=3Dc++1z implementation approach or the Technical
<br>Specification approach as those are only practical for &quot;chunky&quo=
t;
<br>changes like Modules or Concepts or big rolled-up balls like Library
<br>Fundamentals.
<br></blockquote><div><br>I think the problem with that approach is that pe=
ople will write code that depends on it.<br><br>Your HTML5 pretty much stan=
ds alone. It&#39;s yours, on your website, generated by your server-side sc=
ripts. So you decide what to use and what not to use; that&#39;s between yo=
u and your users.<br><br>C++ is used for libraries in many cases. Some prod=
ucts are an amalgam of dozens of different projects. So if one of those cho=
oses to use a small, optional feature of C++... everyone else has to as wel=
l (if the project isn&#39;t shipped as a DLL/SO). And if you can&#39;t affo=
rd to make everyone do that, then the feature may as well not exist.<br><br=
>It&#39;s hard enough to deal with the fragmentation that the current TS sy=
stem is giving. Adding fine-grained features like that will only make it wo=
rse.</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/7dfb5924-762a-4241-ab1b-3bc5d79936c2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7dfb5924-762a-4241-ab1b-3bc5d79936c2=
%40isocpp.org</a>.<br />

------=_Part_5146_1997462290.1456006597170--
------=_Part_5145_295448877.1456006597170--

.

On 21 February 2016 at 00:16, Nicol Bolas <jmckesson@gmail.com> wrote:
> It's hard enough to deal with the fragmentation that the current TS system
> is giving. Adding fine-grained features like that will only make it worse.


Correct. That's one of the usual not-welcoming responses to such ideas.

--
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/CAFk2RUa39WGgVJNg%2B7%2BV1HnARUJVd3ZvpSRTd_PJ0NWvcUZhbg%40mail.gmail.com.

.

On Sat, Feb 20, 2016 at 2:19 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 21 February 2016 at 00:16, Nicol Bolas <jmckesson@gmail.com> wrote:
>> It's hard enough to deal with the fragmentation that the current TS system
>> is giving. Adding fine-grained features like that will only make it worse.
>
>
> Correct. That's one of the usual not-welcoming responses to such ideas.

I'm not convinced, but I understand the trepidation.

The TS approach runs back into "it's not opt-in." And when it is, it's
done on the command line with a compiler switch, not necessarily
encoded in the source (with big blazing "enable experimental" syntax),
or limited to pure additions (std::experimental::optional) versus
tweaks or deprecations.

And in any event, modules reduce (though they don't eliminate) the
"infectious" nature of such experiments for libraries. Besides, in
real-world experience, libraries are even more likely to be
ultra-convservative since their users are on such a wide diversity of
platforms (to the point that an application is sometimes restricted
from using modern C++ features in some contexts because the library
interacts poorly, e.g. libraries that use continue to use callback
classes instead of "modern" std::function, barring use of lambdas for
callbacks).

Not that I have any plans to write a paper on this anytime soon. I
barely have time for writing emails about the mere thought. :)


Back on topic, I just dislike the idea of short-term hacks to enum
class for questionable purposes. It's potentially just adding changes
that will be seen as cruft and an anachronism in the (hopefully)
not-too-distant future.

--
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/CALQmNFgvHmUy7CvFwvQiVsT%3DPToorhLwbJpebXYdvKAY7_bYKw%40mail.gmail.com.

.

On 21 February 2016 at 00:30, Sean Middleditch <sean@middleditch.us> wrote:
> Back on topic, I just dislike the idea of short-term hacks to enum
> class for questionable purposes. It's potentially just adding changes
> that will be seen as cruft and an anachronism in the (hopefully)
> not-too-distant future.


Evolution disagreed on whether it's a hack for questionable purposes. ;)

--
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/CAFk2RUaW0m_KjtkXJ6Loge5-oE%2BGtgWebFt_X%3D6NCY%2Be0%2Bo-ew%40mail.gmail.com.

.

On Sat, Feb 20, 2016 at 4:36 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 21 February 2016 at 00:30, Sean Middleditch <sean@middleditch.us> wrote:
>> Back on topic, I just dislike the idea of short-term hacks to enum
>> class for questionable purposes. It's potentially just adding changes
>> that will be seen as cruft and an anachronism in the (hopefully)
>> not-too-distant future.
>
>
> Evolution disagreed on whether it's a hack for questionable purposes. ;)

I'm not sure whether it's a hack, but it does not fulfill the need
of an SI units library.  For example, there is no strong enum for
floating points.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

--
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/CAGsORuAnr610%2BAUyfw3Y%3D_8q8grD3_4A_3bxwPCf7hzunL8X9A%40mail.gmail.com.

.

On 21 February 2016 at 00:53, Zhihao Yuan <zy@miator.net> wrote:
> I'm not sure whether it's a hack, but it does not fulfill the need
> of an SI units library.  For example, there is no strong enum for

It wasn't intended to fulfill that need.

--
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/CAFk2RUYv7OsKA5Z5wc_Y3-7UM-mhoYSeixJ%2BOVy93%3DSuOqpYUA%40mail.gmail.com.

.