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

[Benjamin Spratling]

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 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161101/04fca6c2/attachment.html>