> On Jul 28, 2014, at 2:57 PM, Geoffrey Garen <[email protected]> wrote: > > Two concerns that came up today: > > (1) A binary built with Swift today can only run if the client individual has > the same version of Xcode installed. (Is this true?)
Not sure if it's true (I haven't hit this) but I wouldn't be surprised if there are ABI-breaking changes across beta releases, especially regarding the underlying bridging to the Objective-C runtime. I don't know how often that will happen long term. I should mention though that LayoutTestRelay will inherently have a dependency on CoreSimulator.framework inside the Xcode.app bundle, so if LTR is built against a particular location, it will have to either be rebuilt or have its rpath adjusted if using the common /Applications/Xcode.app location, regardless of the language. > (2) The language and implementation are still changing in breaking ways. Yep, I concede to this. My only question in response is whether it's valuable to observe those changes in a project like this or even to use a project like this to investigate other points of discussion, like: - Is there one Swift coding style? If not, what's ours? - What do we need to implement in spite of, or for lack of, a standard library feature? Or, just save all that for a rainy day, I suppose. David > > Geoff > >> On Jul 28, 2014, at 2:21 PM, Sam Weinig <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi David, >> >> I think it is a bit too early to start using Swift in WebKit, especially >> since the language is still evolving. Eventually, I think we should start >> using it, but I’d like for it to settle a bit before we do. >> >> - Sam >> >> >> On Jul 28, 2014, at 12:47 PM, David Farler <[email protected] >> <mailto:[email protected]>> wrote: >> >>> Hello all, >>> >>> I have the following bug to help build out support for layout tests in the >>> iOS Simulator. >>> >>> iOS Simulator LayoutTestRelay >>> https://bugs.webkit.org/show_bug.cgi?id=135269 >>> <https://bugs.webkit.org/show_bug.cgi?id=135269> >>> >>> I'd like to include this as a new tool written in Swift. >>> >>> Why I think it's fine in this case: >>> - This tool is specific to the iOS and OS X platforms >>> - Swift is a fully supported, albeit new, language starting in Xcode 6. >>> - Swift is probably the best way to get Objective-C bridging "for free" in >>> the long term >>> - Swift supports script-like "immediate mode" with good JIT-compiled >>> performance >>> - The tool's size and scope is sufficiently small with no complex or >>> WebKit-specific dependencies >>> >>> 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. >>> >>> 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: >>> >>> What of future use of Swift in WebKit? >>> >>> Regards, >>> David Farler >>> _______________________________________________ >>> webkit-dev mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>> <https://lists.webkit.org/mailman/listinfo/webkit-dev> >> >> _______________________________________________ >> webkit-dev mailing list >> [email protected] <mailto:[email protected]> >> https://lists.webkit.org/mailman/listinfo/webkit-dev >
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
