> On Oct 5, 2017, at 9:32 AM, Joe Groff <jgr...@apple.com> wrote: > >>> >>> The suggestion to have this semantics was originally my fault, I believe, >>> and it arose from the observation that if we have 'inlinable' backed by a >>> symbol in the binary, then we'd also want the 'must be emitted by client' >>> attribute. I think 'must be emitted by client' is going to almost always be >>> preferable for an inlinable function, though, so it's better to have the >>> single attribute with this behavior, only constrained by backward >>> deployment. >> >> What is the use case of “must be emitted by client” attribute? If I imagine >> that the Swift 5 standard library is shipped in the OS, I can see cases >> where deprecated/legacy shims for Swift3/4 compatibility would be emitted >> into the client but not shipped in the OS. Those seem relatively obscure >> though. > > You could just as easily pose the opposite question—what's the use case for a > symbol in the dylib when the definition is visible to clients? Evaluating the > tradeoffs, we feel like it's better not to unless backward compatibility > demands it.
The behavior I’m proposing dovetails with the overall design of swift resilience progressive disclosure: 1) You can be fast and loose with a symbol, so long as you don’t define it as public. 2) Making it public allows you to be fast and loose within your module, but you have to opt into guarantees for other modules. 3) You can ship your symbol as public, then grant additional guarantees (overridability/subclassability or inlinability) in a subsequent release after you gain experience with it. I think it is hugely problematic that transitioning from “public” to “inlinable public” would be an ABI break with your approach. I would much rather see a model where “public” can graduate to “inlinable public” in an ABI compatible way, but that there were a “alwaysinlined public” concept (with a sufficiently scary name) for power users that want the semantics that you’re arguing for. -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
