[swift-evolution] commas optional

[Dave Yost]

Nuance:

Compiler says:
    Expression following ‘return’ is treated as an argument of the 'return'.
unless foo() is indented by at least one space. Then there is no complaint.

> On 2017-10-15, at 4:32 PM, Dave Yost <dave at yost.com> wrote:
> 
> Very cool!
> 
> func foo() -> Int { return 17 }
> 
> func bug1() -> Int {
>     return
>     foo()  // Compiler says: Expression following ‘return'
>            //    is treated as an argument of the 'return'.
> }
> 
> var x = 0
> 
> func bug2() {
>     return x = 4 // not even a warning – should be an error
> }
> 
> print(bug1()) // prints 17
> bug2()
> 
> Dave
> 
> bug1() suggests that return be one of perhaps a set of special cases where line wrap is illegal.
> 
> bug2() is a compiler bug IMO.
> 
>> On 2017-10-15, at 8:32 AM, Mike Kluev via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> on Date: Fri, 13 Oct 2017 20:21:22 -0700 Chris Lattner <clattner at nondot.org <mailto:clattner at nondot.org>> wrote:
>> 
>> We already have whitespace sensitive rules to handle this.  There is no fundamental implementation difference that I see between separating the elements of lists (which are expressions) and the elements of statements (which can be expressions):
>> 
>> func foo() -> Int { … }
>> 
>> func statements() {
>>   foo()
>>   foo()
>> }
>> 
>> let list = [
>>   foo()
>>   foo()
>> ]
>> 
>> i was beaten by these optional semicolons...
>> 
>> override func viewDidLoad() {
>> 	super.viewDidLoad()
>> 	return	// put it ad-hoc to temporarily circumvent the rest of the code
>> 		
>> 	someView = SomeView(frame: view.bounds)	// *
>> 	view.addSubview(someView)			// **
>> 	...
>> }
>> 	
>> so i put that ad-hoc return statement to circumvent the rest of the code temporarily. of course i didn't put a semicolon after "return" as that skill was long lost. to my surprise the app crashed, and nowhere else but in the code that i thought was disabled...
>> 
>> further investigation showed that in this case compiler was treating the statement after return which happened to have the matching type “Void” as part of return statement.
>> 
>> should the function return type was, say, Int - that wouldn’t happen. or should the next statement was of a different type - that wouldn’t happen. in this case i was just “lucky”. here semantic information (matching vs non matching types) is clearly "aiding" syntax parsing and sometimes it leads to a surprising results.
>> 
>> there was a warning on the * line:
>> “warning: expression following 'return' is treated as an argument of the 'return’”
>> 
>> and another warning on the ** line:
>> “warning: code after 'return' will never be executed”
>> 
>> as i was prepared to get the warning about the code being unused in the first place, i didn’t pay too much attention to the exact wording of that warning... and was beaten by it.
>> 
>> Mike
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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/20171015/deae7a76/attachment.html>