You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SR-7532 "Class should not be declared public..." shouldn't apply to type aliases for public types
Issue Description:
In some scenarios it is useful to declare typealiases internally to a module, to make it easier to implement the functionality of the module itself, but less useful to impose that typealias on clients of the module. For example, consider an image manipulation framework that can work with NSImage or UIImage instances, depending on the platform. Internally to the module, I might define:
Since I haven't marked my typealiases as 'public', the above would fail to compile. But if I mark the typealiases public, I impose a new type "RSPlatformNativeImage" on clients, when as far as they are concerned NSImage or UIImage would do the trick.
There's probably some generics + protocol way to tackle this, but that would also entail exposing unccessary type clutter (IMHO) to clients.
What would be nice in this situation is instead of giving a compiler error, Swift could simply export the method using the public type that the typealias resolves to. In which case a client of the module on iOS would see the method as:
Making Swift handle internal typealiases in this way would cause its behavior to match what is already done for Objective-C clients. The generated -Swift.h for this method in a Mac project is:
See discussion with @AnthonyLatsis on SR-7532. The summary is that there's no real way to tell if a developer meant for a typealias to be used publicly in a function declaration (and therefore wants to know if it can't be) or if it's just being used for convenience. I think any change here would have to go through the Swift Evolution Process.
Additional Detail from JIRA
md5: 83e86eed043a729fd2b9a914aaaead84
relates to:
Issue Description:
In some scenarios it is useful to declare typealiases internally to a module, to make it easier to implement the functionality of the module itself, but less useful to impose that typealias on clients of the module. For example, consider an image manipulation framework that can work with NSImage or UIImage instances, depending on the platform. Internally to the module, I might define:
Then I can implement methods, including public facing methods like:
Since I haven't marked my typealiases as 'public', the above would fail to compile. But if I mark the typealiases public, I impose a new type "RSPlatformNativeImage" on clients, when as far as they are concerned NSImage or UIImage would do the trick.
There's probably some generics + protocol way to tackle this, but that would also entail exposing unccessary type clutter (IMHO) to clients.
What would be nice in this situation is instead of giving a compiler error, Swift could simply export the method using the public type that the typealias resolves to. In which case a client of the module on iOS would see the method as:
Making Swift handle internal typealiases in this way would cause its behavior to match what is already done for Objective-C clients. The generated -Swift.h for this method in a Mac project is:
Thus for Objective-C clients the clutter of the typelias definition is tidied away, but for Swift clients, it must be dealt with.
The text was updated successfully, but these errors were encountered: