> On 4 Oct 2017, at 14:33, Slava Pestov <spes...@apple.com> wrote:
>
> @_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
>From my language user point of view it would be more understandable if that
>was written with a single keyword, eg:
@nonABI internal func myImplDetail() { }
@nonABI public func myPublicFunction() { myImplDetail() } // OK
Anyway, for my use case mentioned earlier (shipping a release version of my app
bundle), that doesn’t really matter. I’d just like a compiler switch that made
the whole module not having an ABI, essentially making all all methods and
types @inlinable and @_versioned, using the terminology in your example.
My other observation is that no matter how great the ergonomics, and no matter
the naming of these attributes, very few people outside the compiler team is
going to be able to successfully ship a versioned library without the “Checking
Binary Compatibility” tool mentioned in
https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#checking-binary-compatibility
<https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#checking-binary-compatibility>.
/Jonas
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
