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

[Benjamin Spratling]

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

> On Nov 1, 2016, at 11:28 PM, rintaro ishizaki <fs.output at gmail.com> wrote:
> 
> 
> 2016-11-02 13:14 GMT+09:00 Benjamin Spratling via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto: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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/8b302996/attachment.html>