Re: [swift-evolution] A case for postponing ABI stability

I have to assume that was sarcasm. The Release to Release Binary Compatibility with SOM (http://hobbes.nmsu.edu/h-viewer.php?dir=/pub/os2/doc=R2R_SOM.zip) paper includes the following footnote: "We exclude Microsoft’s COM [14] because it is an interface model, not an object model and it’s ABI

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 27, 2017, at 2:08 PM, Freak Show via swift-evolution > wrote: > > Maybe so - but IB M > solved this very problem along with release to release binary compatibility > for C++ and a number of other languages twenty years ago with the System > Object Model

Re: [swift-evolution] A case for postponing ABI stability

Yup. If the root of all evil for programming is premature optimization, the root of all evil for design is premature standardization. Thanks, Jon > On Jan 27, 2017, at 5:54 PM, Matt Whiteside via swift-evolution > wrote: > > >> On Jan 26, 2017, at 13:14, Matthew

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 27, 2017, at 3:08 PM, Freak Show via swift-evolution > wrote: > > Maybe so - but IBM solved this very problem along with release to release > binary compatibility for C++ and a number of other languages twenty years ago > with the System Object Model

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 26, 2017, at 13:14, Matthew Johnson via swift-evolution > wrote: > > >> On Jan 26, 2017, at 3:10 PM, Dave Abrahams via swift-evolution >> wrote: >> but it's equally possible that we find ourselves >> painted into a corner. >

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 27, 2017, at 11:27 AM, Tino Heth via swift-evolution > wrote: > >> Rather than Apple have to commit in perpetuity to ship all relevant versions >> of the frameworks, one could imagine more of an app-thinning/install-time >> optimization: “thinned” versions

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 27, 2017, at 11:27 AM, Tino Heth <2...@gmx.de> wrote: > >> Rather than Apple have to commit in perpetuity to ship all relevant versions >> of the frameworks, one could imagine more of an app-thinning/install-time >> optimization: “thinned” versions of apps would be built and signed

Re: [swift-evolution] A case for postponing ABI stability

Maybe so - but IBM solved this very problem along with release to release binary compatibility for C++ and a number of other languages twenty years ago with the System Object Model (SOM). I'm not arguing for its adoption per se - but good ideas are always worth stealing and there was some

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 27, 2017, at 9:19 AM, Tino Heth <2...@gmx.de> wrote: > >> It would mean for Apple (and others who'd distribute compiled frameworks) to >> maintain several code bases of the same framework given that they would need >> to maintain backward compatibility and hence wouldn't be able to

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 27, 2017, at 8:59 AM, Charlie Monroe via swift-evolution > wrote: > > >> On Jan 27, 2017, at 5:43 PM, Tino Heth <2...@gmx.de > >> wrote: >> - runtime libraries for Swift 4 - all system frameworks will need to contain two

Re: [swift-evolution] A case for postponing ABI stability

> Rather than Apple have to commit in perpetuity to ship all relevant versions > of the frameworks, one could imagine more of an app-thinning/install-time > optimization: “thinned” versions of apps would be built and signed without > the shared system frameworks, but with dependency information

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 27, 2017, at 11:09 AM, David Scrève via swift-evolution > wrote: >>> On Jan 27, 2017, at 2:57 AM, Charlie Monroe via >>> swift-evolutionwrote: > >>> >> That's right. If the OS frameworks use Swift

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 27, 2017, at 9:21 AM, James Berry wrote: >> It would mean for Apple (and others who'd distribute compiled frameworks) to >> maintain several code bases of the same framework given that they would need >> to maintain backward compatibility and hence wouldn't be

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 27, 2017, at 5:43 PM, Tino Heth <2...@gmx.de> wrote: > >>> - runtime libraries for Swift 4 >>> - all system frameworks will need to contain two variants - one compatible >>> with Swift 4 and one with Swift 5. This is IMHO absolutely unmaintainable >>> in the long run. For how long

Re: [swift-evolution] A case for postponing ABI stability

>> - runtime libraries for Swift 4 >> - all system frameworks will need to contain two variants - one compatible >> with Swift 4 and one with Swift 5. This is IMHO absolutely unmaintainable in >> the long run. For how long would you need to keep several versions of the >> framework around? What

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 27, 2017, at 2:57 AM, Charlie Monroe via swift-evolution > wrote: > >> On Jan 27, 2017, at 11:35 AM, Tino Heth via swift-evolution >> > wrote: >> >>> I don’t disagree with your overall point, but

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 26, 2017, at 9:48 PM, Dave Abrahams via swift-evolution > wrote: > > > on Thu Jan 26 2017, Matthew Johnson wrote: > >>> On Jan 26, 2017, at 3:10 PM, Dave Abrahams via swift-evolution >>> wrote: >>>

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 26, 2017, at 8:22 PM, Michael Ilseman wrote: > > >> On Jan 26, 2017, at 5:48 PM, Matthew Johnson via swift-evolution >> > wrote: >> >> >> >> Sent from my iPad >> >> On Jan 26, 2017, at 7:29 PM, Ted

Re: [swift-evolution] A case for postponing ABI stability

> I don’t disagree with your overall point, but I do want to emphasize that > forcing apps to bundle the stdlib and runtime is more than just suboptimal. Wouldn't it be possible to have several versions of the runtime bundled with the OS? Frameworks on macOS still have a filesystem layout that

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 27, 2017, at 11:35 AM, Tino Heth via swift-evolution > wrote: > > >> I don’t disagree with your overall point, but I do want to emphasize that >> forcing apps to bundle the stdlib and runtime is more than just suboptimal. > > Wouldn't it be possible to

Re: [swift-evolution] A case for postponing ABI stability

> I don’t disagree with your overall point, but I do want to emphasize that > forcing apps to bundle the stdlib and runtime is more than just suboptimal. Wouldn't it be possible to have several versions of the runtime bundled with the OS? Frameworks on macOS still have a filesystem layout that

Re: [swift-evolution] A case for postponing ABI stability

Sent from my iPhone > On 27 Jan 2017, at 07:04, Goffredo Marocchi wrote: > > In a way some people moved to a new language with few years of life under its > belt and should kind of expect the language not offering the stability and > maturity something tested and

Re: [swift-evolution] A case for postponing ABI stability

on Thu Jan 26 2017, Matthew Johnson wrote: >> On Jan 26, 2017, at 3:10 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Thu Jan 26 2017, David Hart wrote: >> > >>> Thanks Michael for the manifesto.

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 26, 2017, at 5:48 PM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > > On Jan 26, 2017, at 7:29 PM, Ted Kremenek > wrote: > >> >>> On Jan 26, 2017, at 12:19 PM, Matthew Johnson

Re: [swift-evolution] A case for postponing ABI stability

Sent from my iPad > On Jan 26, 2017, at 7:29 PM, Ted Kremenek wrote: > > >> On Jan 26, 2017, at 12:19 PM, Matthew Johnson via swift-evolution >> wrote: >> >> Locking down ABI when all foreseeable desirable changes are additive is one >>

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 26, 2017, at 12:19 PM, Matthew Johnson via swift-evolution > wrote: > > Locking down ABI when all foreseeable desirable changes are additive is one > thing. But doing so before we get there feels premature. I fully agree that locking down the ABI

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 26, 2017, at 1:02 PM, Rick Mann via swift-evolution > wrote: > > Thanks for that, that's helpful. > > My concern, of course, is the obvious one: that we'll have to compromise on > future functionality in order to not break ABI compatibility, or we'll have

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 26, 2017, at 2:15 PM, David Sweeris via swift-evolution > wrote: > >> On Jan 26, 2017, at 13:02, Rick Mann via swift-evolution >> wrote: >> >> Thanks for that, that's helpful. >> >> My concern, of course, is the obvious one:

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 26, 2017, at 13:02, Rick Mann via swift-evolution > wrote: > > Thanks for that, that's helpful. > > My concern, of course, is the obvious one: that we'll have to compromise on > future functionality in order to not break ABI compatibility, or we'll have a

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 26, 2017, at 3:10 PM, Dave Abrahams via swift-evolution > wrote: > > > on Thu Jan 26 2017, David Hart wrote: > >> Thanks Michael for the manifesto. It definitely made quite a few things >> clearer for me. >> >> Concerning the

Re: [swift-evolution] A case for postponing ABI stability

on Thu Jan 26 2017, David Hart wrote: > Thanks Michael for the manifesto. It definitely made quite a few things > clearer for me. > > Concerning the topic of when ABI stability should happen, I still have > a strong feelings that Swift 4 might not be the best time

Re: [swift-evolution] A case for postponing ABI stability

Thanks for that, that's helpful. My concern, of course, is the obvious one: that we'll have to compromise on future functionality in order to not break ABI compatibility, or we'll have a painful transition when we do break it. While today it's suboptimal to ship copies of the runtime with each

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 26, 2017, at 2:12 PM, David Hart via swift-evolution > wrote: > > Thanks Michael for the manifesto. It definitely made quite a few things > clearer for me. > > Concerning the topic of when ABI stability should happen, I still have a > strong feelings that

Re: [swift-evolution] A case for postponing ABI stability

Thanks Michael for the manifesto. It definitely made quite a few things clearer for me. Concerning the topic of when ABI stability should happen, I still have a strong feelings that Swift 4 might not be the best time for it. Concerning Data Layout, Type Metadata, Mangling, the Calling

Re: [swift-evolution] A case for postponing ABI stability

As described in e.g. https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md#what-does-abi-stability-enable , it primarily enables OSes to ship with a copy of the standard

Re: [swift-evolution] A case for postponing ABI stability

I'm also late to the thread (and the ABI stability discussion in general). Is there a reference online that describes the reason for desiring ABI stability? I mean, I get, generally, why we need it. But I'd like to see the arguments for why we need it *now*, before certain other things are in

Re: [swift-evolution] A case for postponing ABI stability

Hi David, My apologies for being late to the thread — I've been away for the last week. ABI stability remains a keystone goal for Swift, but the concerns you have here about not rushing important things are real. There's been a lot of scoping work into what ABI stability means, soup-to-nuts

Re: [swift-evolution] A case for postponing ABI stability

This is both great to hear (ivar introspection available) and a little disappointing (method level not). Basically, I would hope for at least enough to allow implementation of KVC - which would require the ability to find and invoke methods by name. > On Jan 24, 2017, at 14:16, Joe Groff

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 24, 2017, at 12:15 PM, Freak Show via swift-evolution > wrote: > > I do not see how you can consider standardizing ABI without first > standardizing the dynamic features and the desired programmatic interfaces to > them. > > We know that dynamic

Re: [swift-evolution] A case for postponing ABI stability

I do not see how you can consider standardizing ABI without first standardizing the dynamic features and the desired programmatic interfaces to them. We know that dynamic features need to come. They will impact everything. My personal ideal is a language that smoothly transitions from fully

Re: [swift-evolution] A case for postponing ABI stability

I agree that we shouldn't rush decisions but I feel like the emphasis of ABI stability has been a factor in discussing a number of proposals for Swift 4 and has been a core goal of this next major release. Seems strange to deemphasize it and its importance at this time. Below are some thoughts

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 24, 2017, at 12:12 AM, Tino Heth via swift-evolution > wrote: > > Imho the major problem is that there's quite a lot confusion about what ABI > stability actually means — and a lot uncertainty which proposals would > actually affect it. I’m hoping to

Re: [swift-evolution] A case for postponing ABI stability

> I'm not really sure if the String-changes affect the ABI, but none the less, > I strongly agree with your opinion that things shouldn't be done in a hurry, > and I hope that Swift keeps the courage to break things for the better > (sporadically ;-) +1

Re: [swift-evolution] A case for postponing ABI stability

I definitely agree. With Swift 3, especially near the end, we had a bunch of changes that were rushed in because “we won’t have a chance to change it later, so let’s do it just in case”. I think setting these deadlines leads to worse choices overall. That said, we do need stability so that we

Re: [swift-evolution] A case for postponing ABI stability

Imho the major problem is that there's quite a lot confusion about what ABI stability actually means — and a lot uncertainty which proposals would actually affect it. People with more insight may prove me wrong, but I'll lay out my understanding in the next paragraph: It shouldn't be hard to