swift - "Parameters may not have the ' var ' specifier"swift 3 编译错误

Question

在 swift 3 中使用 inout 参数编码时，我一直遇到这个错误。以下代码会产生错误:

class Example {
var a : Int
    init(_ a: Int) {
        self.a=a
    }
}

let closure = { val in val.a = 7 } as (inout Example) -> ()
var v = Example(6)
closure(&v)

控制台:

Playground execution failed: error: parameters may not have the 'var' specifier

* thread #1: tid = 0x12e365d, 0x00000001071d33c0 MyPlayground`executePlayground, queue = 'com.apple.main-thread', stop reason = breakpoint 1.2
  * frame #0: 0x00000001071d33c0 MyPlayground`executePlayground
    frame #1: 0x00000001071d29c0 MyPlayground`__37-[XCPAppDelegate enqueueRunLoopBlock]_block_invoke + 32
    frame #2: 0x0000000107cee6ac CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 12
    frame #3: 0x0000000107cd36f4 CoreFoundation`__CFRunLoopDoBlocks + 356
    frame #4: 0x0000000107cd2e65 CoreFoundation`__CFRunLoopRun + 901
    frame #5: 0x0000000107cd2884 CoreFoundation`CFRunLoopRunSpecific + 420
    frame #6: 0x000000010d172a6f GraphicsServices`GSEventRunModal + 161
    frame #7: 0x0000000108880c68 UIKit`UIApplicationMain + 159
    frame #8: 0x00000001071d26e9 MyPlayground`main + 201
    frame #9: 0x000000010b2b468d libdyld.dylib`start + 1

这段代码有错吗？这个错误来自哪里？会不会是编译器错误？

Answer 1

如何避免错误？

您似乎只是想声明一个 () 返回闭包，其中包含一个自定义类型的 inout 参数。为此，无需使用类型转换(使用 as)来帮助编译器推断闭包的类型。

您可以(正如@Hamish 所指出的那样)简单地在闭包主体内注释 inout 参数类型，这足以让编译器将闭包类型推断为 (inout Example ) -> ():

let closure = { (val: inout Example) in val.a = 7 }

或者，您可以显式键入注释闭包的类型:

let closure: (inout Example) -> () = { val in val.a = 7 }

---

偏离点的误诊错误 -> 考虑提交错误报告

尽管如此，您示例中的编译器错误是误诊，可能值得提交错误。

• https://bugs.swift.org/

似乎已经有一些错误报告，其中由于 inout 参数使用(在不同的上下文中)导致的错误会产生令人困惑的错误消息“参数可能没有 'var '说明符";例如

• SR-2354: inout parameter in subscript gives the wrong error message
• SR-3644: Misleading diagnostics: parameters may not have the 'var' specifier

提交一个错误报告，当尝试像上面那样声明一个闭包(使用 as)时，这个错误诊断也会显示，这对 Swift 团队来说可能是有值(value)的信息(额外的 inout 到错误消息案例)，即使我们永远不想在示例的声明上下文中使用 as 。正如@matt 在评论中所写。

"The Swift team have specifically called out that they want to improve compiler error messages."