Hi Jer, I think it sounds like a reasonable rule to allow Swift for bridging purposes only, with the caveat that we should prefer Objective-C/C where it can be used.
The one other place that Swift seems reasonable for WebKit is in the definition and refinement of Swift bindings to WebKit’s public API. That is to say, for the time being, we should avoid Swift in tools and core functionality. Thanks for bringing this up on the list. - Sam > On Jun 8, 2021, at 3:57 PM, Jer Noble via webkit-dev > <webkit-dev@lists.webkit.org> wrote: > > Hi all! > > We're working on some new features that currently use APIs exposed through > Swift. We have not yet approved writing and committing WebKit code in Swift, > given runtime, library, and just plain mental overhead that comes with adding > a new language to the project. But I'd argue that doing so for the purpose of > allowing existing C++ code to call into Swift APIs is probably not terrible. > > Should we relax our "no new language" policy, only for the purposes of > allowing our core language code to call into APIs in Swift? > > (ref: https://bugs.webkit.org/show_bug.cgi?id=226757) > > Thanks, and look forward to hearing from everyone, > > -Jer > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
