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

[rintaro ishizaki]

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161102/79bf767f/attachment.html>