[Review] SE-0109: Remove the Boolean protocol

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:

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:

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?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at

Thank you,

-Doug

Review Manager

Aside from confusing people, does it actually hurt anything? It's not too hard to imagine that someone might make a type conform to `Boolean` because, within their code, the semantics of "x || y” are clear and that reads better than "x.foo || y.foo".

I agree it feels out of place, though. What about renaming it to something like "CustomBooleanConvertible”?

- Dave Sweeris

···

On Jun 29, 2016, at 01:44, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
<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?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

  > * What is your evaluation of the proposal?

Agree.

In extensive Swift use I've never had cause to actively use Boolean rather than Bool.

If there is a need to keep it (which I don't see) I think it would be better renamed to something less succinct and confusing.

  * Is the problem being addressed significant enough to warrant a
    change to Swift?

Yes. Removing things, especially confusing things is good when there is little impact.

  * Does this proposal fit well with the feel and direction of Swift?

Yes.

  * How much effort did you put into your review? A glance, a quick
    reading, or an in-depth study?

Quick read.

Joseph

Just a quick clarification: I was under impression that the utility of Boolean was that one could extend any type to behave as a boolean type and thus be used in control flow constructions etc. Not something that has to do often, but nice to have nevertheless. I would be sad if this functionality were to go. At the same time, I understand the rationale behind this proposal. Maybe we could introduce something like CustomBoolConvertible instead (if not yet suggested)?

Best,

Taras

···

On 29 Jun 2016, at 08:44, Douglas Gregor via swift-evolution <swift-evolution@swift.org> 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
<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?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
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

https://github.com/apple/swift-evolution/blob/master/proposals/0109-remove-boolean.md

  • What is your evaluation of the proposal?

+1. I hope we eventually get this functionality back through a more flexible mechanism—either subtyping Bool or a protocol for creating custom conditional constructs[1]—but I don't think `Boolean` is really carrying its weight at this point.

  • Is the problem being addressed significant enough to warrant a change to Swift?

Yes. We're trying to get rid of this kind of thing now.

  • Does this proposal fit well with the feel and direction of Swift?

See previous.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

The only language I've used

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading.

[1] For instance, if we have a pattern matching protocol like this:

  // Allows for `if case .foo(let bar, let baz) = quux`-style pattern matching.
  protocol PatternProtocol {
    associatedtype Value
    associatedtype Destructured = Void
    
    // Returns nil for a failed match, or the destructured values for a
    // successful match.
    func match(for value: Value) -> Destructured?
    
    // One could also imagine a `func init(values...: Destructured) -> Value` here
  }
  
  // Enum cases would have a pattern as one of their "aspects", as though
  // they had things like:
  extension Optional {
    static let none: Pattern.None
    static let some: Pattern.Some
    
    enum Pattern {
      struct None: PatternProtocol {
        typealias Value = Optional<Wrapped>
        func match(for value: Value) -> Void? { … }
      }
      struct Some: PatternProtocol {
        typealias Value = Optional<Wrapped>
        typealias Destructured = Wrapped
        func match(for value: Value) -> Void? { … }
      }
    }
  }
  
  // You could write your own patterns for other types:
  extension URL {
    static let http = SchemePattern(scheme: "http")
    static let https = SchemePattern(scheme: "https")
    static let mailto = SchemePattern(scheme: "mailto")
    
    struct SchemePattern: PatternProtocol {
      associatedtype Value = URL
      associatedtype Destructured = (host: String, path: String)
      
      var scheme: String
      
      func match(for value: Value) -> Destructured? {
        guard value.scheme == scheme else { return nil }
        return (value.host, value.path)
      }
    }
  }

Then we could offer a `ConditionalConvertible` protocol which would open up `if let` and plain `if` to other types:
  
  // Allows for `if let (bar, baz) = quux` and, if UnwrappedValues is Void, `if quux`.
  protocol ConditionalConvertible {
    associatedtype Conditional: PatternProtocol where ConditionalPattern.Value == Self
    static var conditional: Conditional
  }
  
  extension Optional: ConditionalConvertible {
    typealias Conditional = Pattern.Some
    static let conditional = some
  }
  
  extension Bool: ConditionalConvertible {
    struct Conditional: PatternProtocol {
      typealias Value = Bool
      
      func match(for value: Value) -> Void? {
        // equivalent to...
        return value ? () : nil
      }
    }
    static let conditional = Conditional()
  }

···

--
Brent Royal-Gordon
Architechies

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

Ha! You clicked send 4 minutes before I did :-)

