我们可以确保 `+ (nonnull instancetype)sharedInstance;` 的可空性吗？

这是一个关于如何优雅地规避可空性的问题init in NSObject class.

这是一个经典的 Objective-C 实现：

+ (instancetype)sharedInstance
{
    static dispatch_once_t onceToken;
    static id sharedInstance;
    dispatch_once(&onceToken, ^
    {
        sharedInstance = [[self alloc] init];
    });
    return sharedInstance;
}

但现在我想将其声明为nonnull， 如果可能的话：

+ (nonnull instancetype)sharedInstance;

很遗憾，init返回一个nullable instancetype价值。我应该添加一个NSAssert或者打电话后的事情init?

我注意到有些人甚至文档nonnull现实中的价值观nullable https://github.com/LaunchKit/launchkit-ios/blob/1.1.2/LaunchKit/Classes/LaunchKit.h。那有意义吗？

我应该大胆地添加NS_ASSUME_NONNULL_BEGIN无处不在，但没有真正确保价值观nonnull?

这里似乎有两个问题：

1. 我如何确保我的单例中产生的价值sharedInstance方法并且该方法返回的值在运行时实际上不是nil？

2. 我如何满足为空注释、编译器警告和 Swift 桥接系统的要求nonnull指针？

确保/执行nonnull

在某些时候，每个 API 合约都会分解为人类合约。例如，编译器可以帮助确保您不能获取 a 的结果nullable调用并从返回类型为的方法返回它nonnull...但是在某个地方通常有一个原始调用，其返回类型是nonnull仅仅因为编写它的程序员说：“我保证永远不会返回 null，交叉我的心，等等。”

如果您熟悉 Swift，这与隐式解包选项的情况类似——当您“知道”某个值不能为 nil，但无法向编译器证明该知识时，您可以使用这些选项，因为该知识是外部的源代码（例如，来自情节提要或捆绑资源的内容）。

这就是这里的情况——你“知道”init永远不会返回 nil，要么是因为您编写/有相关初始化程序的源代码，要么是因为它只是NSObject's init其记录为return self不做任何事情。对该初始化程序的调用将失败的唯一情况是因为前面的alloc调用失败（因此您正在调用一个方法nil，它总是返回nil). If alloc返回零，你已经在恐怖海峡 http://thelaundryfiles.wikia.com/wiki/Case_Nightmare_Green对于这个世界来说，你的流程并不长——这并不是设计 API 的失败案例。

（可空性注释通常用于描述 API 的预期用途，而不是更极端的边缘和角落情况。如果 API 调用仅由于以下原因而失败普遍错误 https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst将其注释为可为空是没有意义的；同样，如果 API 仅在可通过非空参数注释排除的输入上失败，则返回值可假定为非空。）

所以，长话短说：是的，只是把NS_ASSUME_NONNULL围绕你的标题，并运送你的sharedInstance按原样实施。

返回一个nonnull可为空的

这里的情况并非如此，但假设您有一个注释为的值nullable，但你知道（或“知道”）它永远不会为零并且想从你的nonnull- 带注释的方法。并且您处于这样的情况：尝试时会收到编译器警告。

有一个语法 - 只需将值转换为预期的返回类型、注释和所有内容：

return (NSWhatever *_Nonnull)whatever;

在你的情况下，这不需要 - 因为你正在处理id and instancetype特殊类型编译器对可空性转换更加宽容，并且可能不会一开始就发出警告。