> On 28 May 2016, at 10:37 AM, Matthew Johnson via swift-evolution
> <[email protected]> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
