> On Oct 3, 2017, at 11:05 PM, Jonas B <bobe...@gmail.com> wrote: > > >> On 4 Oct 2017, at 14:33, Slava Pestov <spes...@apple.com >> <mailto: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
The two attributes are different though. myImplDetail() is _not_ inlined into client code here, but myPublicFunction() is. So they need different attributes to express this intent. > > 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. Yes, that would be a nice feature to have but it is outside the scope of this proposal. First, we want to tackle shipping resilient modules — then we can discuss generalizing the notion of a “resilience domain” to encompass multiple modules. I realize the latter is more useful to third party developers though, and I apologize that in this particular case our priorities are at odds… > > 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>. I agree — even for members of the compiler team this tool would be very useful, both as a way of encoding our assumptions for sanity-checking, and making sure we don’t make a silly mistake with a future update to the standard library. Slava > > /Jonas >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
