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

[Kelvin Ma]

glad to see this finally moving forward!

On Wed, Dec 20, 2017 at 6: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?
>
> 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 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/20171220/9277b601/attachment.html>