···

On Jun 29, 2016, at 7:48 AM, Taras Zakharko via swift-evolution <swift-evolution@swift.org> wrote:

Just a quick clarification: I was under impression that the utility of Boolean was that one could extend any type to behave as a boolean type and thus be used in control flow constructions etc. Not something that has to do often, but nice to have nevertheless. I would be sad if this functionality were to go. At the same time, I understand the rationale behind this proposal. Maybe we could introduce something like CustomBoolConvertible instead (if not yet suggested)?

Best,

Taras

On 29 Jun 2016, at 08:44, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
<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?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Aside from confusing people, does it actually hurt anything? It's not too hard to imagine that someone might make a type conform to `Boolean` because, within their code, the semantics of "x || y” are clear and that reads better than "x.foo || y.foo".

I agree it feels out of place, though. What about renaming it to something like "CustomBooleanConvertible”?

IIRC Optional conformed to this protocol early on and that conformance was removed. In practice the idea of a protocol for "truthiness" to which non-Boolean types conform caused more confusion than it provided value. It was a cool idea that just didn't work out so well.

IMO if it doesn't make sense for Optional to conform it is pretty unlikely it would make sense for other types to conform. It seems like a good idea to remove the protocol.

···

Sent from my iPad

On Jun 29, 2016, at 7:52 AM, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:

- Dave Sweeris

On Jun 29, 2016, at 01:44, Douglas Gregor via swift-evolution <swift-evolution@swift.org> 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
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?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

The baseline is not generally whether something that is “nice to have nevertheless”. A better way to look at legacy features like this is: if Swift 3 didn’t already have this feature, would we add it now?

-Chris

···

On Jun 29, 2016, at 5:48 AM, Taras Zakharko via swift-evolution <swift-evolution@swift.org> wrote:

Just a quick clarification: I was under impression that the utility of Boolean was that one could extend any type to behave as a boolean type and thus be used in control flow constructions etc. Not something that has to do often, but nice to have nevertheless.

Is Swift that old that we can really talk about 'legacy' features though? Should we give language features more time to shine and get more people on board on this mailing list and at Apple Dev conferences giving feedback?

···

Sent from my iPhone

On 29 Jun 2016, at 20:37, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 29, 2016, at 5:48 AM, Taras Zakharko via swift-evolution <swift-evolution@swift.org> wrote:

Just a quick clarification: I was under impression that the utility of Boolean was that one could extend any type to behave as a boolean type and thus be used in control flow constructions etc. Not something that has to do often, but nice to have nevertheless.

The baseline is not generally whether something that is “nice to have nevertheless”. A better way to look at legacy features like this is: if Swift 3 didn’t already have this feature, would we add it now?

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

If it didn’t have it, I am sure that we’d sooner or later get a request for CustomBoolConvertible :) Bool is a magic type which is privileged by the compiler for control-flow constructions. Having a hook into that magic would allow the programmer to more clearly express certain models (there are examples in this thread). Not to mention that we already have a precedent : CustomStringConvertible (I don’t suppose anyone would argue for removing THAT). I agree that conversion to boolean has less utility, but IMO removing a hook into privileged Bool type makes the language more asymmetrical and is not a design choice I would make.

Anyway, I think I’ve made my arguments clear. Sorry for the noise. For a full feedback:

What is your evaluation of the proposal?
-1. Implicit Bool conversion is a useful utility when modelling logical entities. The confusion between Boolean and Bool can be solved by refactoring Boolean into CustomBoolConvertible

Is the problem being addressed significant enough to warrant a change to Swift?
Yes (confusion potential), but removing the protocol over renaming it removes useful functionality from the language.

Does this proposal fit well with the feel and direction of Swift?
IMO, no. So far, general concepts/models are playing a vital role in Swift and are source of its elegance. Boolean might be a ’small’ feature, but its a natural part of the system.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Most modern scripting languages offer a boolean conversion hook. Its a useful thing to have.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
A glance.

···

On 29 Jun 2016, at 21:37, Chris Lattner <clattner@apple.com> wrote:

On Jun 29, 2016, at 5:48 AM, Taras Zakharko via swift-evolution <swift-evolution@swift.org> wrote:

Just a quick clarification: I was under impression that the utility of Boolean was that one could extend any type to behave as a boolean type and thus be used in control flow constructions etc. Not something that has to do often, but nice to have nevertheless.

