微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

为什么类型推断在Swift 3中的这个switch语句中不起作用?

更新这在 Swift 3.1中得到修复

在将if-else迁移到switch语句时,我注意到类型推断不起作用.当quantityTypeIdentifier已经属于该类型时,为什么我需要在每种情况下都指定HKQuantityTypeIdentifier?

func process(samples: [HKSample]?,quantityTypeIdentifier: HKQuantityTypeIdentifier) {
    dispatchQueue.main.async { [weak self] in            
        if let quantitySamples = samples as? [HKQuantitySample] {
            for sample in quantitySamples {
                switch quantityTypeIdentifier {
                case HKQuantityTypeIdentifier.distanceWalkingRunning:
                    // code

                case HKQuantityTypeIdentifier.activeEnergyBurned:
                    // code

                case HKQuantityTypeIdentifier.heartRate:
                    // code

                default:
                    fatalError("Quantity Type Identifier not implemented \(quantityTypeIdentifier)")
                }
            }
        }
    }
}

我能够调用这样的函数

process(samples: samples,quantityTypeIdentifier: .distanceWalkingRunning)
我认为你发现了一个错误,或者至少你有一个合理的案例要求一个.一个更短的例子很好地显示了不一致性:
let c : UIColor = .red
switch c {
case .red : print ("red") // error
default : break
}

那不会编译.您可以在第一行说出.red但在第三行没有.red.这似乎是一个明显的不一致.

现在,说了这些,我当然可以解释为什么规则在两个不同的地方有所不同.根据〜=运算符和形成模式的规则来解析案例表达式.这些规则与Swift中的任何其他规则都不同(因此,例如,在某些情况下,您可以像在案例模式中那样说,但在其他地方也可以这样说).显然,这些是需要调整以使其工作的规则.它们已经被调整到允许裸枚举的情况但不是简单的枚举结构“情况”(即,那些静态成员评估结构本身实例的RawRepresentable结构的静态成员).

最后,当案例模式变得过于繁重时,我喜欢使用这种方法

let c : UIColor = .red
switch true {
case c == .red : print ("red") // heh heh
default : break
}

通过接通true并写出整个布尔条件,我们打破了模式匹配的界限并重新进入正常表达式的世界.

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 [email protected] 举报,一经查实,本站将立刻删除。

相关推荐