> On Dec 21, 2017, at 12:42 PM, Paul Cantrell <cantr...@pobox.com> wrote: > > 1. Presumably the portions of A inlined into B and C remain sensitive to the > version-specific memory layout of A? Or will ABI stability mean that the > compiler can magically rearrange memory offsets in already-compiled code when > the layout changes? (Apologies if this is a too-obvious question; this part > of Swift is all a mystery to me.)
There is not really a notion of memory layout at the level of an entire module. For structs, classes and enums, you pretty much have the same concerns with both inlinable and non-inlinable functions — if the framework author can change the stored property layout of a struct or class (or adds a case to an enum), code that manipulates these data types must not make any compile-time assumptions that might be invalidated at runtime with a newer version of the framework. This is basically what the upcoming @fixedContents proposal for structs is about — giving framework authors a way to trade future flexibility for performance by allowing the compiler to make assumptions about the layout of a struct as it is written at compile-time. The @exhaustive proposal for enums has a similar implementation angle, but is of course more interesting because it affects the source language as well, with switch statements. We don’t plan on any kind of resilience opt-out for classes — already in shipping Swift compilers, accesses to stored properties of classes use accessor methods and not direct access across module boundaries. > 2. Is there some class of statically identifiable breaking changes that the > compiler does (or should) detect to flag incompatible inlined code? e.g. some > version of A inlined into B references A.foo, then A.foo is deleted in a > later version of A, so mixing older B with newer A in a project gives a > compile- or link-time error? This is what an “ABI differ” tool would achieve, but like I said it has not yet been designed. > 3. Does this need some sort of poison pill feature for other sorts of > breaking changes that are not statically detectable? e.g. invariants of a > data structure in A change in release 2.0, so the author of A says “it is an > error to include A ≥2.0 in any project that inlined any of my code from a > version <2.0.” Is this what you were getting at with the mention of > @inlinable(2.0) in the proposal? Sounded like that part was about something > else, but I didn’t really grasp it tbh. This is an interesting point and I think it is outside of the scope of these proposals. If the ABI of a library changes in an incompatible manner and previous binaries are no longer compatible with it, you should think of it as shipping a *new* library, either by changing it’s name or bumping the major version number, so that the dynamic linker prevents the client binary from being run in the first place. > Yes, frameworks+app built simultaneously are clearly the more common case. > Though Carthage seems to be champing at the bit to create this problem, since > it added a feature to download prebuilt binaries long before ABI stability! I > can easily imagining this feature spreading via word of mouth as a “secret go > faster switch,” and causing no end of problems in the wild. Perhaps, but I still think it is strictly better to formalize the feature through a proposal and document the pitfalls carefully — the underscored attribute is already spreading through word of mouth and in the absence of official documentation the potential for abuse is greater. > It might be safer — and better match the understanding of the typical user — > to have @inlinable assume by default that an inlined version of any given > method is only valid only for the specific version of the module it was > inlined from. The compiler would by default flag any version mixing as an > error, and require an explicit statement of compatibility intent for each > piece of inlinable code to opt in to the danger zone of mixed versions. How would this be implemented? Slava
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
