Got it. Seems like, in this case, this is the best (i.e. only) way to do things. For the general case, I’m not sure what the current “no new language” policy states, but I would favor some kind of amendment that said “…unless it’s the only way to do things because you’re calling out to something in that language, and in that case please try to make the usage as minimal as reasonably possible”. Thanks, Geoff
On Jun 9, 2021, at 11:37 AM, Jer Noble <jer.noble@apple.com> wrote:
On Jun 9, 2021, at 11:31 AM, Geoff Garen <ggaren@apple.com> wrote:
In this specific case
What is the API we’re trying to call into?
This is calling into the GroupActivities.framework API which was announced at WWDC this week.
Is using Swift the only way to call into it?
This was true at the time we wrote it, as GroupActivities required using the Combine framework, which does not have an Objective-C API. I'm learning that this may not be the case in the future. If GroupActivities is modified to not require Combine, I will gladly remove the .swift.
Is there any way to reduce the use of Swift to only the calls into it, and not the surrounding objects (which all seem to be marked @objc anyway)?
The surrounding objects have to be written in Swift (in order to call Swift APIs), but callable from Objective-C/++, which is why they're marked as @objc. I believe that they are as minimal as I can make them.
-Jer
Thanks, Geoff
On Jun 8, 2021, at 4:27 PM, Sam Weinig via webkit-dev <webkit-dev@lists.webkit.org> wrote:
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