<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Another thing I think we are missing here is versioning the function bodies themselves. For example (ignore syntax) suppose we have</div><div class=""><br class=""></div></div><div class=""> </div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class="">public (1.0) func removeTheCacheFiles() {</div></div><div class=""><div class=""> os.rmdir("/path/to/cache")</div></div><div class=""><div class="">}</div></div></blockquote><div class=""><div class=""><br class=""></div><div class="">We may evolve this function in two orthogonal ways:</div><div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">We may develop other cache files as our program grows</li><li class="">We may discover that we forgot to check if the user is allowed by the security policy to remove the cache files.</li></ol><div class=""><br class=""></div></div><div class="">Therefore we may evolve this function as follows (again, I use pretend syntax):</div><div class=""><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><div class="">public (1.0) func removeTheCacheFiles() {</div></div></div><div class=""><div class=""><div class=""> precondition(userIsAuthorized()) //this change is backported to 1.0</div></div></div><div class=""><div class=""><div class=""> os.rmdir("/path/to/cache")</div></div></div><div class=""><div class=""><div class=""> #if 1.1 { //this code only for 1.1-era callers</div></div></div><div class=""><div class=""><div class=""> os.rmdir("/path/to/cache2")</div></div></div><div class=""><div class=""><div class=""> }</div></div></div><div class=""><div class=""><div class="">}</div></div></div></blockquote><div class=""><div class=""><br class=""></div><div class="">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 <a href="https://www.debian.org/security/faq#oldversion" class="">Debian Security FAQ</a>, where people spend a huge amount of time backporting security fixes to old versions.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><br class=""></div><div>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.)</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>Jordan</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>P.P.S. I'll respond to the inlineable thread tomorrow.</div><br class=""></body></html>