www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Types soup with enum and bool

reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Oct 29 2013
parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
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).
Oct 29 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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
Oct 29 2013
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
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)
Oct 29 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Oct 29 2013
parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
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.
Oct 29 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Oct 29 2013
parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
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.
Oct 29 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Oct 29 2013