Or you can make sure every expression is boolean, which would take care of this as well...
-- E > On May 24, 2016, at 12:47 PM, Jacob Bandes-Storch <[email protected]> wrote: > > 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] <mailto:[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] >> <mailto:[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] <mailto:[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] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
