[swift-evolution] commas optional

Dave Yost Dave at Yost.com
Sun Oct 15 18:32:44 CDT 2017


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> 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
> 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/b49500b0/attachment.html>


More information about the swift-evolution mailing list