Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-7622] Non-public typealias should be exported as public equivalent when possible #50164

Open
swift-ci opened this issue May 7, 2018 · 5 comments

Comments

@swift-ci
Copy link
Collaborator

swift-ci commented May 7, 2018

Previous ID SR-7622
Radar None
Original Reporter jalkut@red-sweater.com (JIRA User)
Type Improvement
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Improvement, LanguageFeatureRequest
Assignee None
Priority Medium

md5: 83e86eed043a729fd2b9a914aaaead84

relates to:

  • 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:

#if os(macOS)
    typealias RSPlatformNativeImage = NSImage
#else
    typealias RSPlatformNativeImage = UIImage
#endif

Then I can implement methods, including public facing methods like:

public func monochromeImage(fromImage image: RSPlatformNativeImage) -> RSPlatformNativeImage { ... }

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:

public func monochromeImage(fromImage image: UIImage) -> UIImage { ... }

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:

- (NSImage * _Nonnull) monochromeImageFromImage:(NSImage * _Nonnull)image SWIFT_WARN_UNUSED_RESULT;

Thus for Objective-C clients the clutter of the typelias definition is tidied away, but for Swift clients, it must be dealt with.

@belkadan
Copy link
Contributor

belkadan commented May 8, 2018

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.

@swift-ci
Copy link
Collaborator Author

swift-ci commented May 8, 2018

Comment by Daniel Jalkut (JIRA)

Thanks for the link @belkadan. That is a bummer, but makes sense!

@Dante-Broggi
Copy link
Contributor

Dante-Broggi commented Sep 10, 2019

As a passing thought, should/does the compiler make `@inlinable internal typealias` work for this purpose?

@belkadan
Copy link
Contributor

belkadan commented Sep 10, 2019

*shrug* That's a little different than other inlinable things, which normally don't change the rules about how something is used, just optimized.

@belkadan
Copy link
Contributor

belkadan commented Oct 22, 2019

rdar://problem/21461090 is a similar issue. There's an old comment from me there that says:

Then again, if /you're/ working with a type that's so complex you need an alias, your clients might want it too.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants