On Wed, Dec 20, 2017 at 4: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? > > +1. I've worked on a performance-sensitive codebase (Swift protocol buffers) where being able to optimize across module boundaries (using documented features!) would be a huge win. > - > - > > Is the problem being addressed significant enough to warrant a change > to Swift? > > Yes. > > - > - > > Does this proposal fit well with the feel and direction of Swift? > > Yes, aside from the inevitable name bikeshedding. :) I share Xiaodi's view that "@abiPublic" feels like it's coöpting "public" in an odd way, especially when that attribute specifically only applies to internal decls. I could get behind "@abi", but that doesn't quite feel like "enough". "@abiVisible" comes to mind as a possibility—the declaration isn't "public", but it's "visible" in the ABI. A related question (with some background): My assumption is that conditional compilation directives (e.g., #if DEBUG) are resolved *before* an @inlinable function is serialized to the module. Is that correct? In other words, if I have this: ----- // Logger @inlinable func log(_ msg: String) { #if DEBUG print(msg) #endif } // Client import Logger log("hello") ----- Then when Logger is compiled, the call to print() is *not serialized at all* if DEBUG is undefined, right? (As opposed to serializing the conditional and the body and then using the value of DEBUG in *Client's* compilation to decide whether the code is present when inlined.) The reason I ask is because I've been looking at how to tackle logging in Swift—specifically the ability to have debug logging statements completely stripped (including the strings passed to them) in release binaries. This can be achieved today if the logging function is in the same module as the caller and you do an optimized build (and you trust the optimizer to do this reliably); the entire function call and its strings are dropped. But if Logger is a separate module, this is no longer possible. @inlinable is one of the ways that I thought this problem could be resolved, but only if the conditionals are also serialized and reapplied against the client's -D flags, and only if the attribute is a *guarantee* from the compiler and not just a *suggestion* to it. My hunch is that this is out of scope for this particular proposal (and would be a "side effect" at best rather than a "feature" even if it did work), but I'd love to hear your thoughts on that! > - > - > > If you have used other languages or libraries with a similar feature, > how do you feel that this proposal compares to those? > > Just C++, as described in the proposal. It's unfortunate that C++'s separate header/source structure makes this more elegant in a sense than the Swift solution using attributes, by virtue of just deciding where you place the code. That being said, I can't think of a more elegant approach. > > - > - > > How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? > > Followed earlier discussions and read the proposal. > > - > > 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
