[Review] SE-0043 Declare variables in 'case' labels with multiple patterns


(Chris Lattner) #1

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:

  https://github.com/apple/swift-evolution/blob/master/proposals/0043-declare-variables-in-case-labels-with-multiple-patterns.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:

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:

Thank you,

-Chris
Review Manager


(Greg Titus) #2

The review of “Declare variables in 'case' labels with multiple patterns” begins now and runs through March 21, 2016. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0043-declare-variables-in-case-labels-with-multiple-patterns.md

  • What is your evaluation of the proposal?

+1!

  • 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. :slight_smile:

···

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:

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

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


(Brent Royal-Gordon) #3

  • 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):

  • 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?

Quick reading.

···

--
Brent Royal-Gordon
Architechies


(Juan Ignacio Laube) #4

• 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:

  https://github.com/apple/swift-evolution/blob/master/proposals/0043-declare-variables-in-case-labels-with-multiple-patterns.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:

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,

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


(Patrick Gili) #5

  • What is your evaluation of the proposal?

I think anything that improves pattern matching is a good thing for Swift.

  • 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?

Haskell and ML have very flexible pattern matching capabilities.

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

Quick read.


(Sebastian Hagedorn) #6

• What is your evaluation of the proposal?

+1

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

Yes, I’ve come across the issue a few times.

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

To me the solution seems a lot more intuitive than the proposed alternatives, so yes!

• 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?

Read the proposal, and I’ve thought about the issue before when stumbling over this in my own code.

···

On 16 Mar 2016, at 18:55, 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:

  https://github.com/apple/swift-evolution/blob/master/proposals/0043-declare-variables-in-case-labels-with-multiple-patterns.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:

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,

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


(Matthew Johnson) #7

  • What is your evaluation of the proposal?

+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?

No

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

Followed the initial thread and gave it a quick read.

···

More information about the Swift evolution process is available at:

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris
Review Manager
_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce


(Jordan Rose) #8

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):


(TJ Usiyan) #9

+1

This is a great addition. I've hoped for it since 1.0.

···

On Sat, Mar 19, 2016 at 9:45 AM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote:

• What is your evaluation of the proposal?

+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?

No

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

Followed the initial thread and gave it a quick read.

More information about the Swift evolution process is available at:

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris
Review Manager
_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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


(Andrew Bennett) #10

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.

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