While I did not get a chance to review all the discussion in time to respond to the proposal, I am happy with the revised version that was approved (the semi-colons were a point of concern for me). In addition to resolving ambiguity, this also resolved a pedigogical issue surrounding the 'where' keyword I encountered when teaching Swift.
On Wed, Jun 08 2016 at 09:47:55 PM, Joe Groff via swift-evolution <[email protected]> wrote: > 'where' keyword can be retired from its purpose as a boolean condition > introducer. When teaching Swift, I did discover that the requirement of 'where' in conditionals as expressed by this proposal was confusing and those I was teaching assumed they would use commas (or &&). I'll admit that at first the 'where' keyword surprised me as well, but I grew to like it and will be a little sad to see it replaced by comma instead of allowing 'where' or comma as I thought certain statements were easier to read with 'where'. On Thu, Jun 09 2016 at 06:30:17 AM, Haravikk via swift-evolution <[email protected]> wrote: > On 9 Jun 2016, at 09:47, Brent Royal-Gordon > <[email protected]> wrote: > > > > Can we get some clarification as to why ‘where’ is being chosen > to be retired here? I’m deeply disappointed by that decision as > enabling the consistent use of comma as a separator does not > preclude the use of where for simple cases that don’t require > it. I’m all for having a more usable separator for complex > conditionals, but I rarely need it, meanwhile in common, simple > conditional bindings and patterns I find the ‘where’ keyword a > lot more readable, i.e: > > if let value = foo where foo > 5 { … } > > > I think there may be a case for keeping the `where` keyword—but > before, not after, the equals sign. > > if case .cartesian(let x, let y) where x != y = point { ... } > if let value where value > 5 = foo { … } > > > That looks pretty strange visually though thanks to the assignment (it > kind of looks like x is being compared against y = point). I had this feeling as well. > While my reasons for liking where are mainly aesthetic once the need to > use it to get around separator issues goes away, it’s still a nice tool > for grouping statements visually, for example: This is the case for me as well, functionally I suppose I will not miss 'where', but for aesthetics I do think it made some statements cmore clear to read. -- Roth _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
