Private enum members + Descent

[Yigal Chripun]

On 24/10/2009 17:10, Denis Koroskin wrote:
> On Sat, 24 Oct 2009 19:00:10 +0400, Justin Johansson <no at spam.com> wrote:
>
>> Yigal Chripun Wrote:
>>
>>> On 24/10/2009 01:16, Justin Johansson wrote:
>>> > Sorry; subject line mod'ed just so Ary doesn't miss it.
>>> >
>>> >> enum Color { private UNINITIALIZED = -1, RED, GREEN, BLUE }
>>> >
>>> >> (btw. Interestingly, typing this code into Eclipse with the
>>> Descent plug-in
>>> >> causes a Java out of heap space malfunction.)
>>> >
>>>
>>> enum Color { RED, GREEN, BLUE }
>>>
>>> void foo(Color* c) {
>>> if (c !is null) handleColor(*c);
>>> }
>>> what's the need for that UNINITIIALIZED member?
>>
>> Okay; that's one work around for a corner case of my cited use-case, but
>> you don't always want to, or perhaps it is not convenient/elegant to,
>> use a pointer
>> to data that conveniently fits into a machine register.
>>
>> Perhaps I am wrong but I thought uninit was a good metaphor to
>> demonstrate
>> the various useful purposes that private enum members might have.
>>
>> Here is another example that might make the concept jell. Again I may
>> well be wrong.
>>
>> Consider this hypothetical enum definition together with plausible
>> comments:
>>
>> enum Color {
>> RED, GREEN, BLUE, // these 3 members are available for public consumption
>> private RED_WITH_BLUE_POKER_DOTS, // this value is used internally and
>> is not for public consumption and that's why it is marked private
>> private RED_OR_GREEN, // ditto; internal routine to cater for
>> red-green color-blindness
>> }
>>
>> The above demonstrates a set of entities that are meaningful to some
>> possible internal
>> function but otherwise not externally meaningful.
>>
>> Another use-case lies in the API programmer's want for "private" ..
>> so, for example, consider that "private" may well be a synonym for
>> "pleasedontusethismemberbecauseitisalikelycandidateforfuturedeprecation"
>> **
>>
>> ** Using Walter Bright insignificant whitespace/separator notation :-)
>>
>> Thanks Yigal for commenting and perhaps your further comment?
>>
>> Justin
>>
>
> Another useful use-case I see is enforcing explicit initialization:
>
> enum Color
> {
> private Uninitialized = 0,
> Red,
> Green,
> Blue,
> }
>
> Color color; // error: Color.Uninitialized is not accessible
>
> It would work similar to private struct ctors.


I'd prefer D to have support for:

enum Color { Red, Green, Blue }

Color color; // compile time error
Color? color; // OK

I don't understand why would you want to hide certain enum values. In 
the colors example above, what's the rational behind hiding the 
RED_OR_GREEN value?

personally I'd like to see D enums replaced by Java style enums which 
make more sense to me. D enums are even worse than C enums since you can 
write:
enum foo = "text";

which to me looks very similar to:
auto cat = new Dog;