On Tue, Jun 28, 2016 at 11:44 PM Douglas Gregor via swift-evolution < [email protected]> wrote:
> 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 > > <https://github.com/apple/swift-evolution#what-goes-into-a-review-1>What > 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. > > - 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
