1).  Is there a way to "import" an enum so that you don't need
to qualify each instance with the type name?  Something like
java does with its "static import".

2).  It seems that you can't use an enum of struct or class type
in a switch statement.  This seems inconsistent.  Would it make
sense to have like an "uint opOrdinal()" method that would return
a value known at compile time so that class or struct enums
can be used in switch statements?

Thanks,

Eric

Eric:

> 1).  Is there a way to "import" an enum so that you don't need
> to qualify each instance with the type name?  Something like
> java does with its "static import".

In some cases you can use the handy with() statement for that purpose.

One example usages:

final switch (foo) with (MyEnum) {
    ...
}


> 2).  It seems that you can't use an enum of struct or class type
> in a switch statement.

Using an enumeration of class instances isn't a good idea, they are designed mostly for integral built-in types, including chars, etc.

Regarding your enhancement, look here (I suggest an unapply as in Scala), you can even vote it:
https://d.puremagic.com/issues/show_bug.cgi?id=596

Bye,
bearophile

>
> In some cases you can use the handy with() statement for that purpose.
>
> One example usages:
>
> final switch (foo) with (MyEnum) {
>     ...
> }

Okay - the with statement may help in some cases. I'll
have to try it out...


>
> Using an enumeration of class instances isn't a good idea, they are designed mostly for integral built-in types, including chars, etc.
>

I disagree. If you just think of a class type enum as a class type,
then what you say makes sense.  But if you instead think of it as
a more powerful enum then it can enhance data safety in a program.

-Eric

Eric:

> I disagree. If you just think of a class type enum as a class type,
> then what you say makes sense.  But if you instead think of it as a more powerful enum then it can enhance data safety in a program.

I was speaking about the current D enum, as implemented and as designed. Regarding your enhancements, I need some examples or a better explanation to understand your point.

Bye,
bearophile

On Thursday, 3 April 2014 at 22:34:19 UTC, bearophile wrote:
> Eric:
>
>> I disagree. If you just think of a class type enum as a class type,
>> then what you say makes sense.  But if you instead think of it as a more powerful enum then it can enhance data safety in a program.
>
> I was speaking about the current D enum, as implemented and as designed. Regarding your enhancements, I need some examples or a better explanation to understand your point.
>

Okay - I'm new to D, and I'm comming from a java background.  Suppose
you are designing an API, and you want the user to supply arguments
as an enum.  But the user needs to define the enum, so how can the API
know in advance what enum to require?  The solution is to require an
enum that implements a known interface.  This is easy to do in java,
but I haven't yet tried it in D.  I suspect it could be done with CTFE
or something.  An example where I use this is for electronics software.
If I need the user to supply a set of pins, the pins are supplied as an
enum which implements an interface.  By using the interface, it also
forces the user to include all of the attributes of each pin such as
direction, max load, DC current, etc.  Since class type enums are references,
they are light, - and they should be immutable - so they are thread safe aslo.

I hope this example illustrates where I'm comming from.

-Eric

On Thursday, 3 April 2014 at 23:16:14 UTC, Eric wrote:
> Okay - I'm new to D, and I'm comming from a java background.  Suppose
> you are designing an API, and you want the user to supply arguments
> as an enum.  But the user needs to define the enum, so how can the API
> know in advance what enum to require?  The solution is to require an
> enum that implements a known interface.  This is easy to do in java,
> but I haven't yet tried it in D.  I suspect it could be done with CTFE
> or something.  An example where I use this is for electronics software.
> If I need the user to supply a set of pins, the pins are supplied as an
> enum which implements an interface.  By using the interface, it also
> forces the user to include all of the attributes of each pin such as
> direction, max load, DC current, etc.  Since class type enums are references,
> they are light, - and they should be immutable - so they are thread safe aslo.

I'm not sure how you're using your enum. In Java, the only way to perform a switch over an enum is if you know all the values during compile time. Passing a type Enum into a function (i.e. as opposed to "enum MyEnumType') requires using introspection to pull the actual values out, and then a loop to scan through them for your target value.

But if you've programmed a switch for a known enum type, then that means the enum has already been implemented and there is no chance for more than one type to be passed in.

So I'm confused.

By using the interface,
>> it also
>> forces the user to include all of the attributes of each pin such as
>> direction, max load, DC current, etc.  Since class type enums are references,
>> they are light, - and they should be immutable - so they are thread safe aslo.
>
> I'm not sure how you're using your enum. In Java, the only way to perform a switch over an enum is if you know all the values during compile time. Passing a type Enum into a function (i.e. as opposed to "enum MyEnumType') requires using introspection to pull the actual values out, and then a loop to scan through them for your target value.
>
> But if you've programmed a switch for a known enum type, then that means the enum has already been implemented and there is no chance for more than one type to be passed in.
>
> So I'm confused.

I guess D does not see enums as enums, but rather as whatever
type the enum happens to implement. In java, all enums are
of enum type.  So it's probably me that's confused.

-Eric