> On 28 May 2016, at 10:37 AM, Matthew Johnson via swift-evolution > <swift-evolution@swift.org> wrote: > > But I don't know what that has to do with the fact that newline can be used > as an alternative. It's just an alternate separator. As far as I know, > everywhere semicolons are used as separators newlines are accepted as an > alternate separator.
Looks like an interesting proposal. I agree that the use of semicolons being interchangeable with newline separators should be consistent in their usage. Otherwise there’s one approach to learn for members of a type, one for arrays and dictionaries, one for generic parameters, one for a list of clauses, one for pattern matching, one for tuples. Each of these have different rules it seems? Not sure what the best rule and separator to use is, but it would be nice to have something consistent, even if it was more strict in places than today’s rules. Even if when different hierarchies that are used together, such as pattern matching with multiple parts and multiple boolean expressions, then it would be nice for these to have a different separator so they can never clash and step on each others’ toes. Maybe this is the comma and semicolon (/newline). A different train of thought: could semicolons allow the closure ambiguity to be resolved that Chris brought up a couple of months ago? e.g. if numbers.contains { $0 > 7 }; { // ... } // Or newlines if numbers.contains { $0 > 7 } { // ... } I imagine it wouldn’t, as the parser would always catch that first ‘{‘ as an opening brace? Would be nice to solve this if possible too. Patrick
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution