BigInt bool assign

[Derek]

On Sat, 24 Dec 2011 09:19:26 +1100, bearophile <bearophileHUGS at lycos.com>  
wrote:

> 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.

I agree that 'consistency' is a powerful argument. So it comes down to is  
D meant to be the best language or an adequate language.

I maintain that D would be a better language if it didn't allow implicit  
bool <-> int conversions. The most common thing that humans do to source  
code is read it, in order to understand it's purpose and/or intentions. We  
would do ourselves a service if we strive to make programing languages aid  
this activity. Some implicit conversions can mask a coder's intentions,  
and I believe that bool/int is one of those.


>> 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.

But not impossible.

>> 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.

Do you really believe that the purpose of casts are to "shut up the  
compiler"? Seriously?

> 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).

You realize that the exact argument can be made about implicit casts.

> 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.

If we assume that explicit casts are required for bool->int conversion,  
can you show some code in which this could cause a problem?

-- 
Derek Parnell
Melbourne, Australia