On Fri, 20 Aug 2004 13:13:20 +0000 (UTC), nail <nail_member@pathlink.com> wrote:
>> bar(1);         //cannot implicitly convert expression 1 of type int to A
>> bar(1|A.AA);    //cannot implicitly convert expression 1 | cast(A)1 of
>> type int to A
>> bar(B.BB|A.AA); //cannot implicitly convert expression cast(B)4 | cast(A)1
>> of type B to A
>> bar(A.AA|1);    //ok
>> bar(A.AA|B.BB); //ok
>>
>> it appears | causes each operand to be converted to 'int' then the result
>> is converted back to the first operands type. So the following:
>>
>> bar(A.AA|<anything that can implicitly be converted to int>);
>>
>> will work. Walter can tell us for sure.
>>
>
> I'm not sure, that this behaviour of compiler is the best case. First: how can I
> in a language with strong types use combination of different types?!

There are degrees of "strong" in D's case, it's not that strongly typed.

> No mater
> that implicitly they are integers. I even can't understand how I can use
> combination of constants of one type while function accepts value of enumerated,
> enum(!), enumeration(!), case value(!), one value(!) in other words.

Enum's can take a base type eg.

enum A : ubyte {A}

But Enums *must* be integral types you cannot say:

enum A : double {A}

As they are all integral types you can implicitly convert them.
It does still check things like..

enum A : ubyte {A}
enum B : {A}

void foo(A a){}

void main()
{
  foo(A.A|B.A);
}

test4.d(8): function foo (A a) does not match argument types (int)
test4.d(8): cannot implicitly convert expression cast(int)(0) | cast(B)0 of type
 int to A

> Predecoration looks little ugly. I prefer use <enum value> instead of <enum
> type> enum value. IMHO the best case for D if the following code will compile as
> expected in comments:
>
> enum Color
> {
> RED = 1,
> GREEN = 2,
> ORANGE = 4,
> }
>
> enum Fruit
> {
> ORANGE = 1,
> APPLE  = 8,
> }
>
> void xxx(Color color) {...}
> void yyy(bitfield Color colors) {...}
> void zzz(Fruit f) {...}
>
> void main()
> {
> xxx(RED); // ok.
> xxx(RED | GREEN); // error: bitfield not accepted
> xxx(ORANGE); // ok. Value 4 (not 1) used
>
> yyy(RED | ORANGE); // ok. Value 4 for ORANGE used
> yyy(RED | APPLE); // error: APPLE not fount in Color enum
>
> zzz(ORANGE); // ok. Value 1 (not 4) used
> }

See my other thread entitled 'Enums are annoyingly verbose'. I think some times the 'decoration' is superfluous, there are several occasions when it is not however. (the other thread has some examples)

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

"Arcane Jill" <Arcane_member@pathlink.com> escribió en el mensaje
news:cg5jte$m33$1@digitaldaemon.com
| In article <cg54eu$e1t$1@digitaldaemon.com>, nail says...
|
|| It can be not power of two.
|
| Good point. That's more like the old struct { int x : n }; objects you got in
C.
| But in the D overview, Walter lists among the things to drop: "Bit fields of
| arbitrary size. Bit fields are a complex, inefficient feature rarely used." So
| that takes us back to ANDing and ORing constants together, which is back where
| we started.
|
|
||| # (xxx[Color.RED] || xxx[Color.BLUE])
|||
||| Will that not do?
||
|| This is not type safe
|
| You'll get no argument from me there! But then, D is not a typesafe language.
If
| it were, then bool, int, char and enum would not be mutually implicitly
| convertible.
|
|
|| and bulky
|
| I've never been particularly bothered by that. Still, I'm quite happy to
accept
| syntactic sugar so long as things stay readable.
|
| Arcane Jill

IMHO, the way Delphi deals with it is better: they're not enums, they're sets. So you don't check if a certaing bit is set, but if a certain element is present. They /could/ be implemented as bitfields, but for the user they look like sets. IMHO

-----------------------
Carlos Santander Bernal

In article <cg6dun$145f$1@digitaldaemon.com>, Carlos Santander B. says...

>IMHO, the way Delphi deals with it is better: they're not enums, they're sets. So you don't check if a certaing bit is set, but if a certain element is present. They /could/ be implemented as bitfields, but for the user they look like sets. IMHO

Yop. Maybe this is most elegant and perfect way

>-----------------------
>Carlos Santander Bernal
>
>

In article <cg1id4$lou$1@digitaldaemon.com>, nail says...
>
>What about integrated bitfields in D?

I guess you could use C functions underneath to do the bitfield stuff. Of course that adds overhead.