Skip to content

[docs] CToSwift: CF types, protocols, and swift_private #27118

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

Conversation

jrose-apple
Copy link
Contributor

Basically, all the remaining easy cases. See #26947 for what else belongs in this document.


_The original intent of the `swift_private` attribute was additionally to limit access to a Swift module with the same name as the owning Clang module, e.g. the Swift half of a mixed-source framework. However, this restriction has not been implemented as of Swift 5.1._

_For "historical reasons", the `swift_private` attribute is ignored on factory initializers with no arguments._
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I traced this back to 91d1c3b, and it looks like there's no motivation for this; it was just "we forgot to implement it in the factory-method-to-initializer transformation and then didn't want to break anyone who wrote swift_private on a factory method and saw no effect". The code lives in ImportName.cpp today; that's where I got the "historical reasons" phrasing from.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your phrasing uses "factory initializers", is it the same as "factory methods"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mm, not quite, because only some factory methods are imported as initializers. And that section hasn't been written yet. I can expand it out to "factory methods with no arguments that are imported as initializers", though.

Copy link
Contributor

@xymus xymus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This document is very enlightening!


_The original intent of the `swift_private` attribute was additionally to limit access to a Swift module with the same name as the owning Clang module, e.g. the Swift half of a mixed-source framework. However, this restriction has not been implemented as of Swift 5.1._

_For "historical reasons", the `swift_private` attribute is ignored on factory initializers with no arguments._
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your phrasing uses "factory initializers", is it the same as "factory methods"?

@jrose-apple jrose-apple force-pushed the translation-reflection-but-what-about-rotation branch from e5bb756 to 2d63ae4 Compare September 12, 2019 02:45
@jrose-apple
Copy link
Contributor Author

@swift-ci Please smoke test

@jrose-apple
Copy link
Contributor Author

@swift-ci Please smoke test macOS

@jrose-apple jrose-apple merged commit ec862c5 into swiftlang:master Sep 12, 2019
@jrose-apple jrose-apple deleted the translation-reflection-but-what-about-rotation branch September 12, 2019 17:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants