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:
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:
• Is the problem being addressed significant enough to warrant a change to Swift?
Absolutely. The lack of this feature causes a lot of extra boilerplate or workarounds when dealing with enums.
• Does this proposal fit well with the feel and direction of Swift?
Yes. I was surprised the language didn’t already include it. It seems natural.
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I’ve used pattern matching in Haskell quite a bit and this Swift feature serves the same purpose and is really almost a necessary removal of a pattern matching limitation.
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I spent enough effort on it to implement most of it in the compiler. :-)
···
On Mar 16, 2016, at 10:55 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
More information about the Swift evolution process is available at:
How exact does the type match have to be? Can they be two subclasses of a different superclass? Can they conform to common protocols? Can they conform to no common protocols and just be `AnyObject` or `Any`?
Is there a way to specify the type, either to get an exact match or just to ask or a supertype? If you do that, does it have to be specified on both, or only one? Something like:
case let .Case1(x: SignedIntegerType, 2), let .Case2(2, x):
• Is the problem being addressed significant enough to warrant a change to Swift?
It's a minor concern, but still very helpful to fix.
• Does this proposal fit well with the feel and direction of Swift?
Yes.
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I don't believe I have. It's nice.
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
• What is your evaluation of the proposal?
A strong +1.
• 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.
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Other functional programming languages like Haskell has strong pattern matching features. I think this get us a little closer to that.
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Quick reading of the proposal.
···
On Mar 16, 2016, at 2:55 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
Hello Swift community,
The review of “Declare variables in 'case' labels with multiple patterns” begins now and runs through March 21, 2016. The proposal is available here:
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:
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:
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:
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:
In GregT's current implementation, the types have to be an exact match. You can use the existing "as Foo" constraint to specify a type, but it must be specified everywhere that that wouldn't be the inferred type. (See my earlier message to Andrii C: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160314/012779.html\) Note that that also isn't "as!"; if used with a subtype instead of a supertype, it imposes (and has always imposed) an additional constraint on the match.
Jordan
···
On Mar 16, 2016, at 18:10 , Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
• What is your evaluation of the proposal?
Good stuff.
How exact does the type match have to be? Can they be two subclasses of a different superclass? Can they conform to common protocols? Can they conform to no common protocols and just be `AnyObject` or `Any`?
Is there a way to specify the type, either to get an exact match or just to ask or a supertype? If you do that, does it have to be specified on both, or only one? Something like:
case let .Case1(x: SignedIntegerType, 2), let .Case2(2, x):
Excellent point Brent. I was considering that this would have to be an
exact match, I hadn't considered the need for an (x: Y) syntax.
This probably should be considered in a future proposal though. The future
proposal may make sense to be after existential types are explored, so that
common sub-types can be matched where there are associated-type
requirements.
I'm a +1 on this proposal, I'm not sure if I need to say so, see the
proposal for my analysis.
Thanks everyone for your comments so far!
Andrew Bennett
···
On Thu, Mar 17, 2016 at 1:36 PM, Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote:
> On Mar 16, 2016, at 18:10 , Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org> wrote:
>
>> • What is your evaluation of the proposal?
>
> Good stuff.
>
> How exact does the type match have to be? Can they be two subclasses of
a different superclass? Can they conform to common protocols? Can they
conform to no common protocols and just be `AnyObject` or `Any`?
>
> Is there a way to specify the type, either to get an exact match or just
to ask or a supertype? If you do that, does it have to be specified on
both, or only one? Something like:
>
> case let .Case1(x: SignedIntegerType, 2), let .Case2(2, x):
In GregT's current implementation, the types have to be an exact match.
You can use the existing "as Foo" constraint to specify a type, but it must
be specified everywhere that that wouldn't be the inferred type. (See my
earlier message to Andrii C: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160314/012779.html\)
Note that that also isn't "as!"; if used with a subtype instead of a
supertype, it imposes (and has always imposed) an additional constraint on
the match.