Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

> On 7 Mar 2017, at 21:41, Erica Sadun via swift-evolution > wrote: > >> On Mar 7, 2017, at 1:31 PM, Jonathan Hull > > wrote: >> >> Would ‘if let foo = foo’ still be allowed? >> >> > > Existing code should to continue to work with `if let foo = foo`. I don't > believe

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

I will attach my comments to Brent’s answer because I echo many of his thoughts: > On 8 Mar 2017, at 05:59, Brent Royal-Gordon via swift-evolution > wrote: > >> On Mar 7, 2017, at 12:14 PM, Erica Sadun via swift-evolution >> wrote: >> >> Because of that, I'm going to start over here, hopeful

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

> On 8 Mar 2017, at 03:27, Greg Parker via swift-evolution > wrote: > > >> On Mar 7, 2017, at 3:49 PM, Jaden Geller via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> It’s worth mentioning that the normal let binding can be used for pattern >> matching: >> let (a, b, c

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

> On Mar 7, 2017, at 8:59 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Mar 7, 2017, at 12:14 PM, Erica Sadun via swift-evolution >> wrote: >> >> Because of that, I'm going to start over here, hopefully pulling in all the >> details >> and allowing the community to provide fee

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

> On Mar 8, 2017, at 2:33 AM, Guillaume Lessard via swift-evolution > wrote: > > >> On Mar 7, 2017, at 4:30 PM, Erica Sadun wrote: >> >> I deliberately moved it out of proposal format for that reason, so it could >> be discussed first. > > I see now. > > >>> - The `case let .some(foo)` v

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

> On Mar 7, 2017, at 12:14 PM, Erica Sadun via swift-evolution > wrote: > > Because of that, I'm going to start over here, hopefully pulling in all the > details > and allowing the community to provide feedback and direction. The following > gist is an amalgam of work I was discussing with Xia

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

I disagree that the following is better guard unwrap foo else { ... } // simpler? It feels like you are re-using foo which previously was an optional but now is something else. If a variable is a cup, then you'd be reusing a cup that previously had a different drink in it. guard let foo = foo el

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

> On Mar 7, 2017, at 3:49 PM, Jaden Geller via swift-evolution > wrote: > > It’s worth mentioning that the normal let binding can be used for pattern > matching: > let (a, b, c) = foo() > > This nicely parallels the existing case syntax: > if case let .blah(a, b, c) = bar() { … } > It wou

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

> On Mar 7, 2017, at 4:30 PM, Erica Sadun wrote: > > I deliberately moved it out of proposal format for that reason, so it could > be discussed first. I see now. >> - The `case let .some(foo)` vs. `case .some(let foo)` issue could be a >> targeted proposal. >> (I really like this) > > I pu

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

> On Mar 7, 2017, at 15:30, Erica Sadun wrote: > >> - The `case let .some(foo)` vs. `case .some(let foo)` issue could be a >> targeted proposal. >> (I really like this) > > I put it in as a bug report (link in repo) based on ?Anton's? suggestion but > Jordan says this > isn't similar to norm

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

It’s worth mentioning that the normal let binding can be used for pattern matching: let (a, b, c) = foo() This nicely parallels the existing case syntax: if case let .blah(a, b, c) = bar() { … } It would feel inconsistent if the order switched when in a conditional binding. I would prefer th

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

> On Mar 7, 2017, at 3:44 PM, Guillaume Lessard via swift-evolution > wrote: > > I like some of this, but as a single proposal, it does too many things at > once. I deliberately moved it out of proposal format for that reason, so it could be discussed first. > - The `case let .some(foo)` vs

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

I like some of this, but as a single proposal, it does too many things at once. - The `case let .some(foo)` vs. `case .some(let foo)` issue could be a targeted proposal. (I really like this) - The Unwrappable protocol (and keyword) is interesting; it can probably be its own discussion. (feels u

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

> On Mar 7, 2017, at 1:31 PM, Jonathan Hull wrote: > > Would ‘if let foo = foo’ still be allowed? > > Existing code should to continue to work with `if let foo = foo`. I don't believe I put anything in-text about removing this, but if you see something let me know. -- E >> On Mar 7, 2017, a

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

Would ‘if let foo = foo’ still be allowed? > On Mar 7, 2017, at 12:14 PM, Erica Sadun via swift-evolution > wrote: > > I have been involved in several separate related draft proposals for > discussions > that were cut off about 4 months ago. I believe they meet the criteria for > Stage 2, >

[swift-evolution] [Pitch] Introducing `Unwrappable` protocol

I have been involved in several separate related draft proposals for discussions that were cut off about 4 months ago. I believe they meet the criteria for Stage 2, but I'm doing a poor job presenting them coherently on-list. Because of that, I'm going to start over here, hopefully pulling in a