CGRect(origin:.zero, size:..
is pretty nice. Why do you want to get rid of it?
return values
.flatMap {
//code
}
.filter {
//code
}
.sorted { /* code */ }
.first
is also pretty clean, considering.
> On Nov 1, 2016, at 11:06 PM, rintaro ishizaki via swift-evolution
> <[email protected]> wrote:
>
> Hi all,
>
> The compiler currently accepts these expressions:
>
> x = expr . member
> x = expr .
> member
> x = expr
> .
> member
> x = .
> implicitMember
>
> I propose to reject them because this could cause some unnecessary confusion.
> (especially after SE-0071
> <https://github.com/apple/swift-evolution/blob/master/proposals/0071-member-keywords.md>)
> For instance:
>
> _ = foo(.
> func bar(x: Int) { ... }
>
> The current compiler parses this as:
>
> // call foo(_:_:)
> _ = foo(.func // implicit-member-expression
> // missing ','
> // call bar(x:_:) with argument 'Int' and trailing closure
> bar(x: Int) { ... }
> // missing closing ')'
>
> Here's the summary of current behavior:
>
> // accept
> expr.member
>
> // accept
> expr .member
>
> // accept
> expr
> .member
>
> // reject with fix-it to remove white spaces
> expr. member
>
> // two distinct statements
> expr. // reject as missing member name
> member
>
> // accept
> expr . member
>
> // accept
> expr .
> member
>
> I propose to change the last 2 examples:
>
> // reject with fix-it to remove white spaces
> some . member
>
> // two distinct statements
> some . // reject as missing member name
> member
>
> I think, this is consistent behavior with '.' at postfix position.
>
> Specifically:
> If '.' is at prefix-operator or unspaced-binary-operator position, accept.
> If the next token after '.' is at the same line, propose to fix-it.
> Otherwise, reject it as missing member name.
> This affect following expressions and types in the grammer:
>
> expressions:
> self-method-expression
> self-initializer-expression
> superclass-method-expression
> superclass-initializer-expression
> implicit-member-expression
> initializer-expression
> explicit-member-expression
> postfix-self-expression
> explicit-member-expression
> postfix-self-expression
> types:
> type-identifier
> metatype-type
>
> Of course this is a source breaking change, though.
> Any thought?
>
> _______________________________________________
> 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
