[swift-evolution] [Pitch] Limiting member expression with right-bound period

[rintaro ishizaki]

2016-11-02 13:14 GMT+09:00 Benjamin Spratling via swift-evolution <
swift-evolution at swift.org>:

>
> CGRect(origin:.zero, size:..
>
> is pretty nice.  Why do you want to get rid of it?
>

No, I'm proposing to reject CGRect(origin:.  zero, size:..)

 '.' whitespace identifier

Reject whitespace in this.

 '.' identifier

is OK.



>
>
> return values
> .flatMap {
>

is OK. but

  return valus
        .
        flatMap {

should be rejected.



> //code
> }
>
.filter {
> //code
> }
> .sorted { /* code */   }
> .first
>
> is also pretty clean, considering.
>
>
> On Nov 1, 2016, at 11:06 PM, rintaro ishizaki via swift-evolution <
> swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161102/e98742f7/attachment.html>