Hello Swift community,
The review of SE-0109 "Remove the Boolean protocol" begins now and runs
through July 4, 2016. The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0109-remove-boolean.md
Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at
https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at the
top of the message:
Proposal link:
https://github.com/apple/swift-evolution/blob/master/proposals/0109-remove-boolean.md
Reply text
Other replies
<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
goes into a review?
The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:
- What is your evaluation of the proposal?
+1. Having two similarly named types is confusing to newcomers (especially
those from languages where "Boolean" is the preferred term instead of
"Bool") and the Boolean protocol has very little use.
- Is the problem being addressed significant enough to warrant a
change to Swift?
Yes.
- Does this proposal fit well with the feel and direction of Swift?
Yes. Indeed, the fact that any type can conform to Boolean and get an
implicit conversion in if statements and Boolean expressions is very
un-Swift-like; the language currently prefers explicit and safe conversions
instead of implicit ones. I would be surprised by a language that doesn't
let me implicitly convert two similar types like Int32 and Int but would
let me implicitly convert anything I wanted to Boolean.
Giving users the ability to implicitly treat anything as a Boolean in those
contexts harms the readability of code, IMO. It forces readers to track
down the meaning in a place that isn't evident from that line of code. If I
see something like this:
struct SomeValue: Boolean { ... }
func foo(x: SomeValue) {
if x {
...
}
}
...where do I go to find the meaning of this? The user isn't querying
.boolValue explicitly, so I can't hover over that and get to its
documentation. Maybe they didn't even document that property from the
conformance, so I have to go on a fishing expedition through the type's
documentation to figure out which values map to true and which map to false.
I like that Swift tends away from such "magic" and forces the user to say
what they mean. If a developer was writing an arbitrary type where they
wanted to use this, I would want to know why they think that's better than
*saying what they mean*—in many cases, I would expect that a property like
"isValid", "isEmpty", "exists", or any number of other assertions would
clarify the meaning and read better in a world where we put so much
emphasis on API design/naming.
- If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
Many languages provide implicit conversions between some of its types and
boolean contexts (Javascript, Python, PHP), or a way to define custom
conversions (C++), and it's almost always clever, mysterious, or horrible.
I definitely don't want to see Swift going down the road of users writing
or extending types to make them work magically as if they were booleans. An
extra property/method call or comparison is not onerous. Let's nip this in
the bud now.
···
On Tue, Jun 28, 2016 at 11:44 PM Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote:
- How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
Briefly read the proposal.
More information about the Swift evolution process is available at
https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,
-Doug
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution