[3/x] Improve compile-time checks for Swift mocks

[andrewchang-bird]

Stack

📚 #275 [5/x] Clean up Synchronized wrapper
📚 #274 [4/x] Fix nested optional property and Obj-C types
📚 #273 ← [3/x] Improve compile-time checks for Swift mocks
📚 #272 [2/x] Remove Obj-C based nil check
📚 #271 [1/x] Add Algolia DocSearch to the documentation

Overview

The Objective-C overloads introduced in 0.18 makes it difficult for the Swift compiler to choose the correct branch when type checking given expressions. This is exacerbated with the stubbing operator which can provide incorrect constraints on the return type, preventing implicit bridging of optionals and Foundation types.

protocol Foo {
  var nonOptional: String { get }
  var optional: String? { get }
  var bridged: NSString { get }
}
var stored: String! = "foo"
given(myMock.nonOptional) ~> stored  // Compiler fails to coerce `String?` to `String`
given(myMock.optional) ~> "foo"  // Compiler fails to coerce `String` to `String?`
given(myMock.bridged) ~> "foo"  // Compiler fails to coerce `String` to `NSString`

Additionally, closure-based stubs on Swift methods aren’t protected against changes to the function signature and silently fall back to use Objective-C wildcard stubbing.

Although the issues likely won’t surface frequently, they are very big foot guns. A few non-mutually exclusive options considered:

1. De-unify the static and dynamic stubbing APIs with given and givenDynamic. This is a source-incompatible change and makes the API less ergonomic. In addition, the dynamic stubbing path is not just used for Objective-C mocks, but also for the Swift property syntax given(myMock.property).
2. Catch malformed Swift stubs with a more specific overload of given. Due to how the compiler picks overloads, the new function can only be annotated with a deprecated or obsoleted warning, but not unavailable error.
3. Declare a new stubbing API givenSwift to surface compiler errors or disambiguate the type checking when using the stubbing operator.

The best options are to pair (2) and (3), with the intention that givenSwift is only used for debugging warnings emitted by (2) or in cases where it’s more ergonomic to not provide explicit type annotations (e.g. for complex closure stubs).

Test Plan

• No stubbing warnings in MockingbirdTests
• CI tests pass