[swift-evolution] [RFC] "Library Evolution Support in Swift ('Resilience')"

[Jordan Rose]

> Another thing I think we are missing here is versioning the function bodies themselves.  For example (ignore syntax) suppose we have
> 
>             
> public (1.0) func removeTheCacheFiles() {
>       os.rmdir("/path/to/cache")
> }
> 
> We may evolve this function in two orthogonal ways:
> 
> We may develop other cache files as our program grows
> We may discover that we forgot to check if the user is allowed by the security policy to remove the cache files.
> 
> Therefore we may evolve this function as follows (again, I use pretend syntax):
> 
> public (1.0) func removeTheCacheFiles() {
>       precondition(userIsAuthorized()) //this change is backported to 1.0
>       os.rmdir("/path/to/cache")
>       #if 1.1 { //this code only for 1.1-era callers
>         os.rmdir("/path/to/cache2")
>       }
> }
> 
> It is important to support this case because very often in server land, certain clients only want to pick up the security fixes (and not, say, new features).  See e.g. this Debian Security FAQ <https://www.debian.org/security/faq#oldversion>, where people spend a huge amount of time backporting security fixes to old versions.
> 
> I realize this is not at all the practice in "consumer-grade" applications like iOS/OSX/etc., but it is very entrenched in serverland, and I really think there is value in supporting this at the language level for those people who work in that world.
> 
> I think the implementation of this is just to compile all possibilities and just let the client pick the implementation based on the API version.  I realize this may result in larger binaries, but only when the feature is used, so it's opt-in.

Hm, this is interesting. Apple does use a form of this, called "linked-on-or-after" checks; if you compile your code against the latest version of the OS, you're opting into new behavior. That said, it's problematic if two of your dependencies disagree on which version of the library they want. (There are a few different possible answers there, all with trade-offs.)

I think we should treat this as an additive feature; the worst that happens is you can't do this kind of multi-compilation right away.

Jordan

P.S. I want to note that most of the "innovative" ideas here are already in the Swift 2 OS availability model; main credit for this goes to Devin Coughlin.

P.P.S. I'll respond to the inlineable thread tomorrow.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160210/b1a5c39c/attachment.html>