I think this may be a good idea, but there's also a reasonable library
solution for this:

enum class A {
  X, Y
};

template<typename F>
struct Lo {
   Lo(F f):f(f) { }

   template<typename T>
   operator T() { return f(T{}); }

   F f;
};

template<typename F>
Lo<F> make_Lo(F f) { return { f }; }

#define L(N) make_Lo([](auto E) { return decltype(E)::N; })

A a = L(X), b = L(Y);

I would also like to have this feature for case-labels of switches
over the enumeration. Actually, I would much more like this feature
there, since it's much less dangerous there IMO.


2017-02-07 7:12 GMT+01:00 Brian Bi <bbi5291@gmail.com>:
> For example, should the following code be made well-formed?
>
> enum class Color {
>     RED,
>     GREEN,
>     BLUE,
> };
>
> Color color = RED;
>
> It seems that some code could be broken by this change, since RED could be
> the name of a variable declared somewhere else, but this is probably rare.
>
> --
> Brian Bi
>
> --
> 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/CAMmfjbP44DFNHwVogEBL%2BLHjRXrK2hOZH-5LQLgVDmK%3DJSoqcg%40mail.gmail.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/CANu6V4XiZG2q_rqhhTi7S%3DTb3qptv0PC0kSHsCHU_1nPL--yiw%40mail.gmail.com.

.

On 2017-02-07 01:12, Brian Bi wrote:
> For example, should the following code be made well-formed?
>
> enum class Color {
>     RED,
>     GREEN,
>     BLUE,
> };
>
> Color color = RED;

Not by itself, no. In general, *YES PLEASE*!

My biggest hatred of strongly typed enums, and why I rarely use them, is
that they conflated two orthogonal features: implicit conversion (i.e.
that they *don't* implicitly convert), and scoping of the enumeration
values.

Fortunately, C++11 made it legal to name enumerators by their containing
enumeration for both "classic" and "strongly typed" enumerations, which
lessens the need for weakly-typed, strongly-scoped enumerations.
However, there is as yet no good solution for strongly-typed,
weakly-scoped enumerations, despite a fairly common desire for such
critters.

I'd like to see something like `using enum Color` to make the
enumerators of a named enumeration available in a different scope.

Note that this would not be *just* the parent scope. For example:

  namespace zoo {
    enum class Animal { Dog, Cat, Cow, Pig };
  }
  namespace farm { using enum ::zoo::Animal; }

  auto x = farm::Dog; // okay; decltype(x) == ::zoo::Animal

--
Matthew

--
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/5899F95E.8060407%40gmail.com.

.

------=_Part_1333_1089318693.1551190664806
Content-Type: multipart/alternative;
 boundary="----=_Part_1334_1561241124.1551190664806"

------=_Part_1334_1561241124.1551190664806
Content-Type: text/plain; charset="UTF-8"

I use enums quite a bit in my code as it is nice to have strongly typed
values used for passing to functions and switching.

I'd like to propose the following as the name of such code:
Argument Dependent Name Lookup for Strongly Typed Enums

ADNL is already used for variables and methods within the current scope
such as inside the same class or namespace,
but enums are still a case where the scope strongly suggests that the value
should be a member of an enum, yet must still be fully qualified.

Let me give a few examples:

enum class SpacialUnit {
    Inch,
    Millimeter,
    Point,
    Pixel,
};


// assignment to a variable cannot be anything other than the type of the
variable
SpacialUnit unit = Inch;


// passing to a function that requires that type
Translate(10, Inch);
// where Translate is declared:
void Translate(int, SpacialUnit);


// returning from a function that declares that type
SpacialUnit GetUnit() {
    return Inch;
}


// switching on a variable of that type
SpacialUnit unit;
switch (unit) {
    case Inch: break;
    case Millimeter: break;
}


// passing as a constexpr value to a template that declares argument type
template <SpacialUnit unit>
class Rectangle {
    ...
};

Rectangle<Inch> saeRect;


In every single one of those cases mentioned above, there is no other
possible value besides a member of the enum that can be accepted without
explicit casting.
So why should we be required to qualify the enum name in these cases?

--
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/f2442186-7637-487d-ba01-919b6ef9f3e7%40isocpp.org.

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

<div dir=3D"ltr">I use enums quite a bit in my code as it is nice to have s=
trongly typed values used for passing to functions and switching.<div><br><=
/div><div>I&#39;d like to propose the following as the name of such code:</=
div><div>Argument Dependent Name Lookup for Strongly Typed Enums<br></div><=
div><br></div><div>ADNL is already used for variables and methods within th=
e current scope such as inside the same class or namespace,</div><div>but e=
nums are still a case where the scope strongly suggests that the value shou=
ld be a member of an enum, yet must still be fully qualified.</div><div><br=
></div><div>Let me give a few examples:</div><div><br></div><div><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-wra=
p: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><=
span style=3D"color: #008;" class=3D"styled-by-prettify">enum</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" c=
lass=3D"styled-by-prettify">SpacialUnit</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">=C2=A0</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Inch</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #606;" class=3D"sty=
led-by-prettify">Millimeter</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span></div><div class=3D"subprettyprint"><span style=3D=
"" class=3D"styled-by-prettify"><font color=3D"#666600">=C2=A0 =C2=A0 Point=
,<br>=C2=A0 =C2=A0 Pixel,<br></font></span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">};<br><br><br>// assignment to a variable cannot =
be anything other than the type of the variable<br>SpacialUnit unit =3D Inc=
h;<br><br><br>// passing to a function that requires that type<br>Translate=
(10, Inch);<br>// where Translate is declared:<br>void Translate(int, Spaci=
alUnit);<br><br><br>// returning from a function that declares that type<br=
>SpacialUnit GetUnit() {<br>=C2=A0 =C2=A0 return Inch;<br>}<br><br><br>// s=
witching on a variable of that type<br>SpacialUnit unit;<br>switch (unit) {=
<br>=C2=A0 =C2=A0 case Inch: break;<br>=C2=A0 =C2=A0 case Millimeter: break=
;<br>}<br><br><br>// passing as a constexpr value to a template that declar=
es argument type<br>template &lt;SpacialUnit unit&gt;<br>class Rectangle {<=
br>=C2=A0 =C2=A0 ...<br>};<br><br>Rectangle&lt;Inch&gt; saeRect;<br><br></s=
pan></div></code></div><br>In every single one of those cases mentioned abo=
ve, there is no other possible value besides a member of the enum that can =
be accepted without explicit casting.</div><div>So why should we be require=
d to qualify the enum name in these cases?</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/f2442186-7637-487d-ba01-919b6ef9f3e7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f2442186-7637-487d-ba01-919b6ef9f3e7=
%40isocpp.org</a>.<br />

------=_Part_1334_1561241124.1551190664806--

------=_Part_1333_1089318693.1551190664806--

.