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

Leverage Swift 5.1 module stability #64

Closed
fredpi opened this issue Jul 1, 2019 · 4 comments
Closed

Leverage Swift 5.1 module stability #64

fredpi opened this issue Jul 1, 2019 · 4 comments
Labels
enhancement New feature or request

Comments

@fredpi
Copy link
Contributor

fredpi commented Jul 1, 2019

An idea originating from #62, if the Swift version, let it be v, is greater than 5.1 (the Swift version where module stability is introduced), the cache should also be looked up for versions built with a version w, v ≥ w ≥ 5.1. If a cached build product with version w is found, then it can be used, even with Swift version v.

@fredpi fredpi added the enhancement New feature or request label Jul 1, 2019
@Jeehut
Copy link
Contributor

Jeehut commented Jul 2, 2019

I haven't tested that, but given this actually works with dynamic frameworks I think we could support this feature with an option at first. My reasoning is that although ABI stability is a given now, we still don't know how things go in practical terms and especially given that some frameworks might opt for adding some new features only for newer Swift versions, we might miss out on supporting the latest technology if we make this the default behavior.

Not sure if I explained it well, so here's an example: Let's a framework – let's name it X – introduces a new syntax or new API in version 2.0 only for Swift 6.0 users and has a fallback for Swift 5.1 users which is less concise but still works, and let's say that someone is still running on Swift 5.1 although Swift 6.0 is released, then this user will build that framework with Swift 5.1 and cache the results. Then, when she updates to Swift 6.0 sometime later, she will still get the Swift 5.1 API since it was built with Swift 5.1 – at least that's how I understand it (haven't tested though). This way defaulting to always using compatible cached versions might make users miss out on new features and get confused, why they are not available. Also, optimizations on Swift performance might not automatically be apparent on those cached products.

Also, given that new Swift versions do not appear so often, I think we can comprise having to build dependencies twice a year or so. By the way, I don't think we should in any way optimize for using Beta versions at all. Having this all said, I'm not against adding this as an option for those, who need this.

@fredpi
Copy link
Contributor Author

fredpi commented Jul 2, 2019

@Dschee Not enabling this by default totally makes sense to me, but I'm uncertain whether anyone would actually use a flag with the install / update command that manually enables such a behaviour... Therefore, this is probably not worth implementing at all, is it?

@Jeehut
Copy link
Contributor

Jeehut commented Jul 2, 2019

I think given Apple was quicker than expected with integrating SwiftPM into Xcode renders many features "not worth implementing", including this. We shall have to play around a little more with the given inclusion into Xcode and from that drive a new direction for Accio to go. I feel like there's still space for Accio here to provide a bridge between now and the time all frameworks properly support inclusion into Xcode via SwiftPM. They are still missing resources support, for example ...

@fredpi
Copy link
Contributor Author

fredpi commented Jan 21, 2020

Closing this as not worth implementing (see discussion above)

@fredpi fredpi closed this as completed Jan 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants