glad to see this finally moving forward! On Wed, Dec 20, 2017 at 6:19 PM, Ted Kremenek via swift-evolution < swift-evolution@swift.org> wrote:
> The review of "SE-0193 - Cross-module inlining and specialization" begins > now and runs through *January 5, 2018*. > > The proposal is available here: > > https://github.com/apple/swift-evolution/blob/master/ > proposals/0193-cross-module-inlining-and-specialization.md > > Reviews are an important part of the Swift evolution process. All review > feedback should be sent to the swift-evolution mailing list at: > > https://lists.swift.org/mailman/listinfo/swift-evolution > > or, if you would like to keep your feedback private, directly to the > review manager. > > When replying, please try to keep the proposal link at the top of the > message: > > Proposal link: https://github.com/apple/swift-evolution/blob/master/ > proposals/0193-cross-module-inlining-and-specialization.md > ... > Reply text > ... > Other replies > > 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? > > this is a feature i have been waiting for for a long time so needless to say i strongly support this proposal. one comment is that @abiPublic is a kind of awkward thing to have around, not because of how it’s spelled but because i think access control and abi visibility are orthogonal concepts and i’m not a fan of overloading access control terms for abi concepts. it makes sense to have @abiPublic on private and fileprivate declarations too and i hope this gets added, because private and fileprivate are tools for code organization and maintenance,, the compiler with wmo doesn’t care about private vs internal. but @abiPublic private is bound to cause confusion and it just reads funny. > > - > - > > Is the problem being addressed significant enough to warrant a change > to Swift? > > Yes. this issue (along with generic specialization which is really rendered mostly irrelevant by inlining) is the main technical barrier preventing a swift core library ecosystem from taking root. formalizing this feature will allow library authors like me to ship and use modules for low level tasks, whereas previously the workaround was to copy and paste handy .swift files <https://github.com/kelvin13/swiftlets> containing implementations of common data structures and algorithms. ultimately this will help maintainability, code reuse, and general code base cleanliness. > > - > - > > Does this proposal fit well with the feel and direction of Swift? > > i don’t see why it wouldn’t. the proposal seems overly conservative and leans a bit too far towards maximum resilience vs maximum optimization but that’s fine. > > - > - > > If you have used other languages or libraries with a similar feature, > how do you feel that this proposal compares to those? > > this is a big step up from the c++ thing where you would just distribute giant “header-only” libraries so > > - > - > > How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? > > i read the whole thing,, and i’ve been following this discussion for a while > > - > > Thanks, > Ted Kremenek > Review Manager > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution