Derek Parnell: > I'm with Don on this one because a boolean and an integer are not the same > concept, and even though many programming languages implement booleans > using integers, it still doesn't make them the same thing.
D doesn't implement booleans with integers, D has a boolean type. But D allows bools to implicitly cast to ints/longs. Not allowing a BigInt to be initialized with a bool value introduce an inconsistency that makes BigInts more complex because there is one more rule to remember, less inter-operable with ints, and I don't think it introduces advantages. > Using booleans as implicit integers can be seen as laziness (i.e. poor > documentation of coder's intent) or a legitimate mistake (i.e > unintentional usage by coder). In my code such mistakes are uncommon. > By insisting that an explicit cast must be > used when one wants a boolean to behave as an integer allows the coder's > intent to become more apparent when reading their source code. This has > nothing to do with machine code generation, just source code legibility. Casts are powerful tools, they shut up the compiler and they assume the programmer is perfectly right and has perfect knowledge of what's going on. In practice my experience shows that the programmer (me too) sometimes doesn't have perfect knowledge (usually because the code later was modified, turning the cast into a bug because casts are often silent). This is why it's better to avoid casts, not requiring them in the first place, unless they are useful. In this case I think a cast introduces more danger than the risks caused by implicit bool->int conversions. Bye, bearophile
