Feature Request: Bool <: Boolean

[m-j-w]

I frequently run into the problem of having to define a custom boolean type with an alternative underlying representation. For instance a 16 or 32 bit wide boolean as in Fortran, or a boolean where true and false are not represented by 1 and 0, respectively. These typically originate in external libraries written in other languages...

This feature request aims at providing a customization point in the standard type hierarchy for that.

Thus, I'd like to propose to

"Types belonging to some logical algebra, including at least a state of `true` and `false`."
abstract type Logical <: Integer end

"Types representing the Boolean algebra with states of `true` and `false`."
abstract type Boolean <: Logical end

primitive type Bool <: Boolean 8 end   # The current 'Bool'

The abstract type Logical (or Boolean) should then probably define a minimal interface for testing for true and false, say functions istrue(x::Logical)::Bool , isfalse(::Logical)::Bool. I'm thinking here in particular of the requirement of a Bool in the condition of e.g. a for loop. But this could be decided in the future.

Furthermore, there are more logical algebras than just the binary state boolean algebra. Think about the tri-state (true, false, neither), or the four-state (true, false, neither, both). I do not want to propose to add these to base, but, again, to provide a natural customization point in the standard type hierarchy. Thus, those types could find a home as subtypes of Logical.

While I personally would also prefer a boolean not being a subtype of Integer, these additional abstract types would allow to circumvent that, hopefully, in allowing to define a user-defined alternative bool which does not allow or implement operators +, -, *, ^ etc..

Some relevant issues: #19168, #18367

[nalimilan]

I frequently run into the problem of having to define a custom boolean type with an alternative underlying representation. For instance a 16 or 32 bit wide boolean as in Fortran, or a boolean where true and false are not represented by 1 and 0, respectively. These typically originate in external libraries written in other languages...

Do you actually need to use these custom types as booleans in Julia code? Converting them to Bool from wrappers should be pretty cheap (if not completely free), right? Maybe you can show us specific examples?

[simonbyrne]

Another problem is that you probably wouldn't be able to use it in conditional control flow (e.g. if statements and &&/||), at least not without a lot of work on the Julia side.

For interoperability with C or Fortran libraries, defining a new primitive type to be used only in ccall signatures, along with appropriate convert methods (or more correctly Base.cconvert methods) should be sufficient (e.g. as we already do for Cint).

I don't think this is going to happen, unless there is a very convincing use case.

[m-j-w]

Interoperability with other libraries does not only entail calling into a library, but also the data itself - sometimes gigabytes of data. Practical examples could be the large variety of finite element or CFD solvers, pre- and post-processing tools, lots of other legacy and proprietary mathematical or engineering software.
And although algorithms might be the same, the data representation of a boolean value typically is not. Fortran for instance uses 32bit Logical. On Windows, BOOL is essentially implementation defined by a #define. Sometimes we have (0,1) for (false, true), sometimes (0, everything else), sometimes (-1,0)...

I find it curious that, despite its fundamental importance, Bool is the only type in Julia I know of having special semantics and that cannot be subtyped or otherwise adapted to. There is for instance no such issue in adding a Float80, or a Pascal-style string in the right place...

And, you're right with the 'Boolean context' of if, while, && and ||. That would have been a follow-up feature request.