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

Request: Swift Package Manager support #1

Open
amomchilov opened this issue Jan 4, 2017 · 8 comments
Open

Request: Swift Package Manager support #1

amomchilov opened this issue Jan 4, 2017 · 8 comments

Comments

@amomchilov
Copy link

Would you be interested in making this repo compatible with the Swift Package Manager?

I don't mind doing it and making a PR, if there's interest.

@CodaFi
Copy link
Member

CodaFi commented Jan 4, 2017

Sure! I'm not sure what the look and feel of these APIs is when they're imported in Swift, but if you're up to it I'd certainly appreciate the contribution.

@avaidyam
Copy link

avaidyam commented Oct 9, 2017

@CodaFi You'll need to mark things with __Nullable and __Nonnull for starters, and I believe you can create a package overlay via NS_SWIFT_NAME pretty easily to transform it into a struct or class-like interface.

@CodaFi
Copy link
Member

CodaFi commented Oct 10, 2017

Determining nullability for this API surface is going to be a painful slog, I can feel it...

@avaidyam
Copy link

@CodaFi Yeah, not to mention you can't produce correct Swift throws overlays because of the return type. I don't know how to correct that one unfortunately.


Also, I remember you from the TwUI days... hello again! 👋

@CodaFi
Copy link
Member

CodaFi commented Oct 10, 2017

None of these functions should ever throw a catchable exception. Not only would it have violated an invariant across a MIG’ed interface, it would be bubbling up from across at least one framework boundary.

I think we’re going to need APINotes here too. NS_SWIFT_NAME is only fine in the small.

@avaidyam
Copy link

Well, I would see it as the CGError being returned would instead be caught or ignored by a try? or so. And your suggestion of APINotes is probably more correct - I was thinking of just wrapping the functions in an ObjC class and letting Swift auto-import that but it causes some unwanted (and un-needed) overhead.

@CodaFi
Copy link
Member

CodaFi commented Oct 10, 2017

The few CGError-returning public APIs I can find don't import as throwing. Do you have an example of what you had in mind?

@avaidyam
Copy link

Right - I was suggesting having them import as throwing instead. i.e. CGError CGSDoSomething(...) would import as func CGSDoSomething(...) throws.

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

No branches or pull requests

3 participants