4 ms·

Compiling Swift Generics [pdf]

93 points by matt_d 4y ago

eyelidlessness 4y ago
I can’t read all of this now, mainly because I’m on mobile with limited time and it’s hard to squint at. But I was surprised that what I did read and search through the document makes only one mention of polymorphism (rank 2 polymorphism, which was a new term to me; a quick search seems to suggest this is the type system equivalent of closing over a type parameter, eg to create local generic function whose generic constraints are first constrained by their outer scope). And makes no direct mention of monomorphization in the code specialization section, but it does seem to hint in that direction. I’m probably looking for terminology but would be satisfied with the prose when I read through more. What surprised me most so far, again having only read a portion so far, is the caveats around crossing module boundaries for analysis. I’ve been, frankly, surprised at how much this is expressed as a difficulty in far more dynamic environments like JS ESM, but where the module boundaries not always totally static but in practice almost always are. I’d expect that a much more static and controlled environment like Swift would not have so many challenges in that area. But maybe this is a misconception of how static Swift actually is? Probably so! Adding this comment with more ignorance than insight mostly in hopes I come back to see more knowledgeable discussion when I return.
- kibwen 4y ago
  Haven't read the PDF but apparently it's only part one of three, so that may be covered by future installments.
- favorited 4y ago
  Swift's generics have some unique properties at module boundaries to allow for a stable ABI while enabling library evolution. To get additional background, you might be interested in this[0] conference talk (the paper's author is one of the co-presenters). Also, this post[1] by a Rust and Swift compiler engineer talks about what Swift does differently than other languages, and the tradeoffs that are involved. [0]https://www.youtube.com/watch?v=ctS8FzqcRug https://www.youtube.com/watch?v=ctS8FzqcRug [1]https://faultlore.com/blah/swift-abi/ https://faultlore.com/blah/swift-abi/
- slavapestov 4y ago
  The whole thing is about polymorphism, but Swift calls that generics. Similarly “function specialization” is Swift lingo for monomorphization. The part about module boundaries is what allows separately-compiled and updated shared libraries to work (like the frameworks in the OS). There’s an @inlinable attribute to publish a function’s body to clients, but then if you update the library it won’t be picked up until clients are recompiled (which might be fine, for example a lot of standard library collection algorithms and so on are inlinable).
msie 4y ago
Sadly, Swift will remain a niche language, much like Objective-C was.
- ChrisMarshallNY 4y ago
  But it’s a pretty important “niche” (just like ObjC). It may be the only “niche” language that bubbles to the higher levels of preference polls. One reason that Apple is an attractive target platform, is because it’s fairly lucrative.
- keyle 4y ago
  At some point I might have somewhat agreed with you but not so much lately. I've been using a lot of swift lately and it's one of the most expressive (and impressive) language of late. I've been blown away by its terseness which leads to incredible functionality (SwiftUI is basically a DSL[1]) and robustness of the type system. When it compiles, it will most likely not crash, unless I specifically said "doing!yolo-dumb!stuff!here". I'll come out and say it, Swift might be the most advanced high-level language in terms of power vs. UX. I'll also say that its compile messages, half the time, are like academia vomit thrown at the face of the developer -> that needs to improve. [1] (which agreeably leaks a bit)
  - msie 4y ago
    I am worried about its terseness and readability.
    - keyle 4y ago
      Also agree. That's what I meant about the leaky abstraction. The fact that some chainable things are a one way street... e.g. need a specific order... yikes. But considering the DSL is fully statically typed, wow. So it's a bit of give and take on that one.
      - msie 4y ago
        Out of many sources, it was only the Stanford iphone course that demystified the terseness of the Swiftui dsl. The lecturer pointed out all the optional parentheses and optional arguments that could be omitted to make the declarations clean. Up until then i thought i was looking at weird structs. This is one problem i have with swift’s terseness.
slavapestov 4y ago
Forum post with some context: https://forums.swift.org/t/compiling-swift-generics-part-i/60898 https://forums.swift.org/t/compiling-swift-generics-part-i/6...
ridiculous_fish 4y ago
Hey Slava, this looks to be an incredible resource and I very much look forward to reading it. A question I have: is there any hope to specialize generics exported by shared libraries? Perhaps with help from bitcode or dyld? As you know so many of Apple's frameworks are packaged as shared libraries, and enabling them to export generic definitions which operate on concrete representations would be killer.
- slavapestov 4y ago
  I can't comment on Apple frameworks but there's a @_specialize attribute which allows you to export a fixed set of pre-specialized entry points from your own frameworks, without exposing the entire function body as serialized SIL the way that @inlinable does, but it's still experimental and subject to breakage and change: https://github.com/apple/swift/blob/main/docs/Generics.rst#specialization https://github.com/apple/swift/blob/main/docs/Generics.rst#s...
