For the most part, the method names we’ve chosen in Objective-C make sense in Swift as well. However, there are some cases where the method name feels more verbose than usual, especially when the name describes a parameter’s type in addition to its role.
We should audit the entire API for opportunities to make Swift code read better. Now that realm/jazzy#136 has made it into our build system, we can annotate APIs with NS_SWIFT_NAME where they provide some measure of relief for Swift coders. For example, in #5110, visibleFeaturesAtPoint(_:inStyleLayersWithIdentifiers:) becomes visibleFeatures(at:styleLayerIdentifiers:), consistent with the Swift API design guidelines.
Considering the widespread changes that will be made to Foundation class naming in Swift 3, we should take care of this work around the time people are upgrading to the upcoming release of Xcode, so our changes won’t be breaking changes relative to the language itself.
/cc @friedbunny @boundsj @tmcw
For the most part, the method names we’ve chosen in Objective-C make sense in Swift as well. However, there are some cases where the method name feels more verbose than usual, especially when the name describes a parameter’s type in addition to its role.
We should audit the entire API for opportunities to make Swift code read better. Now that realm/jazzy#136 has made it into our build system, we can annotate APIs with
NS_SWIFT_NAMEwhere they provide some measure of relief for Swift coders. For example, in #5110,visibleFeaturesAtPoint(_:inStyleLayersWithIdentifiers:)becomesvisibleFeatures(at:styleLayerIdentifiers:), consistent with the Swift API design guidelines.Considering the widespread changes that will be made to Foundation class naming in Swift 3, we should take care of this work around the time people are upgrading to the upcoming release of Xcode, so our changes won’t be breaking changes relative to the language itself.
/cc @friedbunny @boundsj @tmcw