> On 12 Jun 2015, at 09:14, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > On Jun 11, 2015, at 18:01 , Roland King <r...@rols.org> wrote: >> >> yes ‘=‘ instead of ‘==‘. I hit on that trying random things and don’t really >> understand it, an ‘=‘ in an if() test is something I’m having trouble >> getting my brain around. > > It’s not that strange. The statement contains an initializer (conceptually > 'let a = y.assocatedValue’), so there’s gonna be a “=“. Note that in your > original version:
I see however the ‘=‘ feels like it’s in a strange place - need to get used to what case is doing. Perhaps a way to explain it to myself is that .two( int a ) = y sets a with the associated value from a .two() enum instance and the case succeeds if it’s possible to do it. I found a stranger one at the bottom of this post http://austinzheng.com/2015/06/08/swift-2-control-flow/ <http://austinzheng.com/2015/06/08/swift-2-control-flow/>. That one had me thinking a while. > >> if case test.two( let a ) == y { } > > what’s on the LHS of the “==“ isn’t a value of any kind — what were you > expecting the value of ‘a’ to be? > > I get the same error with the for … in version. The compiler appears to be > treating x {…} as a closure, though I don’t know whether that’s cause or > effect. I vaguely recall Chris saying somewhere in the session that some > things weren’t implemented yet in the current compiler release. Maybe for > case … in is one of them? Maybe - I just scanned that piece of the talk again and the only thing I saw mentioned as not in seed one is ‘indirect’ in the recursive structs. Thanks for trying it out. _______________________________________________ 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
