[swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

[Tony Allevato]

On Wed, Dec 20, 2017 at 4:19 PM Ted Kremenek via swift-evolution <
swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171221/7bfd286d/attachment.html>