This is an excellent explanation! I think I (mostly) understand. Thanks, Jon
> On Aug 11, 2016, at 9:16 AM, John McCall <rjmcc...@apple.com> wrote: > >> On Aug 11, 2016, at 1:52 AM, Jonathan Hull via swift-evolution >> <swift-evolution@swift.org> wrote: >> Could someone explain in simple terms what the ABI is and what sorts of >> things might affect it? > > The ABI for a compiled programming language is the set of rules for how all > of its interoperating features are implemented in the compiled result. > > For example, in Java the primary ABI is the JVM specification plus some > common-sense rules about how language features are mapped to JVM features. > JVMs do not typically interoperate with other code at a direct binary level, > and so the details of actual memory layout are not ABI. > > Not all language features require interoperation, or only require it a > certain kind of opaque interoperation. For example: > > - Type aliases do not currently have any ABI impact because by design they > are erased at compile time. However, a complete reflection design might > provide some mechanism for introspecting type-aliases at runtime, which would > require information about type aliases to be present in the compiled output; > the representation of that information would be ABI. > > - Closures in most programming languages do not allow external code to > modify their captured values; only the closure's invocation function can > access them, and that is generated together with the capturing code, so the > exact methodology of performing a capture is not ABI. However, arbitrary > code can invoke the closure, and so the opaque representation of a closure > value and the process for invoking it are ABI. > > And so on. > > John. > >> I had thought it was the layout in memory of structs/classes/etc… and how >> the program knows where to go to find a particular field. This seems to be >> incorrect though, as I have seen many features that I would assume have some >> affect on this layout ruled “out of scope for phase 1”. For example, I >> would think that many generics features would have an impact on the ABI, or >> the idea of COW (via secret boxing) for structs, or even union types. >> >> At the very least, I would think that mix-ins would have a fairly >> significant effect. >> >> I am obviously missing something here, and I want to provide constructive >> effort to the community (as opposed to distracting from the task at hand), >> so I would appreciate some clarification/guidance... >> >> Thanks, >> Jon >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
