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

[Kelvin Ma]

that’s why i keep saying we should separate human-facing encapsulation
concepts from compiler-facing abi visibility concepts. i’ve always been
advocating for something like

internal(visible)
fileprivate(visible)
private(visible)

in the same spelling we currently use for stuff like private(set). we might
have to disallow it for fileprivate because of the name mangling issue that
Slava mentioned but it’s an elegant spelling and extensible if someone
comes up with a good unique mangling scheme for private declarations.

On Fri, Dec 29, 2017 at 10:35 AM, Félix Cloutier via swift-evolution <
swift-evolution at swift.org> wrote:

> I agree with the common theme that `@abiPublic` is weird. I imagine that
> not a lot of `@abiPublic` symbols actually want to be internal: they'll
> almost all be implementation details that really want to be `private` or
> `fileprivate` but that have to be `internal` to satisfy what (I believe)
> most people would consider to be a leaky abstraction provided by the Swift
> language. So why not go all the way and force @inlinable code to only
> reference public declarations?
>
> What do we get in exchange of subverting the thus-far clear meaning of
> `internal`? Why is it better to have a special kind of internal that is not
> internal, instead of a special kind of public that is not listed, or even
> just no special kind of public?
>
> That detail aside, having the ability to do cross-module inlining and
> specializing is valuable and exciting.
>
> Félix
>
> Le 20 déc. 2017 à 19:19, Ted Kremenek via swift-evolution <
> swift-evolution at swift.org> a écrit :
>
> 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?
>    -
>
>    Is the problem being addressed significant enough to warrant a change
>    to Swift?
>    -
>
>    Does this proposal fit well with the feel and direction of Swift?
>    -
>
>    If you have used other languages or libraries with a similar feature,
>    how do you feel that this proposal compares to those?
>    -
>
>    How much effort did you put into your review? A glance, a quick
>    reading, or an in-depth study?
>
> Thanks,
> Ted Kremenek
> Review Manager
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> 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/20171229/78825fdc/attachment.html>