The feedback from the first review was positive, and the proposal has been amended to address the feedback provided by the community and the core team. It is now ready for a second review.
Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager or direct message in the Swift forums).
What goes into a review of a proposal?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift.
When reviewing a proposal, here are some questions to consider:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Thank you for helping improve the Swift programming language and ecosystem.
This seems like a reasonable design, thanks folks. My only suggestions are editorial nits: it might be better to replace the -linux- stanza in the hypothetical linux architecture triple with linux-gnu, which is the common way to indicate that you mean "Linux with glibc".
I’m pleased with how this revision has turned out. I think this is a nice improvement that solves a significant use case for Swift packages. I reviewed the previous version and carefully read through the diff for this revision.