> On Oct 3, 2017, at 10:32 PM, Jonas B <bobe...@gmail.com> wrote:
>
>
>> On 4 Oct 2017, at 13:36, Slava Pestov <spes...@apple.com
>> <mailto:spes...@apple.com>> wrote:
>>
>>> On Oct 3, 2017, at 9:14 PM, Jonas B via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>
>>>
>>> Now I understand that this use-case is deferred for a later separate
>>> discussion, but my point here is that the name and the semantics of this
>>> attribute should be somewhat “forward-compatilble” with this use-case. “
>>> inlinable” does not sound appropriate, because we don’t want to “inline”
>>> (in the C/C++ meaning) declarations into each usage site.
>>> Instead we want to compile the annotated parts of -all linked modules- as
>>> one unit. Basically, for those parts, the module name would just function
>>> like a C++ namespace - an input to the symbol name mangling, and then the
>>> whole thing could be whole-module-optimized together.
>>
>> Yeah, @inlinable does not actually force any kind of inlining to be
>> performed — it declared that the SIL for the function body should be
>> serialized as part of the module.
>>
>>>
>>> This touches upon another comment someone made previously in this
>>> discussion - that access level and compiler visibility should be separate
>>> concepts. Because not just public methods, also private methods should be
>>> subject to this.
>>
>> The undocumented @_versioned attribute is currently used to make something
>> visible to the compiler without making it visible in the language. It sounds
>> like there’s some interest in documenting this attribute too — can someone
>> suggest a better name than @_versioned? If we converge on a design here I
>> can incorporate that into the proposal, relaxing the restriction that
>> @inlinable functions can only reference other public functions.
>>
>> Slava
>
>
> It’s not totally clear to me what @_versioned is supposed to do. Well, it’s
> kind of clear that if something less-than-public in module A is declared
> @_versioned then it’s visible to the compiler when compiling module B (which
> imports module A). But does @_versioned imply @inlineable? If not, what’s the
> use case for declaring something @_versioned but not @inlineable? Giving some
> more information to the optimiser without introducing ABI fragility? Why not
> always do that then?
>
@_versioned makes a symbol visible externally without making it visible from
the language. There is no requirement that a @_versioned thing is @inlinable.
It is used when you want to reference an internal function from an inlinable
function. Eg,
internal func myImplDetail() { … }
@inlinable public func myPublicFunction() { myImplDetail() } // error!
—
@_versioned internal func myImplDetail() { … }
@inlinable public func myPublicFunction() { myImplDetail() } // OK
Slava_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
