[swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

[Mathew Huusko V]

Perfect, thanks!

On Tue, Aug 8, 2017 at 7:25 PM, Douglas Gregor <dgregor at apple.com> wrote:

> On Aug 8, 2017, at 10:44 AM, Mathew Huusko V via swift-evolution <
> swift-evolution at 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 <clattner at nondot.org> wrote:
>
>>
>> > On Aug 7, 2017, at 11:34 PM, Elviro Rocca <
>> retired.hunter.djura at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170808/bf38de2f/attachment.html>