Perfect, thanks! On Tue, Aug 8, 2017 at 7:25 PM, Douglas Gregor <dgre...@apple.com> wrote:
> On Aug 8, 2017, at 10:44 AM, Mathew Huusko V via swift-evolution < > swift-evolution@swift.org> wrote: > > Sorry to revive this, but back on my ABI stability education: > > > [We’re a bit far afield of the original subject, but okay] > > > Swift 5 planning was announced today (woohoo!) with a primary target on > ABI stability. Finalising generics seems to be a major part of this, with > "conditional conformances", "recursive protocol requirements," and "there > are no known other generics enhancements needed for ABI stability" as key > points. > > But it seems like there's quite a bit more left in the generics manifesto > unimplemented. > > > Right. We’re not going to get to all of this in a year, or two years, and > we don’t get to block ABI stability on all of the features therein. > > Perhaps some of what's in there is controversial, but something like > generalised existentials afaik *is/was* planned.. can someone explain how > GE doesn't affect ABI stability? > > > It’s an additive feature, so it doesn’t *change* the ABI per se, it > extends the ABI to describe something it didn’t describe before. Now, there > are a few places where we could still run into ABI-compatibility issues > when adding something new: > > * Generalized existentials are a new structural type. An old runtime will > not understand the type metadata for these types, so we have to deal with > that in some way. Sometimes we can “implement ahead”, providing support for > a a feature in the runtime that isn’t surfaced in the language itself yet, > or we can try to build in future-proof mechanisms for adding more types. > > * Generalized existentials could change the way the standard library works > or is implemented. This is mostly opportunity cost: if we don’t have the > feature, we’ll have some suboptimal-in-retrospect APIs or implementation > that’s baked into the standard library. For generalized existentials, we’re > likely to have some suboptimality with struct AnyCollection, either in the > implementation (it could wrap a “Collection where .Element == Element”) or > even in the API itself (maybe the struct should go away and it should be a > typealias for the corresponding generalized existential). > > > To my very naive mind it's not that different from some other things said > to affect ABI, and to my slightly less naive mind, I believe it was going > to enable a protocol oriented approach to KeyPaths in the future, which > seems like it would affect ABI of stdlib. > > > Every ABI is suboptimal. Once you’ve shipped it, there are some hard > limits on what you can change (because all of the existing binaries need to > continue to work), but it’s still possible to make improvements. At worst, > the improvements only be available on some future OS. Sometimes, one can do > better by putting more work into the implementation to interoperate with > other binaries, and often language runtime designers leave themselves hooks > that allow such improvements in the future. We’ll do some of this in the > Swift ABI, particularly where we expect change. Engineering trade-offs > abound, and for generics, we feel like we can tackle what’s been proposed > already… but not more… and that we can live with the limitations posed by > that model. > > I'm quite sure I'm missing the core concept at this point, so I'd be > content with my examples being ignored and just pointing me towards a > general/educational resource on ABI vs. interface thats vaguely compatible > with Swift. > > > The ABI Dashboard (https://swift.org/abi-stability/) and ABI Manifesto ( > https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md) > cover some of this. > > - Doug > > > Thanks! > > On Tue, Aug 8, 2017 at 6:18 PM, Chris Lattner <clatt...@nondot.org> wrote: > >> >> > On Aug 7, 2017, at 11:34 PM, Elviro Rocca < >> retired.hunter.dj...@gmail.com> wrote: >> > >> > I agree with everything you wrote, in particular I agree with the idea >> that it is more important to get the big efforts right, and that they >> should take priority. But I would consider a distinction: >> > >> > - big efforts that add huge new features to the language so that things >> that were done in userland with libraries can be done natively and >> idiomatically (concurrent programming, for example); >> > - more "theoretical" big efforts, that allow one, while building a >> single app or a big library, to "express" more things more precisely in the >> language, and improvements to the generics and protocols systems fall in >> this second realm; >> > >> > The reason why I consider the second kind of feature as more important >> than the first (thus, earning higher priority) is that, apart from reducing >> the amount of busywork to be done in many cases where the abstraction power >> is not good enough, it gives more tools for the community to build upon, it >> allows many people to do more with the language than probably me, you and >> the core team have ever though of, it fosters the explosion of creativity >> that's only possible when a language is expressive enough and it's not only >> based on certain conventions (that, by definition, constraint the way a >> language is commonly used). >> >> MHO is that both are important. I think the details of the tradeoffs >> involved prioritizing the individual members of those categories are bigger >> than the difference between the two categories. I don’t think this is a >> useful way to try to slice the problem up. >> >> -Chris >> >> _______________________________________________ > 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