I see what you’re saying now. Thanks. -Ben > On Nov 1, 2016, at 11:28 PM, rintaro ishizaki <[email protected]> wrote: > > > 2016-11-02 13:14 GMT+09:00 Benjamin Spratling via swift-evolution > <[email protected] <mailto:[email protected]>>: > > 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 >> <[email protected] <mailto:[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] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
