make Bool <: Unsigned (i.e. UInt1)

[StefanKarpinski]

Original title: "make Bool not a subtype of Number"

C.f. #18367. I propose simply changing the type hierarchy so that Bool is not a subtype of Number since it is so often an exceptional case. We could still keep useful arithmetic behaviors like true + true == 2, etc. – arithmetic need not only work for numbers. Once upon a time UInt8 + UInt8 produced an Int, but that's no longer the case, so now Bool is the "odd man out". If we make !(Bool <: Number) then we can at least make the behavior of Number completely consistent.

[carlobaldassi]

Are there any problems caused by not having a completely consistent behavior of Number, i.e. of having an exception in their promotion rules as opposed to having that same "exception" outside of Numbers? (It's an honest question, I'm not trying to be polemic.)

[jiahao]

Would we still allow an idiom like sum(data .< 5) to count the number of entries smaller than 5? I find this particular idiom very useful.

[andyferris]

count(data .< 5) could count the number of entries greater than 5.

That said, Stefan explicitly stated that arthmetic ops like + (used by sum) could stay the same.

Overall, I think this is a great move. Bool is also unique in that it is the only type accepted by if, unlike in C, which is why I always thought it odd that Bool shared the same basket as integers.

[StefanKarpinski]

Are there any problems caused by not having a completely consistent behavior

Dispatch ambiguities used to be a big problem but since we don't warn about those anymore, they're less of a problem now. Otherwise, it's just a matter of making it harder to describe and anticipate what generic code is going to do.

[JeffreySarnoff]

💯 (so many months of Bool mucking about the Integer subtyping tree)

[StefanKarpinski]

@JeffBezanson wants to know what problems this change would solve, and I'm drawing a blank. Probably because I've been on an issue triage call for six hours, so if people can post problems this causes, that would be helpful.

[JeffreySarnoff]

omg -- any new type that subtypes Real pulls in Bool and that (in every case I have encountered) necessitates weird, nonintuitive method dispatch definitions involving Bool to keep the ambiguity away.

For me, this has been a real drag all along. And I have other's source with comments like # this has to be defined or many conflicts arise at runtime. Then there is the reasonable distinction between Signed and Unsigned into which Bool really should not Venn. I passed on a package for time-related logic because the type hierarchy has had Bool sequestered in a way that makes extending AbstractLogic to TemporalLogic while keeping boolean stuff along for the ride very difficult.

abstract type AbstractLogic end
primitive type Bool < Unsigned 8  end # why should the multivalue true,false be Signed?
abstract type TemporalLogic <: AbstractLogic end
struct AllenLogicalPredicate <: TemporalLogic
   ...
end

[JeffBezanson]

The ambiguities might arise just from the methods like *(y::Number, x::Bool). We might be able to remove those.

We have Bool <: Integer, but not <: Signed or Unsigned. Would Unsigned be better?

[JeffreySarnoff]

yes