【问题标题】:Type inference fails when using nil-coalescing operator with two optionals使用带有两个选项的 nil-coalescing 运算符时类型推断失败
【发布时间】:2016-01-18 14:05:16
【问题描述】:

我们正在尝试确定这是 Swift 中的错误,还是我们滥用泛型、可选项、类型推断和/或 nil 合并运算符。

我们的框架包含一些用于将字典解析为模型的代码,我们遇到了一个带有默认值的可选属性的问题。

我们有一个协议SomeProtocol 和一个协议扩展中定义的两个通用函数:

mapped<T>(...) -> T?
mapped<T : SomeProtocol>(...) -> T?

我们的结构和类遵循此协议,然后在协议所需的 init 函数中解析它们的属性。

init(...) 函数中,我们尝试像这样设置属性someNumber 的值:

someNumber = self.mapped(dictionary, key: "someNumber") ?? someNumber

字典当然包含键 someNumber 的实际值。但是,这将始终失败,并且永远不会从 mapped() 函数返回实际值。

注释掉第二个泛型函数或强制向下转换赋值的 rhs 值将解决此问题,但我们认为这应该按照当前编写的方式工作。


以下是演示问题的完整代码 sn-p,以及两个选项(临时)修复代码中标记为 OPTION 1OPTION 2 的问题:

import Foundation

// Some protocol

protocol SomeProtocol {
    init(dictionary: NSDictionary?)
}

extension SomeProtocol {
    func mapped<T>(dictionary: NSDictionary?, key: String) -> T? {
        guard let dictionary = dictionary else {
            return nil
        }

        let source = dictionary[key]
        switch source {

        case is T:
            return source as? T

        default:
            break
        }

        return nil
    }

    // ---
    // OPTION 1: Commenting out this makes it work
    // ---

    func mapped<T where T:SomeProtocol>(dictionary: NSDictionary?, key: String) -> T? {
        return nil
    }
}

// Some struct

struct SomeStruct {
    var someNumber: Double? = 0.0
}

extension SomeStruct: SomeProtocol {
    init(dictionary: NSDictionary?) {
        someNumber = self.mapped(dictionary, key: "someNumber") ?? someNumber

        // OPTION 2: Writing this makes it work
        // someNumber = self.mapped(dictionary, key: "someNumber") ?? someNumber!
    }
}

// Test code

let test = SomeStruct(dictionary: NSDictionary(object: 1234.4567, forKey: "someNumber"))
if test.someNumber == 1234.4567 {
    print("success \(test.someNumber!)")
} else {
    print("failure \(test.someNumber)")
}

请注意,这是一个缺少mapped 函数的实际实现的示例,但结果是相同的,就这个问题而言,代码应该足够了。


编辑:我之前报告过这个问题,现在它被标记为已修复,所以希望在 Swift 3 中不再发生这种情况。
https://bugs.swift.org/browse/SR-574

【问题讨论】:

    标签: swift generics optional


    【解决方案1】:

    您为编译器提供了太多选项,而它选择了错误的选项(至少不是您想要的选项)。问题是每个T 都可以简单地提升到T?,包括T?(提升到T??)。

    someNumber = self.mapped(dictionary, key: "someNumber") ?? someNumber
    

    哇。这样的类型。所以可选。 :D

    那么 Swift 是如何开始解决这个问题的。好吧,someNumberDouble?,所以它试图把它变成:

    Double? = Double?? ?? Double?
    

    这行得通吗?让我们从最具体的开始寻找一个通用的mapped

    func mapped<T where T:SomeProtocol>(dictionary: NSDictionary?, key: String) -> T? {
    

    要完成这项工作,T 必须是 Double?。是Double?:SomeProtocol?没有。继续前进。

    func mapped<T>(dictionary: NSDictionary?, key: String) -> T? {
    

    这行得通吗?当然! T 可以是Double? 我们返回Double?? 一切都会解决。

    那么为什么这个有效呢?

    someNumber = self.mapped(dictionary, key: "someNumber") ?? someNumber!
    

    这解析为:

    Double? = Optional(Double? ?? Double)
    

    然后事情就会按照你认为的方式进行。

    小心使用这么多的 Optional。 someNumber 真的必须是可选的吗?这些东西应该throw吗? (我并不是建议 throw 是解决可选问题的一般解决方法,但至少这个问题让您有时间考虑这是否真的是一个错误情况。)

    在 Swift 中像 mapped 那样只对返回值进行类型参数化几乎总是一个坏主意。这在 Swift 中往往是一个真正的混乱(或任何具有大量类型推断的通用语言,但是当涉及到 Optional 时,它在 Swift 中真的会爆炸)。类型参数通常应该出现在参数中。如果您尝试以下操作,您会看到问题:

    let x = test.mapped(...)
    

    它将无法推断x 的类型。这不是一种反模式,有时麻烦是值得的(公平地说,您要解决的问题可能就是其中一种情况),但如果可以的话,请避免它。

    但要害你的是 Optionals。


    编辑:Dominik 提出了一个很好的问题,即为什么在删除 mapped 的受限版本时它的行为会有所不同。我不知道。显然,类型匹配引擎会根据mapped 是通用的方式,以稍微不同的顺序检查有效类型。您可以通过将print(T.self) 添加到mapped&lt;T&gt; 来查看这一点。这可能被认为是编译器中的错误。

    【讨论】:

    • 这是一个很好的解释。我可以理解您的观点,并且可以理解为什么 someNumber! 有效,但我不确定当您注释掉 mapped&lt;T where T:SomeProtocol&gt;... 函数时代码是否按预期工作。您能否对此发表更多评论?
    • 这样的选项,很头疼。 :D
    猜你喜欢
    • 2020-04-05
    • 2011-12-12
    • 1970-01-01
    • 2017-09-05
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多