SE-0193 - Cross-module inlining and specialization

taylorswift · December 21, 2017, 4:52am

glad to see this finally moving forward!

The review of "SE-0193 - Cross-module inlining and specialization" begins
now and runs through *January 5, 2018*.

The proposal is available here:

GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
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: GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
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

···

On Wed, Dec 20, 2017 at 6:19 PM, Ted Kremenek via swift-evolution < swift-evolution@swift.org> wrote:

-

Thanks,
Ted Kremenek
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution