To be frank, I just find the proposed syntax to be more ugly and less expressive.
I just don't find the proposal compelling enough to take away one of the truly "Swifty" syntaxes that I have used and loved. If there are other ways to keep "where" while fixing the ambiguity I would rather explore that than require semicolons everywhere. I have a feeling that more would object but just aren't perusing the mailing lists. I think we will see much more activity come WWDC Brandon > On May 31, 2016, at 12:25 PM, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > > In English (and, I'm guessing, many other languages), semicolons are used as > a second 'tier' of separators when commas become ambiguous. I'm puzzled that > a proposal to bring this longstanding convention to Swift is raising so many > objections, even going so far as to prompt alternatives such as this that > break clearly useful shorthands. > >> On Tue, May 31, 2016 at 10:44 David Hart via swift-evolution >> <[email protected]> wrote: >> Yet another alternative: would it be possible to disallow commas as variable >> declaration separators and use them for condition clause separators again: >> >> let a = 4, b = 8 // becomes illegal and requires to separate them on two >> lines >> >> if a > 4, let c = foo(), let d = bar(), c != d { // now comma is not >> ambiguous anymore >> } >> >> David. >> >>>> On 28 May 2016, at 02:30, Erica Sadun via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> >>>>> On May 27, 2016, at 6:26 PM, Brent Royal-Gordon <[email protected]> >>>>> wrote: >>>>> >>>>> guard >>>>> x == 0 && a == b && c == d && >>>>> let y = optional, w = optional2, v = optional 3 && >>>>> z == 2 >>>>> else { ... } >>>>> >>>>> Figuring out where to break the first line into expression and into >>>>> condition (after the `d`) could be very challenging to the compiler. >>>> >>>> I'm not sure it is. `let` and `case` are not valid in an expression, so an >>>> `&&` followed by `let` or `case` must be joining clauses. On the other >>>> side of things, Swift's `&&` doesn't ever produce an optional, so if we're >>>> parsing an expression at the top level of an if-let, an `&&` must indicate >>>> the end of the clause. An if-case *could* theoretically include an `&&`, >>>> but pattern matching against a boolean value seems like a fairly useless >>>> thing to do in a context that's specifically intended to test booleans. >>> >>> Let me answer in another way that speaks to my background which isn't in >>> compiler theory: The use of && may produce cognitive overload between the >>> use in Boolean assertions and the use in separating condition clauses. >>> >>> -- 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
