[swift-evolution] [Proposal] Remove Boolean

[Jordan Rose]

It does abstract over DarwinBoolean as well, but this still seems reasonable to me. The most common cases to encounter ObjCBool and DarwinBoolean are out-parameters (which you are usually setting rather than reading, and they will remain BooleanLiteralConvertible) and imported struct fields (which are fairly rare). And John McCall has some ideas for how to even eliminate the latter, though I think that can be separated from this proposal.

Jordan


> On Jun 23, 2016, at 14:33, Anton Zhilin via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Following goals of Swift 3, I've prepaired a minimalistic proposal to 
> remove Boolean protocol.
> 
> https://github.com/Anton3/swift-evolution/blob/remove-
> boolean/proposals/NNNN-remove-boolean.md
> 
> ## Introduction
> 
> Remove `Boolean` protocol. Only Bool will be able to be used in logical 
> contexts:
> 
> let x: ObjCBool = true
> if x {  // will become an error!
>  ...
> }
> 
> ## Motivation
> 
> "Boolean" isn't pulling its weight:
> - It only abstracts over Bool and ObjCBool.
> - It only enables a few operations on ObjCBool, which are not very 
> important.
> - ObjCBool is a bridging problem, and we don't handle bridging by 
> introducing common protocols (e.g. in the case of String vs NSString, we 
> don't introduce a common "Stringable" protocol.
> 
> Further, it complicates the model:
> - People are confused by it and the similar but very different Bool 
> type.
> - Bool is a simple enough concept to not need a family of protocols.
> 
> ## Impact on existing code
> 
> Change is backwards incompatible, but automatic migration is possible:
> 
> - In places where Boolean (but not Bool) was in logical contexts, 
> migrator can add `.boolValue`
> - Migrator can remove conformances to Boolean
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution