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

[Freak Show via swift-evolution]

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 forbids subclassing between library and application. 
If our analysis technique is applied to COM, one sees that it supports only 
Transformations 0 to 4, which places it in the category of procedural pro- 
gramming rather than object-oriented programming. "

> On Jan 28, 2017, at 23:18, Russ Bishop  wrote:
> 
> Yeah and Microsoft’s COM is a reasonable approach

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Russ Bishop via swift-evolution]

> 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 (SOM).

Yeah and Microsoft’s COM is a reasonable approach (and Apple ships a version of 
it used for plugin loading).

Unfortunately you end up with IFrob, IFrob2, IFrob3, IFrob4, IFrobEx, IFrobEx2. 
You also introduce a hard boundary that makes passing “native” types across the 
boundary impossible. Everything must fit inside the set of types described by 
COM. For Swift any scheme boils down to “use a lowest-common-denominator and 
give up all of Swift’s advanced type system features”.

Believe me, there are parts of the Simulator stack where I would like to use 
Swift but without ABI stability it just isn’t possible. If there were a 
plausible alternative I’d happily take it. There isn’t.

Russ

> 
> I'm not arguing for its adoption per se - but good ideas are always worth 
> stealing and there was some solid engineering in there.
> 
> Sent from the road
> 
>> On Jan 27, 2017, at 09:19, Tino Heth via swift-evolution 
>>  wrote:
>> 
>> I wouldn't expect that I can mix language and framework versions freely.
> ___
> 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

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

[Jonathan Hull via swift-evolution]

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 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.
>> 
>> I hope we can all agree that the last thing we want to do is get painted 
>> into a corner.  IMO we should be very sure that won’t happen before making a 
>> firm commitment to lock down ABI stability.
>> 
> 
> I agree strongly.
> 
> -Matt 
> ___
> 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

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

[Christopher Kornher via swift-evolution]

> 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 (SOM).

As one of the developers of the ill-fated WWDC OpenDoc demos that failed 
spectacularly because of bugs in early versions of SOM, I just want to caution 
everyone not to underestimate the complexity of these solutions and the level 
of effort required to bring them up to production quality.

That being said, it is probably too constraining to assume that one ABI should 
last more than a few years for a language like Swift that is destined for 
“world domination” and will eventually be used for platforms spanning from 
watches (and smaller) to data centers and solutions from scripting to real-time 
systems. This is a great time for language design — the most prolific period of 
language development I have ever seen. There is no reason to expect the pace of 
language innovation to slow down and new ideas will probably force Swift to 
stand still or break ABI compatibility if a system is not developed to support 
ABI migration.

> 
> I'm not arguing for its adoption per se - but good ideas are always worth 
> stealing and there was some solid engineering in there.
> 
> Sent from the road
> 
>> On Jan 27, 2017, at 09:19, Tino Heth via swift-evolution 
>>  wrote:
>> 
>> I wouldn't expect that I can mix language and framework versions freely.
> ___
> 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

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

[Matt Whiteside via swift-evolution]

> 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.
> 
> I hope we can all agree that the last thing we want to do is get painted into 
> a corner.  IMO we should be very sure that won’t happen before making a firm 
> commitment to lock down ABI stability.
> 

I agree strongly.

-Matt 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Chris Lattner via swift-evolution]

> 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 of apps would be built and signed without 
>> the shared system frameworks, but with dependency information recorded. At 
>> install-time, the app would be installed, and the working set of required 
>> shared frameworks on the device would be updated with any needed dependent 
>> frameworks. Thus the only the set of frameworks required by installed apps 
>> would be present on device.
>> 
>> This would require more app store, install-time, and perhaps dynamic 
>> linking, infrastructure, but would seem to solve the problem in a way that 
>> wouldn’t require ongoing development resources be applied to old versions.
> 
> I'm thinking in the same direction… but although this isn't trivial, it still 
> sounds to simple to be a solution for the dreaded problem of unstable ABI, so 
> I can't fight the feeling I'm missing something important ;-):
> What is the main motivation for ABI stability?
> Sure, it would reduce app size, and this could be achieved with with this 
> approach as well — but nowadays many apps are so bloated that 10MB make no 
> real difference.

These are the benefits of ABI stability that I can see [**]:

1. Not shipping the stdlib with your app reduces its download size.
2. 3rd party developers could someday ship binary packages/frameworks.
3. Apple could choose to ship OS frameworks with “Swift only” enhancements 
(e.g. a method that takes an "Int?” argument).

That said, I think that these wins are often overstated and poorly understood.  

On #1, as you say, there are lots of ways to reduce the impact of the Swift 
stdlib size in general, and a lot of the work on ABI stability pushes towards 
this.  As it is today, the overhead is only a few MB anyway (not the 10’s of MB 
that people think by looking at the size with bitcode included) because of how 
“app thinning” works.  Further, if some version of iOS “N” included the stdlib, 
your app would still need to include the stdlib if your app needs to deploy 
backwards to "iOS N-1”.  There are other things that could be done that would 
have a huge benefit, like merge all the overlay dylibs + Swift stdlib together 
into one large dylib.  This would improve app launch time independently of ABI 
stability.

On #2, as Michael’s document indicates, this requires stabilizing the ABI *and* 
the module file format.  The second clearly isn’t in scope for Swift 4, so it 
isn’t really a motivator for this.  Also, adding a binary-only dependency to 
your App is always a risk thing.

On #3, it isn’t a truly great solution, but the existing overlay mechanism has 
been proven as a way to ship substantial Swift-only enhancements to the OS.  In 
Swift 3, Foundation included major enhancements including entirely new types 
like Data.  It has additional advantage of allowing backward deployment of this 
functionality.


In short, in the Swift 4 / iOS "N" timeframe, the only benefit of ABI stability 
would be that apps don’t need to include the standard library if they deploy to 
iOS "N or later”.  Independent of whether ABI stability is achievable, I think 
it is important to do things like merge the dylibs together, since backward 
deployment will continue to be important for many apps.

-Chris

[**]  Just a note, but I don’t think that any of these apply to Linux or other 
non-Apple platforms supported by Swift.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[James Berry via swift-evolution]

> 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 without 
>> the shared system frameworks, but with dependency information recorded. At 
>> install-time, the app would be installed, and the working set of required 
>> shared frameworks on the device would be updated with any needed dependent 
>> frameworks. Thus the only the set of frameworks required by installed apps 
>> would be present on device.
>> 
>> This would require more app store, install-time, and perhaps dynamic 
>> linking, infrastructure, but would seem to solve the problem in a way that 
>> wouldn’t require ongoing development resources be applied to old versions.
> 
> I'm thinking in the same direction… but although this isn't trivial, it still 
> sounds to simple to be a solution for the dreaded problem of unstable ABI, so 
> I can't fight the feeling I'm missing something important ;-):
> What is the main motivation for ABI stability?
> Sure, it would reduce app size, and this could be achieved with with this 
> approach as well — but nowadays many apps are so bloated that 10MB make no 
> real difference.
> Declaring a stable ABI is also a statement of maturity (I don't care much 
> about that, but others might feel different), and there might be other goals 
> I'm not even aware of, and which cannot be reached with "tricks".

> On Jan 27, 2017, at 2:21 PM, Greg Parker via swift-evolution 
>  wrote:

> You can't simply freeze an old version of a framework. Many app frameworks 
> have interfaces with other OS components. Freezing the app side of the 
> interface also constrains the other side, effectively introducing another 
> piece of ABI that must be kept stable.
> 
> For example, CoreGraphics needs to talk to the window server. If you try to 
> freeze some version of CoreGraphics then you require the window server to 
> implement that particular interface forever. Now the window server's private 
> interface has become an ABI that must preserve binary compatibility. The same 
> is true for the spellcheck server, the pasteboard server, the address book 
> database server, and a great many others.


Greg’s words from upthread are instructive. The current interface between app 
bundles, and the rest of the system, is currently limited to the C/Obj-C ABI. 
While the idea above could potentially allow you to factor common libraries out 
of the apps we have today, those libraries, and the apps themselves, would 
still be limited to the C/ObjC ABI to speak to the rest of the system. To have 
any prayer of being able to have apps call into more modern, and non-objc, 
Swift frameworks in the rest of the system, you need to have a stable ABI for 
swift. So the idea might work for the apps of today, but it doesn’t do much to 
enable the apps (and system frameworks) of tomorrow.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Freak Show via swift-evolution]

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 solid engineering in there.

Sent from the road

> On Jan 27, 2017, at 09:19, Tino Heth via swift-evolution 
>  wrote:
> 
> I wouldn't expect that I can mix language and framework versions freely.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Greg Parker via swift-evolution]

> 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 use new 
>> language features, etc. It's IMHO not that much about the technical 
>> constraint of having multiple binaries within the framework bundle as much 
>> as maintaining the code in a way that would compile under all Swift versions 
>> you'd like to support.
> 
> I haven't spend much time thinking about the implications, but wouldn't it be 
> feasible to freeze old frameworks completely when a new Swift version is 
> added?
> After all, bundled code isn't updated at all, so I see no downside here — 
> actually, it only adds flexibility that could be utilised when critical bugs 
> are discovered.

You can't simply freeze an old version of a framework. Many app frameworks have 
interfaces with other OS components. Freezing the app side of the interface 
also constrains the other side, effectively introducing another piece of ABI 
that must be kept stable.

For example, CoreGraphics needs to talk to the window server. If you try to 
freeze some version of CoreGraphics then you require the window server to 
implement that particular interface forever. Now the window server's private 
interface has become an ABI that must preserve binary compatibility. The same 
is true for the spellcheck server, the pasteboard server, the address book 
database server, and a great many others.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

> 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 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 happens when Swift 6 comes along with another 
 breaking changes? Would each system framework have 3 versions embedded?
>>> 
>>> That's right. If the OS frameworks use Swift then either (1) you have to 
>>> clone the framework stack for each Swift version, or (2) you have only one 
>>> copy of the frameworks but frameworks and apps can't share their Swift 
>>> objects or publish Swift API.
>>> 
>>> The framework structure that Apple inherited from NeXT supports framework 
>>> versioning, but *no frameworks use it*. It doesn't scale. 
>> 
>> 
>> sure, it's preferable to have a single version that works with all apps — 
>> but if it's technically possible to have one clone installed with the OS, 
>> isn't that better than one version for each app?
>> Managing several versions shouldn't be that hard (have a look at 
>> https://nixos.org/nix/ ).
> 
> 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 use new 
> language features, etc. It's IMHO not that much about the technical 
> constraint of having multiple binaries within the framework bundle as much as 
> maintaining the code in a way that would compile under all Swift versions 
> you'd like to support.


If I understand things correctly, as long as the declarations for any new API 
features which depend on new ABI features are wrapped in "#if swift(>= 
_relevant_version_goes_here_) … #endif” statements, the system frameworks could 
be one codebase that the runtime vender compiles to multiple targets, right? 
Because any code that relied on Swift 5’s shiny new, non-backwards compatible, 
generics feature (or whatever) simply wouldn’t exist in the runtime/stdlib that 
Swift 3 binaries are looking for? Or is this one of those things that works 
better in theory than it does in practice? Specifically, I don’t know if code 
that’s correct when compiled for Swift 3’s ABI is always still correct when 
it’s compiled for Swift 4/5/etc’s ABI. If it is, it seems like it’d make the 
task much easier... For each subsequent version of the ABI, we'd only need to 
test the parts of the stdlib that depend on the new ABI, since the parts that 
could be compiled for earlier ABIs would’ve already been tested when that 
version of the runtime/stdlib was compiled. At least, if it does actually work 
that way.

I very much agree that only having to deal with one runtime and one version of 
the system frameworks is clearly the ideal, but I also think it’s important to 
have an accurate understanding of what it would really cost a 
vendor/organization to commit to supporting multiple versions.

- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tino Heth via swift-evolution]

> 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 recorded. At 
> install-time, the app would be installed, and the working set of required 
> shared frameworks on the device would be updated with any needed dependent 
> frameworks. Thus the only the set of frameworks required by installed apps 
> would be present on device.
> 
> This would require more app store, install-time, and perhaps dynamic linking, 
> infrastructure, but would seem to solve the problem in a way that wouldn’t 
> require ongoing development resources be applied to old versions.

I'm thinking in the same direction… but although this isn't trivial, it still 
sounds to simple to be a solution for the dreaded problem of unstable ABI, so I 
can't fight the feeling I'm missing something important ;-):
What is the main motivation for ABI stability?
Sure, it would reduce app size, and this could be achieved with with this 
approach as well — but nowadays many apps are so bloated that 10MB make no real 
difference.
Declaring a stable ABI is also a statement of maturity (I don't care much about 
that, but others might feel different), and there might be other goals I'm not 
even aware of, and which cannot be reached with "tricks".___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[John McCall via swift-evolution]

> 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 then either (1) you have to 
>> clone the framework stack for each Swift version, or (2) you have only one 
>> copy of the frameworks but frameworks and apps can't share their Swift 
>> objects or publish Swift API.
>> 
>> The framework structure that Apple inherited from NeXT supports framework 
>> versioning, but *no frameworks use it*. It doesn't scale.
>> 
>> (NeXT used framework versioning a few times, back when the entire OS only 
>> had a handful of frameworks. Today's AppKit and Foundation are version C. 
>> libSystem is version B. That's about it.)
> 
>   I completely agree with ABI stability goal…I only have a fear regarding 
> some postponed evolutions requests especially Abstract Classes. Would it be 
> still possible ?

Abstract classes do not require anything special in terms of runtime support.  
The ABI for an abstract class is basically the same as the ABI for a class 
except that you don't need to emit anything that would only be used for 
creating an instance of that class as the most-derived class.  We'd probably 
want to reserve a bit in the metadata to say "this class is abstract" just for 
reflection purposes, but even that can be done retroactively.

John.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[James Berry via swift-evolution]

> 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 able to use new 
>> language features, etc. It's IMHO not that much about the technical 
>> constraint of having multiple binaries within the framework bundle as much 
>> as maintaining the code in a way that would compile under all Swift versions 
>> you'd like to support.
> 
> 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 recorded. At 
> install-time, the app would be installed, and the working set of required 
> shared frameworks on the device would be updated with any needed dependent 
> frameworks. Thus only the set of frameworks required by installed apps would 
> be present on device.
> 
> This would require more app store, install-time, and perhaps dynamic linking, 
> infrastructure, but would seem to solve the problem in a way that wouldn’t 
> require ongoing development resources be applied to old versions.

i.e., you’re really just automatically factoring out frameworks that are 
common/redundant across apps in order to make install(ed) payloads smaller.

> 
> James
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

> 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 would you need to keep several versions of 
>>> the framework around? What happens when Swift 6 comes along with another 
>>> breaking changes? Would each system framework have 3 versions embedded?
>> 
>> That's right. If the OS frameworks use Swift then either (1) you have to 
>> clone the framework stack for each Swift version, or (2) you have only one 
>> copy of the frameworks but frameworks and apps can't share their Swift 
>> objects or publish Swift API.
>> 
>> The framework structure that Apple inherited from NeXT supports framework 
>> versioning, but *no frameworks use it*. It doesn't scale. 
> 
> 
> sure, it's preferable to have a single version that works with all apps — but 
> if it's technically possible to have one clone installed with the OS, isn't 
> that better than one version for each app?
> Managing several versions shouldn't be that hard (have a look at 
> https://nixos.org/nix/ ).

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 use new language 
features, etc. It's IMHO not that much about the technical constraint of having 
multiple binaries within the framework bundle as much as maintaining the code 
in a way that would compile under all Swift versions you'd like to support.



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tino Heth via swift-evolution]

>> - 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 happens when Swift 6 comes along with another 
>> breaking changes? Would each system framework have 3 versions embedded?
> 
> That's right. If the OS frameworks use Swift then either (1) you have to 
> clone the framework stack for each Swift version, or (2) you have only one 
> copy of the frameworks but frameworks and apps can't share their Swift 
> objects or publish Swift API.
> 
> The framework structure that Apple inherited from NeXT supports framework 
> versioning, but *no frameworks use it*. It doesn't scale. 


sure, it's preferable to have a single version that works with all apps — but 
if it's technically possible to have one clone installed with the OS, isn't 
that better than one version for each app?
Managing several versions shouldn't be that hard (have a look at 
https://nixos.org/nix/ ).___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Greg Parker via swift-evolution]

> 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 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 is build 
>> around the idea of having several versions in one bundle.
> 
> I have personally thought about this as well, but it would also mean that the 
> OS frameworks would need to come in several versions - imagine the following 
> scenario:
> 
> Swift 4 libraries are included with macOS 10.13, some frameworks in the 
> system link against them (e.g. AppKit).
> 
> Then, with macOS 10.14, Swift 5 comes along with ABI incompatible changes. 
> AFAICT, if you want apps written compiled with Swift 4 to work under 10.14, 
> you'll need:
> 
> - 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 happens when Swift 6 comes along with another breaking 
> changes? Would each system framework have 3 versions embedded?

That's right. If the OS frameworks use Swift then either (1) you have to clone 
the framework stack for each Swift version, or (2) you have only one copy of 
the frameworks but frameworks and apps can't share their Swift objects or 
publish Swift API.

The framework structure that Apple inherited from NeXT supports framework 
versioning, but *no frameworks use it*. It doesn't scale. 

(NeXT used framework versioning a few times, back when the entire OS only had a 
handful of frameworks. Today's AppKit and Foundation are version C. libSystem 
is version B. That's about it.)


>> Also, breaking ABI isn't that uncommon: C++ did so in the past (and imho 
>> that language did things that are worse ;-)

Note that Apple's OS frameworks do not export C++ interfaces. One reason was 
exactly that historically-unstable C++ ABI. Apple's OS developers chose #2 
above for C++. OS frameworks and apps could get away with mismatched C++ ABI 
because they don't pass C++ objects to each other.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> 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:
>>> 
>>> 
>>> 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 for
 it. Concerning Data Layout, Type Metadata, Mangling, the Calling
 Convention and the Runtime, I don’t know enough about them to
 comment. I’m really centring my discussion on the Standard Library.
 
 If we look back at the evolution of the Standard Library for Swift 3,
 they were many changes. And I’m personally very happy with the
 thoughtful design that went into those. But they are still a few
 gotchas, which is to be expected when so many changes are made at
 once. But we only discover them once the thousands of Swift developers
 start using those APIs.
 
 I just worry that all the big changes that will come for Swift 4 won’t
 have time to mature. Furthermore, it seems like several extra compiler
 features which won’t happen in Swift 4 are really necessary to
 simplify the Standard Library surface area. I’m specifically thinking
 of type constraints on Existentials which would allow us to get rid of
 all the Any* structs and replace them with typedefs. But I’m sure
 there are more examples like those which are just waiting for the
 generics to become powerful enough to express APIs more elegantly.
 
 Perhaps someone from the Standard Library team can chime in to give us
 their opinion on this topic.
>>> 
>>> I have had exactly the same worry for quite some time.  We're still
>>> waiting for many basic components of the generics system, and, if our
>>> experience with protocol extensions is any guide, before we have those
>>> features in hand, it will be impossible to anticipate the design changes
>>> we'd want to make to the standard library... and that cuts against the
>>> grain of *source* (to say nothing of ABI) stability.
>>> 
>>> So far I've been unable to form a mental model for what source and/or
>>> ABI stability actually means for our ability to make changes to the
>>> standard library in the future.  It's possible that we discover a
>>> workable path forward, but it's equally possible that we find ourselves
>>> painted into a corner.
>> 
>> I hope we can all agree that the last thing we want to do is get
>> painted into a corner.  IMO we should be very sure that won’t happen
>> before making a firm commitment to lock down ABI stability.
> 
> Unfortunately, even source stability (which is generally a weaker
> constraint than ABI stability) can have the corner-painting effect, and
> you really have to weigh that downside off against the cost of breaking
> people's code when they upgrade their Swift version.  IIUC that has been
> a major pain point for many people.

Yes, for sure.  I just don’t want to see us end up with baggage in the long run 
because we made promises when foreseeable changes were still on the horizon.

Swift 3 migration has definitely caused some pain.  For a small to moderate 
sized app with a small team it is kind of annoying not really that bad (a 
couple days tops).  For larger apps with larger teams it is pretty disruptive.  
I’ll be part of the migration effort for a fairly large app in the near future. 
 I’m really interested to see how that migration plays out.

I imagine future source breaking changes will be much more modest and we will 
have a better story around dependencies so I expect the pain will be 
significantly less.  We will also have the experience of the Swift 3 migration 
which will help in weighing what the real world cost of specific proposed 
changes might be.

> 
> -- 
> -Dave
> 
> ___
> 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

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

[Matthew Johnson via swift-evolution]

> 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 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 thing.  But doing so before we get there feels premature.
>>> 
>>> 
>>> I fully agree that locking down the ABI prematurely would be detrimental to 
>>> the long-term future of the language.
>>> 
>>> Part of the point of the ABI manifesto is to scope out what are the 
>>> desirable or critical changes needed before ABI gets locked down.  From 
>>> that we can have concrete discussions on what’s left to be done, how much 
>>> work it will take to get there, etc.
>> 
>> That makes perfect sense.  
>> 
>> One thing that isn't clear in the manifesto that I think a lot of us are 
>> wondering about is what language features are important to the long-term 
>> desired design of the standard library that aren't in place yet?  There has 
>> been some informal discussion of this on the list but nothing more and it 
>> hasn't been clear whether those features will be ready by the time ABI 
>> stability is locked down.   Maybe the manifesto is a good place to start 
>> documenting more formally the language features needed to realize the 
>> desired design of the standard library APIs that will be present when the 
>> ABI is declared stable.
> 
> There’s a bit of a chicken-and-the-egg problem here, where the stdlib will 
> discover better APIs after playing with new language features. This is one of 
> the reasons for the intense focus in Swift 4 phase 1.

Yes of course.  But I imagine we could come up with a reasonable list of 
language features that we *think* would have an impact on the library APIs that 
exist today.

> 
>> ___
>> 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

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

[Tino Heth via swift-evolution]

> 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 is build around 
the idea of having several versions in one bundle.

Also, breaking ABI isn't that uncommon: C++ did so in the past (and imho that 
language did things that are worse ;-)

I guess the problem is at least partly a phycological one:
ABI stability was supposed to be one major feature of Swift 3, and it's 
somewhat depressing when big goals are delayed over and over.

Maybe you could "stabilise" the ABI temporarily, and plan for a breaking change 
in two or three years, when the dust has settled?
Doing so would reduce the pressure, and long-term Mac developers are used to 
huge breaking changes anyway ;-)
It could also free resources to work on features and ideas that help to realise 
shortcomings worth to be addressed in a "really stable" ABI.

[have to remember to write something for the "switch to Discourse"-thread — 
seems this message got lost]___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

> 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 have several versions of the runtime bundled with 
> the OS? Frameworks on macOS still have a filesystem layout that is build 
> around the idea of having several versions in one bundle.

I have personally thought about this as well, but it would also mean that the 
OS frameworks would need to come in several versions - imagine the following 
scenario:

Swift 4 libraries are included with macOS 10.13, some frameworks in the system 
link against them (e.g. AppKit).

Then, with macOS 10.14, Swift 5 comes along with ABI incompatible changes. 
AFAICT, if you want apps written compiled with Swift 4 to work under 10.14, 
you'll need:

- 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 happens when Swift 6 comes along with another breaking changes? 
Would each system framework have 3 versions embedded?

> 
> Also, breaking ABI isn't that uncommon: C++ did so in the past (and imho that 
> language did things that are worse ;-)
> 
> I guess the problem is at least partly a phycological one:
> ABI stability was supposed to be one major feature of Swift 3, and it's 
> somewhat depressing when big goals are delayed over and over.
> 
> Maybe you could "stabilise" the ABI temporarily, and plan for a breaking 
> change in two or three years, when the dust has settled?
> Doing so would reduce the pressure, and long-term Mac developers are used to 
> huge breaking changes anyway ;-)
> It could also free resources to work on features and ideas that help to 
> realise shortcomings worth to be addressed in a "really stable" ABI.
> ___
> 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

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

[Tino Heth via swift-evolution]

> 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 is build around 
the idea of having several versions in one bundle.

Also, breaking ABI isn't that uncommon: C++ did so in the past (and imho that 
language did things that are worse ;-)

I guess the problem is at least partly a phycological one:
ABI stability was supposed to be one major feature of Swift 3, and it's 
somewhat depressing when big goals are delayed over and over.

Maybe you could "stabilise" the ABI temporarily, and plan for a breaking change 
in two or three years, when the dust has settled?
Doing so would reduce the pressure, and long-term Mac developers are used to 
huge breaking changes anyway ;-)
It could also free resources to work on features and ideas that help to realise 
shortcomings worth to be addressed in a "really stable" ABI.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

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 developed over many years like Objective-C 
> provides.
> 
> As mean as that may sound (not trying to be), are the needs of the language 
> and medium term users listened to because of people moving critical 
> production code before it was time?
> 
> Sent from my iPhone
> 
>> On 27 Jan 2017, at 03:48, 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:
 
 
 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 for
> it. Concerning Data Layout, Type Metadata, Mangling, the Calling
> Convention and the Runtime, I don’t know enough about them to
> comment. I’m really centring my discussion on the Standard Library.
> 
> If we look back at the evolution of the Standard Library for Swift 3,
> they were many changes. And I’m personally very happy with the
> thoughtful design that went into those. But they are still a few
> gotchas, which is to be expected when so many changes are made at
> once. But we only discover them once the thousands of Swift developers
> start using those APIs.
> 
> I just worry that all the big changes that will come for Swift 4 won’t
> have time to mature. Furthermore, it seems like several extra compiler
> features which won’t happen in Swift 4 are really necessary to
> simplify the Standard Library surface area. I’m specifically thinking
> of type constraints on Existentials which would allow us to get rid of
> all the Any* structs and replace them with typedefs. But I’m sure
> there are more examples like those which are just waiting for the
> generics to become powerful enough to express APIs more elegantly.
> 
> Perhaps someone from the Standard Library team can chime in to give us
> their opinion on this topic.
 
 I have had exactly the same worry for quite some time.  We're still
 waiting for many basic components of the generics system, and, if our
 experience with protocol extensions is any guide, before we have those
 features in hand, it will be impossible to anticipate the design changes
 we'd want to make to the standard library... and that cuts against the
 grain of *source* (to say nothing of ABI) stability.
 
 So far I've been unable to form a mental model for what source and/or
 ABI stability actually means for our ability to make changes to the
 standard library in the future.  It's possible that we discover a
 workable path forward, but it's equally possible that we find ourselves
 painted into a corner.
>>> 
>>> I hope we can all agree that the last thing we want to do is get
>>> painted into a corner.  IMO we should be very sure that won’t happen
>>> before making a firm commitment to lock down ABI stability.
>> 
>> Unfortunately, even source stability (which is generally a weaker
>> constraint than ABI stability) can have the corner-painting effect, and
>> you really have to weigh that downside off against the cost of breaking
>> people's code when they upgrade their Swift version.  IIUC that has been
>> a major pain point for many people.
>> 
>> -- 
>> -Dave
>> 
>> ___
>> 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

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

[Dave Abrahams via swift-evolution]

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. 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
>>> Convention and the Runtime, I don’t know enough about them to
>>> comment. I’m really centring my discussion on the Standard Library.
>>> 
>>> If we look back at the evolution of the Standard Library for Swift 3,
>>> they were many changes. And I’m personally very happy with the
>>> thoughtful design that went into those. But they are still a few
>>> gotchas, which is to be expected when so many changes are made at
>>> once. But we only discover them once the thousands of Swift developers
>>> start using those APIs.
>>> 
>>> I just worry that all the big changes that will come for Swift 4 won’t
>>> have time to mature. Furthermore, it seems like several extra compiler
>>> features which won’t happen in Swift 4 are really necessary to
>>> simplify the Standard Library surface area. I’m specifically thinking
>>> of type constraints on Existentials which would allow us to get rid of
>>> all the Any* structs and replace them with typedefs. But I’m sure
>>> there are more examples like those which are just waiting for the
>>> generics to become powerful enough to express APIs more elegantly.
>>> 
>>> Perhaps someone from the Standard Library team can chime in to give us
>>> their opinion on this topic.
>> 
>> I have had exactly the same worry for quite some time.  We're still
>> waiting for many basic components of the generics system, and, if our
>> experience with protocol extensions is any guide, before we have those
>> features in hand, it will be impossible to anticipate the design changes
>> we'd want to make to the standard library... and that cuts against the
>> grain of *source* (to say nothing of ABI) stability.
>> 
>> So far I've been unable to form a mental model for what source and/or
>> ABI stability actually means for our ability to make changes to the
>> standard library in the future.  It's possible that we discover a
>> workable path forward, but it's equally possible that we find ourselves
>> painted into a corner.
>
> I hope we can all agree that the last thing we want to do is get
> painted into a corner.  IMO we should be very sure that won’t happen
> before making a firm commitment to lock down ABI stability.

Unfortunately, even source stability (which is generally a weaker
constraint than ABI stability) can have the corner-painting effect, and
you really have to weigh that downside off against the cost of breaking
people's code when they upgrade their Swift version.  IIUC that has been
a major pain point for many people.

-- 
-Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Michael Ilseman via swift-evolution]

> 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 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 prematurely would be detrimental to 
>> the long-term future of the language.
>> 
>> Part of the point of the ABI manifesto is to scope out what are the 
>> desirable or critical changes needed before ABI gets locked down.  From that 
>> we can have concrete discussions on what’s left to be done, how much work it 
>> will take to get there, etc.
> 
> That makes perfect sense.  
> 
> One thing that isn't clear in the manifesto that I think a lot of us are 
> wondering about is what language features are important to the long-term 
> desired design of the standard library that aren't in place yet?  There has 
> been some informal discussion of this on the list but nothing more and it 
> hasn't been clear whether those features will be ready by the time ABI 
> stability is locked down.   Maybe the manifesto is a good place to start 
> documenting more formally the language features needed to realize the desired 
> design of the standard library APIs that will be present when the ABI is 
> declared stable.

There’s a bit of a chicken-and-the-egg problem here, where the stdlib will 
discover better APIs after playing with new language features. This is one of 
the reasons for the intense focus in Swift 4 phase 1.

> ___
> 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

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

[Matthew Johnson via swift-evolution]

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 
>> thing.  But doing so before we get there feels premature.
> 
> 
> I fully agree that locking down the ABI prematurely would be detrimental to 
> the long-term future of the language.
> 
> Part of the point of the ABI manifesto is to scope out what are the desirable 
> or critical changes needed before ABI gets locked down.  From that we can 
> have concrete discussions on what’s left to be done, how much work it will 
> take to get there, etc.

That makes perfect sense.  

One thing that isn't clear in the manifesto that I think a lot of us are 
wondering about is what language features are important to the long-term 
desired design of the standard library that aren't in place yet?  There has 
been some informal discussion of this on the list but nothing more and it 
hasn't been clear whether those features will be ready by the time ABI 
stability is locked down.   Maybe the manifesto is a good place to start 
documenting more formally the language features needed to realize the desired 
design of the standard library APIs that will be present when the ABI is 
declared stable.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ted Kremenek via swift-evolution]

> 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 prematurely would be detrimental to the 
long-term future of the language.

Part of the point of the ABI manifesto is to scope out what are the desirable 
or critical changes needed before ABI gets locked down.  From that we can have 
concrete discussions on what’s left to be done, how much work it will take to 
get there, etc.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Michael Ilseman via swift-evolution]

> 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 a 
> painful transition when we do break it. While today it's suboptimal to ship 
> copies of the runtime with each application, it's a working solution.
> 

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. For 
many companies, increasing the OTA download size has real financial impact as 
it can affect whether new users are willing to download an app, as well as 
whether they will wait for it to download and install.

That being said, I hope that many of the ABI stability tasks[2] also result in 
smaller binary sizes for applications. They should be prioritized highly no 
matter when stability happens.

> I'd really like to make sure Swift can be fully introspective (soon), but I 
> don't know how easy it will be to add that after the ABI is locked down. 
> Maybe I'm just being alarmist. I'd also like to see the ability to replace 
> code at run time.
> 

New runtime APIs are ABI-additive. It’s likely that much of Swift’s already 
extensive type metadata will be kept opaque[1] to allow the language to 
continue to grow and change, and new entries can be added.

> If all that is already accommodated by the current ABI, then I'm satisfied. 
> But it seems like there's some concern about this, and I worry that locking 
> down the ABI too early will make those additions MUCH harder in the future.
> 

Locking down the standard library API and (some) exposed implementation details 
is certainly a scary aspect of ABI stability.

[1] 
https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md#type-metadata
 

 (third paragraph)
[2] 
https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md#compact-manglings
 

 and 
https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md#suffix-differentiation
 

 

> Thanks!
> 
>> On Jan 25, 2017, at 15:09 , Michael Ilseman  wrote:
>> 
>> 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 library and 
>> runtime, rather than every app having to bundle their own copy. It’s also a 
>> crucial piece of supporting 3rd party frameworks. There are also more subtle 
>> benefits such as the de-coupling of developer tools that work with Swift 
>> binaries (e.g. debuggers and profilers). Some of the tasks towards stability 
>> are performance improvements we want to do anyways.
>> 
>> 
>> 
>>> On Jan 25, 2017, at 1:36 PM, Rick Mann via swift-evolution 
>>>  wrote:
>>> 
>>> 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 
>>> place. Not saying the reasons for the urgency aren't valid, I just don't 
>>> know what they are.
>>> 
>>> Thanks!
>>> 
 On Jan 25, 2017, at 08:44 , Freak Show via swift-evolution 
  wrote:
 
 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  wrote:
> 
> a lot of the information you'd need for many dynamic features is already 
> there, and planned to be stabilized as part of the ABI. We already emit 
> reflection data that describes the physical layouts of types, and once 
> those formats are stabilized, building a library that interprets the 
> metadata is additive (and could conceivably be done by a third party 
> independent of the standard library). There may not be metadata for 
> individual methods yet
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> 
>>> -- 
>>> Rick Mann
>>> rm...@latencyzero.com
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> 

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

[Greg Parker via swift-evolution]

> 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: 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 application, it's a working solution.
>> 
>> I'd really like to make sure Swift can be fully introspective (soon), but I 
>> don't know how easy it will be to add that after the ABI is locked down. 
>> Maybe I'm just being alarmist. I'd also like to see the ability to replace 
>> code at run time.
>> 
>> If all that is already accommodated by the current ABI, then I'm satisfied. 
>> But it seems like there's some concern about this, and I worry that locking 
>> down the ABI too early will make those additions MUCH harder in the future.
> 
> On a scale of "trivial" to "impossible", how difficult would it be to have a 
> mechanism for telling the compiler how to translate between major versions of 
> the ABI/stdlib? Could we ship app/libs with a small "shim" library for 
> backwards compatibility, if we had to? I mean it wouldn't be ideal, but if 
> it's possible, "works" is better than either "doesn't work" or "painted into 
> a corner", isn't it?
> 
> (In any case, this seems like a last resort... I bring it up not as a 
> "proper" solution, but as a possible "emergency" way out, if we realize in 
> 2-3 years that we locked some things down too soon.)

Depends on the differences between versions. Some changes are plausible to 
patch retroactively, but for most changes it is next to impossible. 

In general each ABI detail is locked down because there are compiled 
instructions that depend on it. To a close approximation existing compiled 
instructions cannot be changed. (Compiled instructions are hard to analyze. 
Compiled instructions are hard to rearrange without throwing off things like 
code<->code and code<->data offsets. Compiled instructions are often part of 
the OS or codesigned.) 


-- 
Greg Parker gpar...@apple.com Runtime Wrangler


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

> 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 
> painful transition when we do break it. While today it's suboptimal to ship 
> copies of the runtime with each application, it's a working solution.
> 
> I'd really like to make sure Swift can be fully introspective (soon), but I 
> don't know how easy it will be to add that after the ABI is locked down. 
> Maybe I'm just being alarmist. I'd also like to see the ability to replace 
> code at run time.
> 
> If all that is already accommodated by the current ABI, then I'm satisfied. 
> But it seems like there's some concern about this, and I worry that locking 
> down the ABI too early will make those additions MUCH harder in the future.

On a scale of "trivial" to "impossible", how difficult would it be to have a 
mechanism for telling the compiler how to translate between major versions of 
the ABI/stdlib? Could we ship app/libs with a small "shim" library for 
backwards compatibility, if we had to? I mean it wouldn't be ideal, but if it's 
possible, "works" is better than either "doesn't work" or "painted into a 
corner", isn't it?

(In any case, this seems like a last resort... I bring it up not as a "proper" 
solution, but as a possible "emergency" way out, if we realize in 2-3 years 
that we locked some things down too soon.)

- Dave Sweeris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> 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 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
>> Convention and the Runtime, I don’t know enough about them to
>> comment. I’m really centring my discussion on the Standard Library.
>> 
>> If we look back at the evolution of the Standard Library for Swift 3,
>> they were many changes. And I’m personally very happy with the
>> thoughtful design that went into those. But they are still a few
>> gotchas, which is to be expected when so many changes are made at
>> once. But we only discover them once the thousands of Swift developers
>> start using those APIs.
>> 
>> I just worry that all the big changes that will come for Swift 4 won’t
>> have time to mature. Furthermore, it seems like several extra compiler
>> features which won’t happen in Swift 4 are really necessary to
>> simplify the Standard Library surface area. I’m specifically thinking
>> of type constraints on Existentials which would allow us to get rid of
>> all the Any* structs and replace them with typedefs. But I’m sure
>> there are more examples like those which are just waiting for the
>> generics to become powerful enough to express APIs more elegantly.
>> 
>> Perhaps someone from the Standard Library team can chime in to give us
>> their opinion on this topic.
> 
> I have had exactly the same worry for quite some time.  We're still
> waiting for many basic components of the generics system, and, if our
> experience with protocol extensions is any guide, before we have those
> features in hand, it will be impossible to anticipate the design changes
> we'd want to make to the standard library... and that cuts against the
> grain of *source* (to say nothing of ABI) stability.
> 
> So far I've been unable to form a mental model for what source and/or
> ABI stability actually means for our ability to make changes to the
> standard library in the future.  It's possible that we discover a
> workable path forward, but it's equally possible that we find ourselves
> painted into a corner.

I hope we can all agree that the last thing we want to do is get painted into a 
corner.  IMO we should be very sure that won’t happen before making a firm 
commitment to lock down ABI stability.

> 
> -- 
> -Dave
> 
> ___
> 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

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

[Dave Abrahams via swift-evolution]

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 for
> it. Concerning Data Layout, Type Metadata, Mangling, the Calling
> Convention and the Runtime, I don’t know enough about them to
> comment. I’m really centring my discussion on the Standard Library.
>
> If we look back at the evolution of the Standard Library for Swift 3,
> they were many changes. And I’m personally very happy with the
> thoughtful design that went into those. But they are still a few
> gotchas, which is to be expected when so many changes are made at
> once. But we only discover them once the thousands of Swift developers
> start using those APIs.
>
> I just worry that all the big changes that will come for Swift 4 won’t
> have time to mature. Furthermore, it seems like several extra compiler
> features which won’t happen in Swift 4 are really necessary to
> simplify the Standard Library surface area. I’m specifically thinking
> of type constraints on Existentials which would allow us to get rid of
> all the Any* structs and replace them with typedefs. But I’m sure
> there are more examples like those which are just waiting for the
> generics to become powerful enough to express APIs more elegantly.
>
> Perhaps someone from the Standard Library team can chime in to give us
> their opinion on this topic.

I have had exactly the same worry for quite some time.  We're still
waiting for many basic components of the generics system, and, if our
experience with protocol extensions is any guide, before we have those
features in hand, it will be impossible to anticipate the design changes
we'd want to make to the standard library... and that cuts against the
grain of *source* (to say nothing of ABI) stability.

So far I've been unable to form a mental model for what source and/or
ABI stability actually means for our ability to make changes to the
standard library in the future.  It's possible that we discover a
workable path forward, but it's equally possible that we find ourselves
painted into a corner.

-- 
-Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rick Mann via swift-evolution]

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 application, it's a working solution.

I'd really like to make sure Swift can be fully introspective (soon), but I 
don't know how easy it will be to add that after the ABI is locked down. Maybe 
I'm just being alarmist. I'd also like to see the ability to replace code at 
run time.

If all that is already accommodated by the current ABI, then I'm satisfied. But 
it seems like there's some concern about this, and I worry that locking down 
the ABI too early will make those additions MUCH harder in the future.

Thanks!

> On Jan 25, 2017, at 15:09 , Michael Ilseman  wrote:
> 
> 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 library and 
> runtime, rather than every app having to bundle their own copy. It’s also a 
> crucial piece of supporting 3rd party frameworks. There are also more subtle 
> benefits such as the de-coupling of developer tools that work with Swift 
> binaries (e.g. debuggers and profilers). Some of the tasks towards stability 
> are performance improvements we want to do anyways.
> 
> 
> 
>> On Jan 25, 2017, at 1:36 PM, Rick Mann via swift-evolution 
>>  wrote:
>> 
>> 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 
>> place. Not saying the reasons for the urgency aren't valid, I just don't 
>> know what they are.
>> 
>> Thanks!
>> 
>>> On Jan 25, 2017, at 08:44 , Freak Show via swift-evolution 
>>>  wrote:
>>> 
>>> 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  wrote:
 
 a lot of the information you'd need for many dynamic features is already 
 there, and planned to be stabilized as part of the ABI. We already emit 
 reflection data that describes the physical layouts of types, and once 
 those formats are stabilized, building a library that interprets the 
 metadata is additive (and could conceivably be done by a third party 
 independent of the standard library). There may not be metadata for 
 individual methods yet
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> -- 
>> Rick Mann
>> rm...@latencyzero.com
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 


-- 
Rick Mann
rm...@latencyzero.com


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> 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 Swift 4 might not be the best time for it. Concerning 
> Data Layout, Type Metadata, Mangling, the Calling Convention and the Runtime, 
> I don’t know enough about them to comment. I’m really centring my discussion 
> on the Standard Library.
> 
> If we look back at the evolution of the Standard Library for Swift 3, they 
> were many changes. And I’m personally very happy with the thoughtful design 
> that went into those. But they are still a few gotchas, which is to be 
> expected when so many changes are made at once. But we only discover them 
> once the thousands of Swift developers start using those APIs.
> 
> I just worry that all the big changes that will come for Swift 4 won’t have 
> time to mature. Furthermore, it seems like several extra compiler features 
> which won’t happen in Swift 4 are really necessary to simplify the Standard 
> Library surface area. I’m specifically thinking of type constraints on 
> Existentials which would allow us to get rid of all the Any* structs and 
> replace them with typedefs. But I’m sure there are more examples like those 
> which are just waiting for the generics to become powerful enough to express 
> APIs more elegantly.
> 
> Perhaps someone from the Standard Library team can chime in to give us their 
> opinion on this topic.

I definitely share the concern about locking down ABI before:

1) The language has the features required for the preferred standard library 
design.
2) The standard library team has had enough time and experience to be confident 
in the design of all aspects of the standard library which are frozen when ABI 
is frozen.

One of the things I have appreciated most about Swift is the commitment to 
making the right decisions for the long term.  It’s important that we don’t get 
locked into decisions in the standard library that don’t align with the most 
desirable long term design.

Locking down ABI when all foreseeable desirable changes are additive is one 
thing.  But doing so before we get there feels premature.

> 
> Thanks!
> David.
> 
>> On 26 Jan 2017, at 00:09, Michael Ilseman via swift-evolution 
>> > wrote:
>> 
>> 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 library and 
>> runtime, rather than every app having to bundle their own copy. It’s also a 
>> crucial piece of supporting 3rd party frameworks. There are also more subtle 
>> benefits such as the de-coupling of developer tools that work with Swift 
>> binaries (e.g. debuggers and profilers). Some of the tasks towards stability 
>> are performance improvements we want to do anyways.
>> 
>> 
>> 
>>> On Jan 25, 2017, at 1:36 PM, Rick Mann via swift-evolution 
>>> > wrote:
>>> 
>>> 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 
>>> place. Not saying the reasons for the urgency aren't valid, I just don't 
>>> know what they are.
>>> 
>>> Thanks!
>>> 
 On Jan 25, 2017, at 08:44 , Freak Show via swift-evolution 
 > wrote:
 
 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  > wrote:
> 
> a lot of the information you'd need for many dynamic features is already 
> there, and planned to be stabilized as part of the ABI. We already emit 
> reflection data that describes the physical layouts of types, and once 
> those formats are stabilized, building a library that interprets the 
> metadata is additive (and could conceivably be done by a third party 
> independent of the standard library). There may not be metadata for 
> individual methods yet
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 

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

[David Hart via swift-evolution]

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 Convention and the Runtime, I 
don’t know enough about them to comment. I’m really centring my discussion on 
the Standard Library.

If we look back at the evolution of the Standard Library for Swift 3, they were 
many changes. And I’m personally very happy with the thoughtful design that 
went into those. But they are still a few gotchas, which is to be expected when 
so many changes are made at once. But we only discover them once the thousands 
of Swift developers start using those APIs.

I just worry that all the big changes that will come for Swift 4 won’t have 
time to mature. Furthermore, it seems like several extra compiler features 
which won’t happen in Swift 4 are really necessary to simplify the Standard 
Library surface area. I’m specifically thinking of type constraints on 
Existentials which would allow us to get rid of all the Any* structs and 
replace them with typedefs. But I’m sure there are more examples like those 
which are just waiting for the generics to become powerful enough to express 
APIs more elegantly.

Perhaps someone from the Standard Library team can chime in to give us their 
opinion on this topic.

Thanks!
David.

> On 26 Jan 2017, at 00:09, Michael Ilseman via swift-evolution 
>  wrote:
> 
> 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 library and 
> runtime, rather than every app having to bundle their own copy. It’s also a 
> crucial piece of supporting 3rd party frameworks. There are also more subtle 
> benefits such as the de-coupling of developer tools that work with Swift 
> binaries (e.g. debuggers and profilers). Some of the tasks towards stability 
> are performance improvements we want to do anyways.
> 
> 
> 
>> On Jan 25, 2017, at 1:36 PM, Rick Mann via swift-evolution 
>> > wrote:
>> 
>> 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 
>> place. Not saying the reasons for the urgency aren't valid, I just don't 
>> know what they are.
>> 
>> Thanks!
>> 
>>> On Jan 25, 2017, at 08:44 , Freak Show via swift-evolution 
>>> > wrote:
>>> 
>>> 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 > wrote:
 
 a lot of the information you'd need for many dynamic features is already 
 there, and planned to be stabilized as part of the ABI. We already emit 
 reflection data that describes the physical layouts of types, and once 
 those formats are stabilized, building a library that interprets the 
 metadata is additive (and could conceivably be done by a third party 
 independent of the standard library). There may not be metadata for 
 individual methods yet
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> -- 
>> Rick Mann
>> rm...@latencyzero.com 
>> 
>> 
>> ___
>> 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Michael Ilseman via swift-evolution]

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 library and 
runtime, rather than every app having to bundle their own copy. It’s also a 
crucial piece of supporting 3rd party frameworks. There are also more subtle 
benefits such as the de-coupling of developer tools that work with Swift 
binaries (e.g. debuggers and profilers). Some of the tasks towards stability 
are performance improvements we want to do anyways.



> On Jan 25, 2017, at 1:36 PM, Rick Mann via swift-evolution 
>  wrote:
> 
> 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 place. 
> Not saying the reasons for the urgency aren't valid, I just don't know what 
> they are.
> 
> Thanks!
> 
>> On Jan 25, 2017, at 08:44 , Freak Show via swift-evolution 
>>  wrote:
>> 
>> 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  wrote:
>>> 
>>> a lot of the information you'd need for many dynamic features is already 
>>> there, and planned to be stabilized as part of the ABI. We already emit 
>>> reflection data that describes the physical layouts of types, and once 
>>> those formats are stabilized, building a library that interprets the 
>>> metadata is additive (and could conceivably be done by a third party 
>>> independent of the standard library). There may not be metadata for 
>>> individual methods yet
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 
> ___
> 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

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

[Rick Mann via swift-evolution]

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 place. Not saying the 
reasons for the urgency aren't valid, I just don't know what they are.

Thanks!

> On Jan 25, 2017, at 08:44 , Freak Show via swift-evolution 
>  wrote:
> 
> 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  wrote:
>> 
>> a lot of the information you'd need for many dynamic features is already 
>> there, and planned to be stabilized as part of the ABI. We already emit 
>> reflection data that describes the physical layouts of types, and once those 
>> formats are stabilized, building a library that interprets the metadata is 
>> additive (and could conceivably be done by a third party independent of the 
>> standard library). There may not be metadata for individual methods yet
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


-- 
Rick Mann
rm...@latencyzero.com


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ted kremenek via swift-evolution]

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 from the runtime to the 
Standard Library.  As Michael Ilseman said he plans on sending out a manifesto 
shortly (possibly today) that includes a bunch of the scoping information for 
ABI stability.  We also plan on having a dashboard up (probably on swift.org) 
that will allow the community to get a holistic view of the work on ABI 
stability and see the progress being made toward that goal.  With that 
information we (the entire community) can make informed decisions on the 
priorities of specific ABI stability tasks and for Swift in general, and the 
relative tradeoffs being made.  As Joe Groff said elsewhere in this thread some 
aspects of ABI are additive, and thus can be added later.  When scoping ABI 
stability, we are trying to assess those kinds of lateral tradeoffs.

But as you point out, a lot of decisions get locked in once we have ABI 
stability.  As part of that, we'll have some public discussion soon on when to 
open up "phase 2" (per Chris's email over the summer about goals for Swift 4) 
and what it means for Swift 4.  I think a key goal for "phase 2" is to front 
load important design changes to Swift that may have implications on ABI.

Thank you for bringing up this topic.  Let's continue this general discussion 
about ABI stability and what it means for prioritizing specific tasks for Swift 
once Michael has his manifesto out.

Ted

> On Jan 23, 2017, at 10:40 PM, David Hart via swift-evolution 
>  wrote:
> 
> Hello swift-evolution,
> 
> ABI stability is an important feature which many Swift users are looking 
> forward to. If I understand it correctly, once it’s here, the Standard 
> Library becomes part of that ABI and only additive and backwards-compatible 
> changes can be done. Seeing how we are still heavily modifying the Standard 
> Library this year (Strings), wouldn’t it be wiser to let those changes simmer 
> under the scrutiny of the broader community of Swift users for a year before 
> we make it into the ABI?
> 
> ABI compatibility is important. Some projects need it, but I think that most 
> projects (most Apple platform third-party applications) would only mildly 
> benefit from it. But I want to make sure the Standard Library has had enough 
> time to mature before we set it in stone.
> 
> Regards,
> David.
> ___
> 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

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

[Freak Show via swift-evolution]

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  wrote:
> 
> a lot of the information you'd need for many dynamic features is already 
> there, and planned to be stabilized as part of the ABI. We already emit 
> reflection data that describes the physical layouts of types, and once those 
> formats are stabilized, building a library that interprets the metadata is 
> additive (and could conceivably be done by a third party independent of the 
> standard library). There may not be metadata for individual methods yet

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joe Groff via swift-evolution]

> 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 features need to come.  They will impact everything.  My 
> personal ideal is a language that smoothly transitions from fully dynamic to 
> fully static without a lot of fuss. 

