Objective-C：在可空性注释违规时强制编译错误答案

【问题标题】：Objective-C: enforce compile error upon nullability annotation violationObjective-C：在可空性注释违规时强制编译错误
【发布时间】：2017-10-19 06:29:18
【问题描述】：

背景

我们一直在开发公共动态 iOS / macOS 框架。该框架是用 Objective-C 编写的，但它与 Swift 完全兼容。

最近，我们为我们的一种公共 API 方法更改了可空性注释：

来自

- (void)setServer:(nullable ABCLocation *)location;

到

- (void)setServer:(nonnull ABCLocation *)location;

，因此开发人员需要创建 [ABCLocation default] 实例并将其传递给新的 API。

问题

现在，我们关心的是，如何强制/通知开发人员围绕我们的新 API 更改他们现有的代码？

将 API 与 Swift 一起使用时，它似乎可以通过抛出错误很好地处理可空性。

但是，

Objective-C 只有在传递 nil 时才会生成警告，而当开发人员将 nullable 属性传递给方法时，Xcode 什么也不做。

我们如何强制开发人员更改他们的 API？这里的常见做法是什么？

UPD：

我们将框架作为二进制文件分发，使用 Release 配置构建，其中关闭了断言。

UPD #2：

到目前为止，我们已经接受了从 Objective-C 使用 API 的现实。但是，我们实现了“故障安全”行为：如果传递了nil，则该方法在内部创建[ABCLocation default] 实例并隐式传递它。

【问题讨论】：

"当开发人员将一个可为空的属性传递给方法时，Xcode 什么也不做。"还有其他问题，如果情况确实如此，您应该收到警告。

标签： ios objective-c ios-frameworks

【解决方案1】：

在未满足注释时生成警告是一种很好的做法。在 API 中进行 nullable -> nonnull 之类的更改是不行的。

【讨论】：

能否请您具体谈谈“在 API 中进行 nullable 之类的更改 -> nonnull 不是[一个好的做法]”？
我的意思是，在 API 中对可疑用途进行重大更改通常不是一个好主意
同意。谢谢你的帮助！正如我在 UPD #2 中提到的，我们添加了一个“故障安全”行为，以免破坏。将您的答案标记为已接受，这与我做出的最终决定相关。

【解决方案2】：

当您无法让编译器强制执行错误（例如在您的实例中）时，一种常见的做法是引发运行时错误。比如：

- (void)setServer:(nonnull ABCLocation *)location    
{
    if (!location) {
        NSAssert(NO, @"Location must not be nil");
    }

这并不理想，但是传递 nil 时的编译器警告和误用引发的运行时错误的组合对于错误地使用您的框架的开发人员来说应该很清楚。

【讨论】：

我们以使用 Release 配置构建的二进制形式分发框架，其中关闭了断言。忘记提了。我已经更新了问题。