On Jun 12, 2015, at 01:15 , Roland King <r...@rols.org> wrote: > > So you mean the slide lied.
One more update on this. I notice that inside a switch statement, the following are equivalent: > case test.two (let a): > case let test.two (a): or more usefully: > case test.three (let a, let b): > case let test.three (a, b): In each case, the second form is documented as being shorthand for the first. That reduces the for…in issue to a syntax analysis hole in the current compiler, rather than it being different for the sake of being different. Perhaps the underlying problem is that the pattern matching construct, in its full generality is doubly flawed: — It may be expressive, rational and useful, but it’s inscrutable to the point of being painful. — Among its many sub-features, across the various statements where it can be used, it’s not very orthogonal, and it’s orthogonality is inconsistent. For example, in a switch statement, cases like this are legal: > case .A, .B: > case .A (let x): but not this (for obvious reasons): > case .A (let x), .B (let y): and in a non-switch statement, anything with a comma in it isn’t legal (I think). In many places in Swift, you can feel an “Ah” of satisfaction at new syntax. Case patterns aren’t one of them. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
