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
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@swift.org> wrote:
Following goals of Swift 3, I've prepaired a minimalistic proposal to
remove Boolean protocol.
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
On Jun 23, 2016, at 3:38 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:
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.