Joe Groff wrote: > ## Impact on existing code > > The number of `@noreturn` functions in the wild is fairly small, and all of > them I can find return `Void`. It should be trivial to migrate > existing `@noreturn` functions to use `-> NoReturn`.
Clang allows `_Noreturn` [C11] and `__attribute__((noreturn))` [GCC] functions to have a non-void return type. NSApplicationMain and UIApplicationMain have an integer return type, but they never return. (There might be similar functions in other libraries). If these functions could add `_Noreturn` without breaking binary compatibility, should SE-0102 be rejected? > ### Naming `NoReturn` > > The best name for the standard library uninhabited type is up for debate. > `NoReturn` seems to me like the name most immediately obvious to most users > compared to these alternatives: Would an `Unreachable` type name match the SIL and Clang terms? <https://github.com/apple/swift/blob/master/docs/SIL.rst#unreachable> <http://clang.llvm.org/docs/LanguageExtensions.html#builtin-unreachable> If empty "ad hoc enums" were available, you wouldn't need to choose a name! <http://thread.gmane.org/gmane.comp.lang.swift.evolution/19210> Off-topic: * Could "incomplete struct types" also be imported as empty enums? * Would the Swift.OpaquePointer then become a generic type? -- Ben _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