gilgoomesh 4y ago
There's a whole space in the document to thunk people and... nothing. Prima donna.

93 points by matt_d 4y ago

I can’t read all of this now, mainly because I’m on mobile with limited time and it’s hard to squint at. But I was surprised that what I did read and search through the document makes only one mention of polymorphism (rank 2 polymorphism, which was a new term to me; a quick search seems to suggest this is the type system equivalent of closing over a type parameter, eg to create local generic function whose generic constraints are first constrained by their outer scope). And makes no direct mention of monomorphization in the code specialization section, but it does seem to hint in that direction. I’m probably looking for terminology but would be satisfied with the prose when I read through more. What surprised me most so far, again having only read a portion so far, is the caveats around crossing module boundaries for analysis. I’ve been, frankly, surprised at how much this is expressed as a difficulty in far more dynamic environments like JS ESM, but where the module boundaries not always totally static but in practice almost always are. I’d expect that a much more static and controlled environment like Swift would not have so many challenges in that area. But maybe this is a misconception of how static Swift actually is? Probably so! Adding this comment with more ignorance than insight mostly in hopes I come back to see more knowledgeable discussion when I return.

kibwen 4y ago
Haven't read the PDF but apparently it's only part one of three, so that may be covered by future installments.
favorited 4y ago
Swift's generics have some unique properties at module boundaries to allow for a stable ABI while enabling library evolution. To get additional background, you might be interested in this[0] conference talk (the paper's author is one of the co-presenters). Also, this post[1] by a Rust and Swift compiler engineer talks about what Swift does differently than other languages, and the tradeoffs that are involved. [0]https://www.youtube.com/watch?v=ctS8FzqcRug https://www.youtube.com/watch?v=ctS8FzqcRug [1]https://faultlore.com/blah/swift-abi/ https://faultlore.com/blah/swift-abi/
slavapestov 4y ago
The whole thing is about polymorphism, but Swift calls that generics. Similarly “function specialization” is Swift lingo for monomorphization. The part about module boundaries is what allows separately-compiled and updated shared libraries to work (like the frameworks in the OS). There’s an @inlinable attribute to publish a function’s body to clients, but then if you update the library it won’t be picked up until clients are recompiled (which might be fine, for example a lot of standard library collection algorithms and so on are inlinable).

msie 4y ago

Sadly, Swift will remain a niche language, much like Objective-C was.

ChrisMarshallNY 4y ago
But it’s a pretty important “niche” (just like ObjC). It may be the only “niche” language that bubbles to the higher levels of preference polls. One reason that Apple is an attractive target platform, is because it’s fairly lucrative.
keyle 4y ago
At some point I might have somewhat agreed with you but not so much lately. I've been using a lot of swift lately and it's one of the most expressive (and impressive) language of late. I've been blown away by its terseness which leads to incredible functionality (SwiftUI is basically a DSL[1]) and robustness of the type system. When it compiles, it will most likely not crash, unless I specifically said "doing!yolo-dumb!stuff!here". I'll come out and say it, Swift might be the most advanced high-level language in terms of power vs. UX. I'll also say that its compile messages, half the time, are like academia vomit thrown at the face of the developer -> that needs to improve. [1] (which agreeably leaks a bit)
- msie 4y ago
  I am worried about its terseness and readability.
  - keyle 4y ago
    Also agree. That's what I meant about the leaky abstraction. The fact that some chainable things are a one way street... e.g. need a specific order... yikes. But considering the DSL is fully statically typed, wow. So it's a bit of give and take on that one.
    - msie 4y ago
      Out of many sources, it was only the Stanford iphone course that demystified the terseness of the Swiftui dsl. The lecturer pointed out all the optional parentheses and optional arguments that could be omitted to make the declarations clean. Up until then i thought i was looking at weird structs. This is one problem i have with swift’s terseness.

slavapestov 4y ago

Forum post with some context: https://forums.swift.org/t/compiling-swift-generics-part-i/60898 https://forums.swift.org/t/compiling-swift-generics-part-i/6...

ridiculous_fish 4y ago

Hey Slava, this looks to be an incredible resource and I very much look forward to reading it. A question I have: is there any hope to specialize generics exported by shared libraries? Perhaps with help from bitcode or dyld? As you know so many of Apple's frameworks are packaged as shared libraries, and enabling them to export generic definitions which operate on concrete representations would be killer.

slavapestov 4y ago
I can't comment on Apple frameworks but there's a @_specialize attribute which allows you to export a fixed set of pre-specialized entry points from your own frameworks, without exposing the entire function body as serialized SIL the way that @inlinable does, but it's still experimental and subject to breakage and change: https://github.com/apple/swift/blob/main/docs/Generics.rst#specialization https://github.com/apple/swift/blob/main/docs/Generics.rst#s...

gilgoomesh 4y ago

There's a whole space in the document to thunk people and... nothing. Prima donna.