The baseline is not generally whether something that is “nice to have nevertheless”. A better way to look at legacy features like this is: if Swift 3 didn’t already have this feature, would we add it now?

-Chris

What if you wanted to do something like this?
class RemoteBool : Boolean {
    let url: URL
    private var cachedValue: Bool? = nil // gets updated periodically in another thread or some other async method
    init(boolURL: URL) { url = boolURL; sync_update() }
    var boolValue: Bool { return cachedValue ?? sync_update() }
    func sync_update() -> Bool {…} // synchronously sets `cachedValue` and returns the newValue
    func async_update() {…} // asynchronously sets `cachedValue`
}

Or experiment with how ternary logic interacts with boolean logic?
protocol Ternary : Boolean, BooleanLiteralConvertible, NilLiteralConvertible {
    static var forcedBoolValue: Bool { get }
    var ternValue: Bool? { get set }
    init(_: Bool?)
}
extension Ternary {
    var boolValue: Bool { return ternValue ?? Self.forcedBoolValue }
    init(booleanLiteral value: Bool) { self.init(value) }
    init(nilLiteral: ()) { self.init(nil) }
}
struct TendsTrue: Ternary {
    static let forcedBoolValue = true
    var ternValue: Bool?
    init(_ value: Bool?) { ternValue = value }
}
struct TendsFalse: Ternary {
    static let forcedBoolValue = false
    var ternValue: Bool?
    init(_ value: Bool?) { ternValue = value }
}

Yeah, sure, in either case you could go through and use extensions to add support for your custom type on an as-needed basis. Life would be way easier, though, if the standard library was simply coded to an abstracted boolean protocol. Isn’t this kind of scenario that led to Swift having generics?

Renaming `Boolean` to something that doesn’t sort next to `Bool` removes the source of confusion. And while I completely agree that the standard library should be consistent it its use of abstraction protocols vs concrete types, in this regard I think this proposal goes in the wrong direction (although, in my whatever-the-opposite-of-defense-is I’m a huge fan of having generic library code wherever possible, so maybe I’m biased).

Is there a downside to overloading any function which takes a Bool with a version that takes a “CustomBooleanConvertible”?
func foo(_ bar: Bool) {} // pretend this exists in the standard library
func foo <T: CustomBooleanConvertible> (_ bar: T) { foo(bar.boolValue) } // add this, and keep the concrete version as well, both to provide the actual implementation and to prevent the generic version from recursively calling itself

- Dave Sweeris

···

On Jun 29, 2016, at 8:47 AM, Matthew Johnson <matthew@anandabits.com> wrote:

On Jun 29, 2016, at 7:52 AM, David Sweeris via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Aside from confusing people, does it actually hurt anything? It's not too hard to imagine that someone might make a type conform to `Boolean` because, within their code, the semantics of "x || y” are clear and that reads better than "x.foo || y.foo".

I agree it feels out of place, though. What about renaming it to something like "CustomBooleanConvertible”?

IIRC Optional conformed to this protocol early on and that conformance was removed. In practice the idea of a protocol for "truthiness" to which non-Boolean types conform caused more confusion than it provided value. It was a cool idea that just didn't work out so well.

IMO if it doesn't make sense for Optional to conform it is pretty unlikely it would make sense for other types to conform. It seems like a good idea to remove the protocol.

IIRC Optional conformed to this protocol early on and that conformance was removed. In practice the idea of a protocol for "truthiness" to which non-Boolean types conform caused more confusion than it provided value. It was a cool idea that just didn't work out so well.

IMO if it doesn't make sense for Optional to conform it is pretty unlikely it would make sense for other types to conform. It seems like a good idea to remove the protocol.

I certainly agree that it doesn’t make much sense for Optional, but I believe that implicit bool conformance can be a desirable feature for a number of applications. For instance, imagine a logical inference library where you can have entities like Term or Formula. For those, Boolean conformance would make a lot of sense. Of course, one can also make explicit conversions e.g.:

extension Bool {
init(x: Term) { self = x.truthValue }
}

if Bool(f1) { … }

But since Bool is a syntactically privileged construct in the language, it makes sense to have it as a target of built-in type conversion support, for the same reason why we have CustomStringConvertible etc.

To be honest, I’d prefer to have a generic mechanism such as:

ImplicitConvertible<T> {
  var as -> T { get }
}

to replace the Custom*Convertible and friends, but thats a different topic.

— Taras

···

On 29 Jun 2016, at 15:47, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

- Dave Sweeris

On Jun 29, 2016, at 01:44, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
<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?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution