This code is accepted by the D compiler:


enum Foo { A, B, C }
void main() {
    bool[5] bools;
    auto b = bools[2] != Foo.C;
    bools[2] = Foo.A;
}


Who is that likes such kind of code? What are the advantages of accepting such kind of code? I can see the disadvantages and risks.

Bye,
bearophile

On Tuesday, 29 October 2013 at 12:43:17 UTC, bearophile wrote:
> This code is accepted by the D compiler:
>
>
> enum Foo { A, B, C }
> void main() {
>     bool[5] bools;
>     auto b = bools[2] != Foo.C;
>     bools[2] = Foo.A;
> }
>
>
> Who is that likes such kind of code? What are the advantages of accepting such kind of code? I can see the disadvantages and risks.
>
> Bye,
> bearophile

Probably may be related to even worse issue:

import std.stdio;

void foo(bool b) { writeln("bool"); }
void foo(long l) { writeln("long"); }

void main()
{
	foo(0); // bool
	foo(1); // bool
	foo(2); // long
	int i = true;
	foo(i); // long
}

If reasons for accepting yours and this example are the same, then this is by design (to be more precise, the part which is related to bool types being essentially kind of integer types + VRP + overloading rules).

On 10/29/2013 09:15 AM, Maxim Fomin wrote:

> On Tuesday, 29 October 2013 at 12:43:17 UTC, bearophile wrote:
>> This code is accepted by the D compiler:
>>
>>
>> enum Foo { A, B, C }
>> void main() {
>>     bool[5] bools;
>>     auto b = bools[2] != Foo.C;
>>     bools[2] = Foo.A;
>> }
>>
>>
>> Who is that likes such kind of code? What are the advantages of
>> accepting such kind of code? I can see the disadvantages and risks.
>>
>> Bye,
>> bearophile
>
> Probably may be related to even worse issue:
>
> import std.stdio;
>
> void foo(bool b) { writeln("bool"); }
> void foo(long l) { writeln("long"); }
>
> void main()
> {
>      foo(0); // bool
>      foo(1); // bool
>      foo(2); // long
>      int i = true;
>      foo(i); // long
> }
>
> If reasons for accepting yours and this example are the same, then this
> is by design (to be more precise, the part which is related to bool
> types being essentially kind of integer types + VRP + overloading rules).

There was a long discussion about that. Walter was happy that bool was a integer type. Many of us had objections:

  http://forum.dlang.org/thread/klc5r7$3c4$1@digitalmars.com

Ali

On Tuesday, 29 October 2013 at 17:40:23 UTC, Ali Çehreli wrote:
> On 10/29/2013 09:15 AM, Maxim Fomin wrote:
>
> > On Tuesday, 29 October 2013 at 12:43:17 UTC, bearophile wrote:
> >> This code is accepted by the D compiler:
> >>
> >>
> >> enum Foo { A, B, C }
> >> void main() {
> >>     bool[5] bools;
> >>     auto b = bools[2] != Foo.C;
> >>     bools[2] = Foo.A;
> >> }
> >>
> >>
> >> Who is that likes such kind of code? What are the advantages
> of
> >> accepting such kind of code? I can see the disadvantages and
> risks.
> >>
> >> Bye,
> >> bearophile
> >
> > Probably may be related to even worse issue:
> >
> > import std.stdio;
> >
> > void foo(bool b) { writeln("bool"); }
> > void foo(long l) { writeln("long"); }
> >
> > void main()
> > {
> >      foo(0); // bool
> >      foo(1); // bool
> >      foo(2); // long
> >      int i = true;
> >      foo(i); // long
> > }
> >
> > If reasons for accepting yours and this example are the same,
> then this
> > is by design (to be more precise, the part which is related
> to bool
> > types being essentially kind of integer types + VRP +
> overloading rules).
>
> There was a long discussion about that. Walter was happy that bool was a integer type. Many of us had objections:
>
>   http://forum.dlang.org/thread/klc5r7$3c4$1@digitalmars.com
>
> Ali

Hey, just be happy that we're not in IDL, where even numbers evaluate as false, odd numbers evaluate as true and 'not x' evaluates to -(x+1)

Ali Çehreli:

> >> enum Foo { A, B, C }
> >> void main() {
> >>     bool[5] bools;
> >>     auto b = bools[2] != Foo.C;
> >>     bools[2] = Foo.A;
> >> }
>...
> There was a long discussion about that. Walter was happy that bool was a integer type. Many of us had objections:

My problem is mostly with enums. I don't remember Walter explaining the rationale of the D enum conversion design. I prefer the C++11 enums.

Bye,
bearophile

On Tuesday, 29 October 2013 at 18:23:03 UTC, bearophile wrote:
> Ali Çehreli:
>
>> >> enum Foo { A, B, C }
>> >> void main() {
>> >>    bool[5] bools;
>> >>    auto b = bools[2] != Foo.C;
>> >>    bools[2] = Foo.A;
>> >> }
>>...
>> There was a long discussion about that. Walter was happy that bool was a integer type. Many of us had objections:
>
> My problem is mostly with enums. I don't remember Walter explaining the rationale of the D enum conversion design. I prefer the C++11 enums.
>
> Bye,
> bearophile


Bools being integer types is reason of your problem with enums. Relevant lines from your code are translated to:

bool b = 0 != 2;
bools[2] = 0;

taking into account that 'bool' is integer type having capacity to represent values 0 and 1.

Maxim Fomin:

> Bools being integer types is reason of your problem with enums.

The reason of that problem of mine with enums is that they convert implicitly to integers. And I still don't know the original rationale of Walter of this design mistake.

Bye,
bearophile

On Tuesday, 29 October 2013 at 21:24:35 UTC, bearophile wrote:
> Maxim Fomin:
>
>> Bools being integer types is reason of your problem with enums.
>
> The reason of that problem of mine with enums is that they convert implicitly to integers. And I still don't know the original rationale of Walter of this design mistake.
>
> Bye,
> bearophile

It works according to spec: "A named enum member can be implicitly cast to its EnumBaseType, but EnumBaseType types cannot be implicitly cast to an enum type. "

In this respect D enums behave like C enums.

Maxim Fomin:

> It works according to spec: "A named enum member can be implicitly cast to its EnumBaseType, but EnumBaseType types cannot be implicitly cast to an enum type. "
>
> In this respect D enums behave like C enums.

In C conversion in both directions is allowed (C enums don't have a EnumBaseType, well, it's int).

But why are D specs prescribing D enums to be implicitly castable to its EnumBaseType?

Bye,
bearophile