There will inevitably be features at some point that require added runtime 
support that won't backward-deploy to older runtime versions. However, a lot of 
the information you'd need for many dynamic features is already there, and 
planned to be stabilized as part of the ABI. We already emit reflection data 
that describes the physical layouts of types, and once those formats are 
stabilized, building a library that interprets the metadata is additive (and 
could conceivably be done by a third party independent of the standard 
library). There may not be metadata for individual methods yet, but there is 
tracking of protocol conformances, and once the standard library protocols are 
stabilized, someone could make assumptions about the protocol witness table 
layouts for those protocols to find particular method implementations even if 
you're running on an older standard library without the full method metadata we 
might support one day.

-Joe
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Freak Show via swift-evolution]

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 dynamic to 
fully static without a lot of fuss. 



> On Jan 24, 2017, at 11:45, Rahul Malik via swift-evolution 
>  wrote:
> 
> 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 from my perspective as someone involved in the 
> decision to adopt Swift in production at work.
> 
> ABI Stability
> The reality is that stability in the ABI is important for a number of 
> developers and companies considering adopting or that have already adopted 
> Swift. Shipping the runtime increases the binary size of every app that ships 
> with it and becomes a barrier in user acquisition due to the increased app 
> size. If I'm not mistaken this issue multiplies as you add extensions to your 
> application since they all bundle the runtime separately. Due to these 
> issues, ABI Stability is one of the leading reasons we have not adopted Swift 
> in our flagship app.
> 
> API Stability
> This I would consider just as important as the ABI stability. Changing APIs 
> provides a lot of churn on developers that manage large codebases and I've 
> often heard of issues using the Swift migrator at scale which doesn't help. 
> I'd like to see a less drastic approach like Jonathan is suggesting where we 
> have clear indication of APIs that might change or at least allowing one 
> minor release where an API will warn if it's used but is still available to 
> allow developers time to migrate.
> 
> Right now I think it's important to keep ABI stability as a core tenant of 
> any proposal and acknowledge that we need to just flag how proposals will 
> affect ABI stability. This seems inline with our stance on the development of 
> a Rust-inspired `Memory Ownership Model`: "While a full memory ownership 
> model is likely too large for Swift 4 stage 1, we need a comprehensive design 
> to understand how it will change the ABI."
> 
> On Tue, Jan 24, 2017 at 3:16 AM, Georgios Moschovitis via swift-evolution 
> > wrote:
> > 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
> 
> ___
> 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rahul Malik via swift-evolution]

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 from my perspective as someone involved in the
decision to adopt Swift in production at work.

*ABI Stability*
The reality is that stability in the ABI is important for a number of
developers and companies considering adopting or that have already adopted
Swift. Shipping the runtime increases the binary size of every app that
ships with it and becomes a barrier in user acquisition due to the
increased app size. If I'm not mistaken this issue multiplies as you add
extensions to your application since they all bundle the runtime
separately. Due to these issues, ABI Stability is one of the leading
reasons we have not adopted Swift in our flagship app.

*API Stability*
This I would consider just as important as the ABI stability. Changing APIs
provides a lot of churn on developers that manage large codebases and I've
often heard of issues using the Swift migrator at scale which doesn't help.
I'd like to see a less drastic approach like Jonathan is suggesting where
we have clear indication of APIs that might change or at least allowing one
minor release where an API will warn if it's used but is still available to
allow developers time to migrate.

Right now I think it's important to keep ABI stability as a core tenant of
any proposal and acknowledge that we need to just flag how proposals will
affect ABI stability. This seems inline with our stance on the development
of a Rust-inspired `Memory Ownership Model`: "While a full memory ownership
model is likely too large for Swift 4 stage 1, we need a comprehensive
design to understand how it will change the ABI."

On Tue, Jan 24, 2017 at 3:16 AM, Georgios Moschovitis via swift-evolution <
swift-evolution@swift.org> wrote:

> > 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
>
> ___
> 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

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

[Michael Ilseman via swift-evolution]

> 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 clarify this very soon with a lot more information.

> 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 have several versions of the stdlib installed, and no 
> one talks about API stability (which is great as well — but a superior API 
> imho is better ;-)
> ABI is very low level and affects the junction of software and hardware 
> (which bits are put into which location when a function call happens, 
> utilisation of registers…).
> 

While ABI is low-level, at least in the sense that binary interfaces are 
low-level, a language’s ABI is actually pretty cross-cutting. All of a 
languages features and semantics that may be exposed across ABI boundaries need 
a place in the languages ABI, and Swift has a lot of features.

> 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 ;-)
> 

One subtlety that’s not always brought up is that when we talk about 
stabilizing the Swift ABI, what is really important is stabilizing the 
interface of libSwiftCore. libSwiftCore includes the standard library and 
language runtime, so in a hand-wavy sense the stdlib’s API is part of 
libSwiftCore's ABI. Again, much more on this soon.


> - Tino
> ___
> 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

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

[Georgios Moschovitis via swift-evolution]

> 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jonathan Hull via swift-evolution]

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 can start to build things that we 
know will last.  I have ObjC programs which are years old and still work fine, 
but I have to update my Swift projects every 6 months to get them to compile.

What I would like to see instead of these deadlines for the whole language is 
for parts of the language to be stabilized over time.  That is each part of the 
language and standard library would be marked one of the following:

• Unstable - This is in active development or is expected to have major changes 
soon. You can build things with it, but expect to have to update that code.
• Pre-stable - We have a design that we think works, and only expect minor 
tweaks, but we need to see how it works in the wild for a while before we know 
it is correct.
• Stable - This is a proven design that we feel comfortable baking in to the 
language. It has been tested in real world code and we are confident it won’t 
need to change in ways that break backward/forward compatibility.

Then each API would have this listed in the documentation.  I think that the 
most we should start things at right now is “Pre-stable” given the pending 
updates from generics, concurrency, etc… that will affect wide swaths of the 
language.

For example, the new Arithmetic stuff would be Pre-stable because we think it 
will be our design, but we may have small tweaks once we see how it interacts 
with other API in the real world.  Then if it works as well as we think it 
will, we can move it to Stable in the following release.  String would be 
unstable right now due to the planned upgrades.

Breaking things up like this allows us to focus and take time on each part… 
baking things in as we are confident that they are the right choice.  It also 
allows the developer community to plan accordingly and predict which parts of 
their code will need to be updated.  I kind of feel like we are lying to 
ourselves with the current system.

Thanks,
Jon


> On Jan 23, 2017, at 10:40 PM, David Hart via swift-evolution 
>  wrote:
> 
> Hello swift-evolution,
> 
> ABI stability is an important feature which many Swift users are looking 
> forward to. If I understand it correctly, once it’s here, the Standard 
> Library becomes part of that ABI and only additive and backwards-compatible 
> changes can be done. Seeing how we are still heavily modifying the Standard 
> Library this year (Strings), wouldn’t it be wiser to let those changes simmer 
> under the scrutiny of the broader community of Swift users for a year before 
> we make it into the ABI?
> 
> ABI compatibility is important. Some projects need it, but I think that most 
> projects (most Apple platform third-party applications) would only mildly 
> benefit from it. But I want to make sure the Standard Library has had enough 
> time to mature before we set it in stone.
> 
> Regards,
> David.
> ___
> 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

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

[Tino Heth via swift-evolution]

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 have several versions of the stdlib installed, and no 
one talks about API stability (which is great as well — but a superior API imho 
is better ;-)
ABI is very low level and affects the junction of software and hardware (which 
bits are put into which location when a function call happens, utilisation of 
registers…).

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 ;-)

- Tino
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution