更新これはSwift3.1で修正されています
をステートメントに移行する際if-elseに、switch型推論が機能していないことに気づきました。なぜ私が指定する必要がありますHKQuantityTypeIdentifier各caseときquantityTypeIdentifier、すでにその型のでしょうか？
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
}
それはコンパイルされません。.red1行目では言うことができますが、3行目では言えません。それは明らかに矛盾しているようです。
そうは言っても、2つの異なる場所でルールが異なる理由を確かに説明できます。case発現は、に従って解決される~=オペレータと形成の規則パターン。これらのルールは、Swiftの他のルールとは異なります（したがって、たとえば、パターンで言うasが、他のすべての場所で言う状況があります）。したがって、明らかに、これが機能するために微調整が必要なルールです。それらは、裸の列挙型ケースを許可するが、裸の列挙型のような構造体「ケース」（つまり、静的メンバーが構造体自体のインスタンスに評価されるRawRepresentableである構造体の静的メンバー）を許可しないように調整されています。caseas?
最後に、ここで私はときに使用したいというskanky回避策だcaseパターンがあまりにも面倒になるには：
let c : UIColor = .red
switch true {
case c == .red : print ("red") // heh heh
default : break
}
切り替えることでtrue、全体のブール条件をして書き出す我々は、パターンマッチングの限界を打破し、正常な表現の世界を再入力します。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加