Re: [swift-evolution] Pitch: Cross-module inlining and specialization
> On 4 Oct 2017, at 14:33, Slava Pestov 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
.
/Jonas
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Pitch: Cross-module inlining and specialization
> On 4 Oct 2017, at 13:36, Slava Pestov wrote: > >> On Oct 3, 2017, at 9:14 PM, Jonas B via swift-evolution >> 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? ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Pitch: Cross-module inlining and specialization
> > Yeah, but the compiler could handle NSObject as a special case. Are there > enough other special cases that it is worth documenting and exposing a > fragile attribute on classes to the user? > Pitching in here.. currently if you do something remotely complex with protocols and generics you need a bunch of classes for type erasure. I don’t want to think about what happens if you annotate a class with the "open” access modifier as @fragile/@inlineable though. Would @fragile become transitive? :)___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Pitch: Cross-module inlining and specialization
I find the following points in the proposal interesting: > Within the scope of a single module, the Swift compiler performs very > aggressive optimization, including full and partial specialization of generic > functions, inlining, and various forms of interprocedural analysis. > On the other hand, across module boundaries, runtime generics introduce > unavoidable overhead ... > The attribute can only be applied to public declarations. This is because the > attribute only has an effect when the declaration is used from outside of the > module. If your company name is not Apple, looking at how your code base using Swift is typically going to be deployed - it’s very often going to end up in a iOS or macOS app bundle. Those bundles are deployed as one unit. Now, in our code base (I suspect similar to many other users of swift), we have various frameworks that are not frameworks for the purpose of providing a stable ABI but rather: * A reusable unit with a somewhat stable API, that can be shared between apps and with the wider open source community * A mechanism for namespacing 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. 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. Jonas ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
