St_W wrote:When the programmer wants to convert boolean to integer rather often and use it like an integer for arithmetic operations etc. he/she should probably just use Integers instead of booleans.
But what if the return type of an operation that doesn't imply a boolean has for return type a boolean. Simplest example '<' . I would agree with you to leave the booleans live their own life and the integers their own, but when you write a<b where a and b are integers (or whatever) , booleans invites themselves. So they are somehow intrusive, and for that reason implicit conversion to the type that has been choosen by the user is a right balance (of course only if boolean are nested in an larger arithmetic operation and we don't force the result to a boolean variable). I can however admit that one may want only operate inside the booleans for some rare application like electronics, and then a compiler option to set a restrictive approach like "_boolean_strict" may be useful at the margin.
I dont even know if this is not the way that this will be done in the future (I have not even the dev version) and I may worry for nothing. But if we were about prepending a CType everywhere, it would compromise backward compatibility for functions that has been written assuming that a<b return is a numeric value when nested inside a calculation ( e.g c = 5*(a<b) ).
This would summarize the state of my (poor) knwoledge on the subject. It's partial but it will show hopefully that there shouldn't be any compilation error, just big warning in a rather unusal case.
Internal operations over numeric types, and boolean
--------------------------------------------------------------------------
Type: Operator set: Comparison set:
Boolean 'LOG' BOOLCOMP = { = , <> }
Numeric 'ARI' ARICOMP = COMP
where :
LOG = { NOT, AND, OR, NAND, NOR, XOR, ANDALSO, ORELSE ..etc..)
ARI = {+, -, *, /, \, MOD, ^ ..etc..)
COMP = {<, >, =, >=, <=, <> ..etc..}
boolean is the default return type of COMP(any, ...) or LOG(boolean,...)
numeric is the default return type of ARI(numeric, ...)
which means for instance :
Var x = COMP(any)
TypeOf(x) = TypeOf(Boolean)
* shown below the case of LOG(any, ...) or ARI(any, ...)
Conversion boolean<->numeric
--------------------------------------------
Boolean ----> Numeric
FALSE ----> int_0
TRUE -----> int_+1
Numeric -----> Boolean
0 ------> FALSE
anytype_nonzero ------> TRUE
External operations (combined boolean and numeric)
--------------------------------------------------------------------------
Clean
dim as Numeric n, n1, n2, n3, N = n ari COMP(n1, n2....n3)
any arithmetic combination of this form where booleans operations are insulated then casted to numeric to take part of numerical operations only is perfectly simple, not to say very useful.
Example : N = n + (n1 > n2)
Clean, even if more complicated
N = n ari LOG(COMP(n1, n2...n3))
Example : N = n * (n1 = n2 Or n1 < n3)
Easy to decypher
dim as Boolean b, B = b log ARI(a1, a2....an)
that's more exotic, but no reason here to banish if the coder knows what he is computing. The hard part is only that ARI(a1,a2, ...an) has to be casted to a boolean first. Just taking care of insulation with the help of parenthesis ensure easy going.
B = b OR (n1 - n2)
Complicated
dim as Boolean b1, b2
dim as Numeric n1
var x = b1 log n1 ari b2
example : var x = TRUE AND -37 + FALSE
Code reads from left to right so -37 has to be casted, the boolean result is TRUE. Returns TRUE. Then both TRUE and FALSE have to be casted to -1 and 0. Final result is -1. And TypeOf(x) is integer. Here the user may be warned, and would even thank for this, above all when all the values are hidden by the variable names. But the only thing that hurts is the lack of insulation, allowing the compiler to suppose the user may be mixing types by mistake. This will return a clear result anyway.
MrSwiss wrote:ENUM returns an Integer, at least ATM. I'd favor an option to force Int32 (Long)
Also what if we want a boolean as a constant in the enum, will it be converted, will it be prohibited? will it be a mixed case?
Ok it's my boolean day, I have a quote about this too:
Refresher on some Enum and boolean usages
--------------------------------------------------------------------------
LOGIC USAGE
One may use enums and boolean both for logic computation. Maybe not freebasic enums, but bitwise types so. Whatever this is rather clear for booleans we want to get the truth value of operation like :
a < b
Not (a or b)
...
For bitwise affair, it is about logical combinations of enum fields. For instance:
Enum _COMBINE
_green = ..
_yellow = ..
_yellowgreen = ..
End Enum '_COMBINE
We would like that (_green Or _yellow) gives _yellowgreen for instance. This said, this is not a matter I master.
ARITHMETIC USAGE
Just an example should be convincing :
dim as integer i, a, b
a = 1 : b = 1
If a>b then i = 1
If a=b then i = 2
If a<b then i = 3
Test can be replaced by single line yet easy to decypher:
i = -1*(a>b) -2*(a=b) -3*(a<b)
SEMANTIC USAGE
At last, booleans and enums are used to enrich code sense. TRUE and FALSE are often better answers than 0 or -1, for readability. Also Enums are used to link a numeric answer to a speech. Anyone who has taken a look at windows API has seen the use and abuse they have made there of named constants and enum like WS_OVERLAPPED, WS_EX_OVERLAPPEDWINDOW....
For this usage, mixing booleans with the other values inside an Enum seems properly consistent.
