Re: [boost] Enums: naming question?

Subject: Re: [boost] Enums: naming question?
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-03-19 05:55:45

On Sat, Mar 19, 2011 at 1:10 AM, Vicente Botet <vicente.botet_at_[hidden]>wrote:

>
> Jeffrey Lee Hellrung, Jr.-2 wrote:
>
[...]

> I don't know why the  template parameter of the trait disappears each time.
> Is the second time I have problems with < and >.
>

:(  My email client (just switched to using gmail) may be removing them...

Your "corrections" you had given look exactly the same as before :/

[...]

> On C++0x there is already the trait underlying_type that is associated to
> the storage. The same trait is used on the Opaque.Strong Types  proposal.
> So
> i will prefer to maintain underlying_type us such. The names I'm not happy
> with are scoping and native.
>

Fair enough.

> > So what's with scoping_type?  In one case, it's the scoped enum, and in
> > the other case, it's the emulated scoped enum, but in both it looks like
> > an
> > identity operation.  I don't get the point.
> >
>
> It is not the identity when the scoped enum is emulated. In any case is the
> type giving scope to the enumerators, this was the reason for the name.
>
> In the emulation scoping of the nested enum is the identity.

This seems to contradict your earlier statement: "It is not the identity
when the scoped enum is emulated."  Can you elaborate?  Do you mean that the
scoping_type maps the "native enum" type of the (emulated) scoped enum back
to the (emulated) scoped enum?  I.e., native_type and scoping_type are
inverse metafunctions?

> With scoped
> enums scoping and enum_type/native_type are identities.
>
> I'm conscientious  that this alternative emulation of enums has a major
> drawback: the emulating type is not an enum and I can understand why others
> have abandoned the idea. I just wanted to explore it in depth to see if the
> whole design had more advantages than liabilities, but I suspect that I've
> not reached it yet.

Actually, what I've seen of the design so far seems very reasonable.  I will
try to take a closer look at the documentation to get a better sense of the
limitations of the emulation.

I guess the thing I'd be worried about is how necessary or in-demand scoped
enums are.  There are clear benefits to them, as evident by their inclusion
in the standard, but emulating it doesn't seem like such a big deal as, for
example, the move/rvalue reference emulation that Boost.Move provides.

As the emulation is not an enum we need some traits to
> get the enum type and vice versa. The same is applicable for the value
> conversion of these type.
>

Sure, makes sense.

- Jeff