[swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

[Patrick Smith]

> On 28 May 2016, at 10:37 AM, Matthew Johnson via swift-evolution <swift-evolution at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160528/5d360c7b/attachment.html>