Could we just require "let" (or var) to introduce every binding, rather than allowing the combination "if let x = y, z = q, ..."? I always use "let" anyway; I think it's easier to read.
On Tue, May 24, 2016 at 11:42 AM, Erica Sadun via swift-evolution < [email protected]> wrote: > Okay, and here is where the problem is (thanks Chris L) > > `z = q` is an expression. It returns Void. > > For example: > > let q = 5 > var z = 0 > let foo = z = q // foo inferred to have type `()` which may be unexpected > > So if you have the following statement: > > guard let x = optional, z = q else {...} > > where q is non-optional, there's issues in that `q` is not an optional and > `z = q` is an expression. > > -- E > > > On May 24, 2016, at 11:59 AM, Austin Zheng <[email protected]> wrote: > > I like the idea in principle. > > However, right now you can write something like: > > if let a = optionalA, frob = fooBarBaz() { ... } > > It's clear that both clauses are optional binding clauses. > > With this change, it's not clear anymore whether the second clause is an > optional binding clause, or a logic test erroneously using '=' instead of > '=='. > > To be fair, though, since assignment in Swift doesn't return the new value > as it does in C, there is far less room for disastrous bugs caused by this > sort of mistake. > > Austin > > > > On Fri, May 20, 2016 at 10:07 AM, Erica Sadun via swift-evolution < > [email protected]> wrote: > >> *Earlier on Swift Evolution:* >> >> Me: "*Is there a technical reason that Swift cannot be expanded to allow >> arbitrary mixes of conditional binding and boolean assertions within a >> single compound guard statement?*" >> >> Joe Groff: "*No. You already can, we just have the somewhat strange rule >> that to separate `guard` conditions uses `,` before optional or pattern >> conditions, but `where` before Boolean conditions. **There's no >> technical reason we couldn't accept either 'where' or ',' consistently."* >> >> guard x == 0, >> let y = optional where >> z == 2 { >> } >> >> *Pitch: * >> >> I'd like to update Swift's grammar to interchangeably and consistently >> accept `where` or `,` to separate guard conditions. This would allow a more >> consistent approach that supports intermingling conditional binding and >> boolean assertions. Here's a real-world bit of code I was helping someone >> with a few evenings ago. It's attempting to navigate through some JSON, >> using optional conditions with where clauses. >> >> guard >> let fileContents = fileContents, >> let jsonDict = try >> NSJSONSerialization.JSONObjectWithData(fileContents, options: []) as? >> NSDictionary, >> let featuresArray = jsonDict["features"] as? NSArray *where >> **featuresArray.count >> > 0,* >> let featuresDict = featuresArray[0] as? NSDictionary, >> let coordinatesArray = featuresDict["geometry"] *where >> **coordinatesArray.count >> > 0,* >> let coordinateArray = coordinatesArray[0] as? NSArray *where >> **coordinateArray.count >> > 3* >> else { fatalError("Reason") } >> >> Each `where` test is a separate test. While there *are* semantic ties >> between the conditional binding and the count tests, there *doesn't have >> to be*. Under Swift's current rules, you must use the `where` keyword >> to introduce a Boolean test after a binding or pattern, regardless of >> whether or not there's an underlying semantic link between the two. >> >> By removing this requirement and allowing interchangeability between >> `where` and `,`, you're given the option of tying the boolean to the >> binding/pattern match or introducing a boolean statement with no connection >> to previous steps. Here's what this example looks like after excluding >> `where`: >> >> guard >> let fileContents = fileContents, >> let jsonDict = try >> NSJSONSerialization.JSONObjectWithData(fileContents, options: []) as? >> NSDictionary, >> let featuresArray = jsonDict["features"] as? NSArray, >> * featuresArray.count > 0,* >> let featuresDict = featuresArray.firstObject as? NSDictionary, >> let coordinatesArray = featuresDict["geometry"], >> * coordinatesArray.count > 0,* >> let coordinateArray = coordinatesArray.firstObject as? NSArray, >> *coordinateArray.count > 3* >> else { fatalError("Reason") } >> >> The motivation for this approach becomes more compelling when the Boolean >> tests are disjoint from binding or pattern matches. >> >> guard >> minimumShapeCount > 4, >> let shapes = decompose(map, minimum: minimumShapeCount), >> availableArea > minimumArea, >> let map = placeShapes(shapes, availableArea) else { >> fatalError() >> } >> >> would be allowed compared to current Swift which mandates where between >> the second and third tests: >> >> let shapes = decompose(map, minimum: minimumShapeCount) where >> availableArea >> > minimumArea, >> >> In my vision, Swift would continue to allow where clauses and expand to >> allow disjoint Boolean entries. >> >> Thoughts? >> >> -- E >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
