<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">On Jul 28, 2014, at 17:10, Ryosuke Niwa <<a href="mailto:rniwa@webkit.org" class="">rniwa@webkit.org</a>> wrote:</div><div class=""><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class="">On Mon, Jul 28, 2014 at 12:47 PM, David Farler <span dir="ltr" class=""><<a href="mailto:dfarler@apple.com" target="_blank" class="">dfarler@apple.com</a>></span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Hello all,<div class=""><br class=""></div>
<div class="">I have the following bug to help build out support for layout tests in the iOS Simulator.</div><div class=""><br class=""></div><div class="">iOS Simulator LayoutTestRelay</div><div class=""><a href="https://bugs.webkit.org/show_bug.cgi?id=135269" target="_blank" class="">https://bugs.webkit.org/show_bug.cgi?id=135269</a></div>
<div class=""><br class=""></div><div class="">I'd like to include this as a new tool written in Swift.</div><div class=""><br class=""></div><div class="">Why I think it's fine in this case:</div><div class="">- This tool is specific to the iOS and OS X platforms</div><div class="">
- Swift is a fully supported, albeit new, language starting in Xcode 6.</div>
<div class="">- Swift is probably the best way to get Objective-C bridging "for free" in the long term</div><div class="">- Swift supports script-like "immediate mode" with good JIT-compiled performance</div><div class=""><div class="">
- The tool's size and scope is sufficiently small with no complex or WebKit-specific dependencies</div>
</div></div></blockquote><div class=""><br class=""></div><div class="">There is a precedence of WebKit rejecting the use of new programming languages in the past:</div><div class=""><a href="https://lists.webkit.org/pipermail/webkit-dev/2011-December/018837.html" class="">https://lists.webkit.org/pipermail/webkit-dev/2011-December/018837.html</a><br class=""></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Precedence drives opinions of law, for which reinterpretations are considered to be an unfortunate correction. I don’t think it should be invoked to hamper creativity or reject something “new”. Still, the main difference to that case is that Swift is not an unsupported third-party language, it won’t require installation of new software, and it’s not for cross-platform automation.</div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">
</div><div class="">In particular see Maciej's response in <a href="https://lists.webkit.org/pipermail/webkit-dev/2011-December/018865.html" class="">https://lists.webkit.org/pipermail/webkit-dev/2011-December/018865.html</a>.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">From the second e-mail:</div><div class=""><br class=""></div><div class="">"<span style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">In conclusion, I think we should be very hesitant to introduce new languages for tools unless there are massive benefits that cannot be achieved with any of the languages that the WebKit project already uses.</span>”</div><div class=""><br class=""></div><div class="">I myself am hesitant, hence the e-mail, but I think there is more to the picture here regarding the two languages which I outline below.</div><div class=""><br class=""></div><div class="">For everyday automation tasks, I agree that we should continue to converge on Python because of its coverage across platforms, one-way-to-do-it-ness, strong style guidelines, large standard library, popularity, easy to learn, etc. It’s one of my goals to do just that and create a strong, unified, hackable, well-documented tools platform. I wouldn't advocate that automation be written in Swift.</div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">I understand that its freshness and continual evolution means that we won't reviewer support relative to our C family languages. I would argue that it will be difficult to subjectively tell when the time is "right", that a good way to solve that is to start using the language itself, and take an incremental approach to crafting the Swift story in WebKit. Using it for some simple tools is a good place to start.</div>
</div></blockquote><div class=""><br class=""></div><div class="">Could you clarify what the advantage of using Swift is? Personally, I'm not interested in learning a yet another platform-specific language to hack on WebKit.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Sure. There is a book, website, blog and conference touting the advantages of Swift. :) I’m not going to fall into the trap of trying assume responsibility for articulating what has already been said there because I’ll surely not do as good of a job, but I’ll provide some enticing bullets below. If you took the time to learn and use it, I think you would appreciate the advantages and disadvantages more and would be excited for its future. I am.</div><div class=""><br class=""></div><div class="">For this project, I think it’s a valid exploration for code that would already have to use platform-specific Objective-C. Of course, I wouldn’t presume to argue that all of OS X and iOS WebKit code should move to Swift at this point. However, I reject thinking that leads one to only consider a new possibility when the current situation is unbearable or even painfully obvious.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">
<div class="">I'm not saying that Swift is a bad language or anything but I don't want to start having people writing random programming languages such as Haskell, Scala, Go, Rust, etc... deemed hip/cool at the time to create new tools in WebKit.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Of course. The main difference is that I don’t deem it hip; it’s a fully supported, productized language that ships with Xcode and it’s only going to grow in use on OS X and iOS. Even so, that Swift is hip and exciting shouldn’t be ignored. Developing WebKit should be as exciting to hack as much as it is an exemplary web framework too, as both motivations work together to make it better.</div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">
<div class="">It would increase the entry barrier of working on those tools even if they were specific to one platform.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">It is something new to learn. Is it a <i class="">barrier?</i> I don’t think so. I think it’s an opportunity. We assumed Objective-C in the first place because it was <i class="">the only </i>way to write apps and frameworks on OS X and iOS. Now that's no longer true and, while both languages are supported, if someone didn’t think it was the way forward, I don’t think it would exist in the first place since Objective-C does a pretty good job already and it could’ve been extended incrementally. That’s my perspective. Obviously it’s not going anywhere anytime soon but, if Objective-C were deprecated in the future, and we suddenly decided we needed reviewers who knew Swift, where would we look? </div><div class=""><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">e.g. what should GTK+/EFL contributors do if they wanted to modify the way webkitpy works and needed to make changes to your tool? Or do you think such a scenario is extremely unlikely?</div></div></div></blockquote><div class=""><br class=""></div><div class="">Given the pace of webkitpy development … :)</div><div class=""><br class=""></div><div class="">I do think it’s unlikely. It’s just a proxy to a simulator app's standard file descriptors which are only accessible indirectly and I’m happy to say that it somewhat pays for its debt by removing lots more platform-specific code than it creates (<a href="https://bugs.webkit.org/show_bug.cgi?id=135374" class="">https://bugs.webkit.org/show_bug.cgi?id=135374</a> and <a href="https://bugs.webkit.org/show_bug.cgi?id=135271" class="">https://bugs.webkit.org/show_bug.cgi?id=135271</a>). It doesn’t exist to automate but make it possible to run layout tests on the simulator with the current tools. Essentially, it pretends to be DRT/WKTR, so it has the same I/O behavior requirements as those tools.</div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">
<div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">The larger discussion of using Swift in larger AOT-compiled contexts but is probably going to happen in this thread anyway, so let's have it:</div>
<div class=""><br class=""></div><div class=""><b class="">What of future use of Swift in WebKit?</b></div></div></blockquote><div class=""><br class=""></div><div class="">I would really like to know why we should use Swift in WebKit at all in the current stage?</div><div class=""><br class=""></div>
<div class="">- R. Niwa</div></div></div></div></blockquote><br class=""><div class="">Fine, twist my arm. :) In comparison to Objective-C, I don’t think it’s a stretch to think of these as major achievements:</div><div class=""><br class=""></div><div class="">- Modern type inference (although it could’ve gone a few steps further, IMO)</div><div class="">- Static types</div><div class="">- Sum types</div><div class="">- Enforced optional/maybe type</div><div class="">- Promotion of immutability</div><div class="">- Safer usage or downright omission of pointers</div><div class="">- Better numeric type conversion (IMO)</div><div class="">- Enforced initialization of objects</div><div class="">- Nice Unicode string primitives</div><div class="">- Low resistance to reasonable functional programming patterns</div><div class="">- Generics with constraints</div><div class="">- Pretty fast</div><div class="">- Terse syntax</div><div class="">- String interpolation with expressions</div><div class="">- No class prefixes needed</div><div class=""><br class=""></div><div class="">Reasons to not use it at the current stage:</div><div class=""><br class=""></div><div class="">- Needs more standard library features (IMO)</div><div class="">- Possible ABI changes</div><div class="">- Possible syntax changes</div><div class="">- No Swift++, have to use C or Objective-C call sites</div><div class=""><br class=""></div><div class="">David</div></body></html>