If we can do this efficiently this sounds like a great idea. Even if we can't do it efficiently it might be a good idea in Debug builds.

Comment by Andrew Bennett (JIRA)

Thanks for taking a look Jordan!

one note on this; the Darwin version of Foundation actually sometimes uses null as a placeholder sentry value in initializers purposefully to implement certain functionality that is contrary to the declaration of non null in the interface to serve as a internal behavior. If this were added we would need a way to either opt in or opt out of this behavior.

Philippe, I don't think we ever want to support that in Swift. Instead, you'd just make two entry points, one of them public and one of them internal (and thus testable).

how could one make a public and internal exposition in objc?
e.g. -[NSLocale init] calling -[NSLocale initWithLocaleIdentifier:nil] even though initWithLocaleIdentifier: naturally is nonnull

This would be a better pattern:

public init() {
  self.init(localeIdentifierImpl: nil)
}

public init(localeIdentifier: String) {
  self.init(localeIdentifierImpl: localeIdentifier)
}

internal init(localeIdentifierImpl: String?) {
  // Actual work here.
}

again how do I write that in objective-c?

- (id)init { return [self initWithLocaleIdentifier: nil]; }
- (id)initWithLocaleIdentifier:(NSString *)ident { ... }

If the compiler inserts the assertion that would make a function that would previously not crash and return nil now crash if I am understanding the request correctly.

This particular request is that the synthesized Objective-C entry points for Swift code include nil checks. It wouldn't change anything actually written in Objective-C.

I guess I misread it then; disregard my concern then. Your suggestion would be by far preferable in a swift world - most of these cases are from factory patterns anyhow.

Comment by Andrew Bennett (JIRA)

This is related to a newly discovered issue https://bugs.swift.org/browse/SR-11040