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 <d...@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@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>> on Date: Fri, 13 Oct 2017 20:21:22 -0700 Chris Lattner <clatt...@nondot.org
>> <mailto:clatt...@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@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
