> 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/ 
<https://swift.org/abi-stability/>) and ABI Manifesto 
(https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md 
<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 
> <mailto:clatt...@nondot.org>> wrote:
> 
> > On Aug 7, 2017, at 11:34 PM, Elviro Rocca <retired.hunter.dj...@gmail.com 
> > <mailto: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

Reply via email to