[swift-evolution] Pitch: Cross-module inlining and specialization

[Chris Lattner]

> On Oct 2, 2017, at 11:27 PM, Slava Pestov <spestov at apple.com> wrote:
> 
> 
>> On Oct 2, 2017, at 10:57 PM, Chris Lattner <clattner at nondot.org <mailto:clattner at nondot.org>> wrote:
>> 
>> 1) Why not another level of access control?  There is a reasonable argument that what you’re doing is making something “more public than public” or that you’re making the “body also public”.  I’m not strongly in favor of this design approach, but if you agree, the doc should explain why you’re not in favor of it.
> 
> Oh, I forgot to address this point. I’m against this because even though this proposal says inlinable requires public, it is really orthogonal to public, because eventually we will have something like the current @_versioned attribute, where internal (or even private, as some have suggested) functions can be “public ABI”. For example,

I’m also against it, because it should theoretically be orthogonal to open/public.  While we could define “fragile” as being “more permissive than open and public”, that is weird and access control is already too complicated.  :-)

-Chris


> 
> @_versioned func myInternalDetails() {
>   // …
> }
> 
> @inlinable
> public func myPublicFunction() {
>   myInternalDetails() // I can reference this from an inlinable function, but users can’t call it directly
> }
> 
> Slava

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171003/51e6090a/attachment.html>