[Pitch] Limiting member expression with right-bound period


#1

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(_:_:slight_smile:
_ = foo(.func // implicit-member-expression
        // missing ','
        // call bar(x:_:slight_smile: 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?


(Benjamin Spratling) #2

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 <swift-evolution@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(_:_:slight_smile:
_ = foo(.func // implicit-member-expression
        // missing ','
        // call bar(x:_:slight_smile: 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


#3

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 {

···

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

//code
}
.sorted { /* code */ }
.first

is also pretty clean, considering.

On Nov 1, 2016, at 11:06 PM, rintaro ishizaki via swift-evolution < > swift-evolution@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(_:_:slight_smile:
_ = foo(.func // implicit-member-expression
        // missing ','
        // call bar(x:_:slight_smile: 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Benjamin Spratling) #4

I see what you’re saying now. Thanks.
-Ben

···

On Nov 1, 2016, at 11:28 PM, rintaro ishizaki <fs.output@gmail.com> wrote:

2016-11-02 13:14 GMT+09:00 Benjamin Spratling via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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(_:_:slight_smile:
_ = foo(.func // implicit-member-expression
        // missing ','
        // call bar(x:_:slight_smile: 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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution