What is the "plan" for ObjC on non-Darwin platforms?


(David Zarzycki) #1

Recently I found myself writing the following in a test case:

+// -- On Darwin, the first 4 GiB are unmapped: 0x7ffffffc
+// -- Otherwise, one can only assume the first page (4 KiB) is unmapped: 0xffd
+// CHECK-ios:       i8* inttoptr (i64 2147483644 to i8*)
+// CHECK-macosx:    i8* inttoptr (i64 2147483644 to i8*)
+// CHECK-watchos:   i8* inttoptr (i64 2147483644 to i8*)
+// CHECK-darwin:    i8* inttoptr (i64 2147483644 to i8*)
+// CHECK-objc-linux-gnu:   i8* inttoptr (i64 2045 to i8*)
+// CHECK-native-linux-gnu: i8* inttoptr (i64 4093 to i8*)
+// CHECK-objc-windows:     i8* inttoptr (i64 2045 to i8*)
+// CHECK-native-windows:   i8* inttoptr (i64 4093 to i8*)

This feels needlessly complicated given that ObjC on non-Darwin platforms is "niche" to nonexistent, and given that disabling ObjC interoperability on Darwin means that the vast majority of Apple's frameworks become unusable.

What is the "plan" for ObjC support on non-Darwin platforms? Normally I don't like feature conflation, but in this case, conflating "is Darwin" with "supports ObjC" seems quite practical.

Dave


Windows Nightlies
(Lars Sonchocky-Helldorf) #2

Well, Swift could support GNUstep, but I don't know if this is wanted.


(David Zarzycki) #3

With all due respect to GNUStep, I think planning around it is unwise for the following reasons:

  1. Based on GitHub traffic/analytics, one can have a reasonable debates about whether the project is still under active development. (It looks more like infrequent maintenance to me.)
  2. One could also have a reasonable debate about the project's relevancy given that NeXTSTEP "died" more than 20 years ago when NeXT was acquired by Apple.
  3. GNUStep is vastly outclassed by GNOME and KDE, which are far more mature and more feature rich.

(Chris Lattner) #4

I don't speak for Apple or anyone else, but I'd strongly prefer to never support GNU Step in Swift. It would introduce a massive amount of complexity into the compiler and runtime (far more than in Clang) and there is no user base for it.


(David Zarzycki) #5

Hi @Chris_Lattner3,

Do you think people would be open to replacing ObjC interop logic within the compiler with "is Darwin" checks? This would let us remove -enable-objc-interop and -disable-objc-interop from the frontend.

Dave


(Joe Groff) #6

There are no plans to support other ObjC runtimes, at least from us. I would keep the flag disjoint from "is Darwin", though, since a non-ObjC-compatible Swift runtime on Darwin, although not maintained at this time, may be useful for things like server-side development on Mac hosts, in order to get closer behavior to Swift on other platforms.


(Félix Fischer) #7

I'd agree. That kind of system in Darwin will prove very useful for server devs :slight_smile:


(David Zarzycki) #8

Hi @Joe_Groff,

Okay, What about a diagnostic error if someone tries to enable objc interoperability on non-Darwin platforms?

Dave


(Jordan Rose) #9

I know @compnerd has been finding it very useful to be able to run tests for -enable-objc-interop on non-Darwin platforms, even if you can't actually execute anything. Makes it easier to tell if you've broken some ObjC thing. But we could probably invent some lit substitution like %darwin-target-triple that expands to the current target on Apple platforms and a dummy macOS on non-Apple platforms.


(Joe Groff) #10

Yeah, there's no reason you shouldn't be able to build a compiler targeting Darwin with ObjC interop on non-Darwin platforms.


(David Zarzycki) #11

I also find it useful to have two RUN lines per test, one with ObjC enabled and one without. And yes, something like %darwin-target-triple would be preferable over -enable-objc-interop. Would people be open to %darwin-target-triple replacing -enable-objc-interop in the test suite?


(Saleem Abdulrasool) #12

I totally agree that it is more convenient to have two tests (w/wo objc) if testing ObjC specific behavior. Having a substitution is reasonable. However, there are differences in certain cases (e.g. section names) that are material to some IRGen tests. As long as those things are taken care of, I think that using the substitution is a great idea.


(Nobody1707) #13

What about Microsoft's Objective-C runtime? Were there any plans to support it on Windows?


(John McCall) #14

Unlike Chris, I'm not opposed to supporting ObjC interop on other platforms if somebody is willing to contribute and maintain that. I do think that we shouldn't try to enable ObjC interop in the default target ABI anywhere except Darwin, though; enabling ObjC interoperation with (say) GNUStep would be a variant, incompatible ABI.


(Félix Fischer) #15

Wait.

Should we be pursuing ObjC interop? Swift should at some point supersede ObjC in all of its uses. We also know that the current ObjC interop for Darwin required a lot of people-hours to be invested in order to exist.

Unless there's something urgent and precious that we can get in other platforms from interacting with an ObjC runtime, I'd say let's not. There are already urgent and pressing issues outside of this topic, like the corelibs-foundation project and the cross-platform Swift tooling.


(John McCall) #16

We already have pursued ObjC interop. It was a basic requirement of writing a programming language that works well with the Darwin platform APIs. And while it was, and continues to be, a huge project, the vast majority of that work is not Darwin-specific, and the parts that are are fairly self-contained. A few branches in IRGen and #ifs in the runtime are not a major burden.

Also, I'm not suggesting that anybody should be reassigned from their current tasks to work on GNUStep compatibility; I'm saying that if someone created a PR that added compatibility for other ObjC runtimes, that is a reasonable contribution that I would be willing to accept, provided they proved willing to maintain it.


(Félix Fischer) #17

Ahh, my bad. Now I get you. Yeah, that'd be reasonable...

But to bring Chris's concerns back, I'd say that it should keep the complexity burden over the compiler codebase at a minimum. Given that, yeah, why not :D


(John McCall) #18

Absolutely. If there was an ObjC runtime with invasively different interoperation requirements — e.g. if it didn't use reference-counting — then it would need to meet a much higher bar for us to consider supporting it.


(Gregory Casamento) #19

Your response here illustrates a couple of things:

First. The project is and has been under active development for almost 20 years

Second. If you had even taken a cursory look at the codebase you would clearly see that there are Cocoa classes implemented in it.

I really hate it when people make unfounded and, worse, inaccurate statements about the project I have been the lead of for the last 8 years and part of almost since it’s inception.

Please get off this “GNUstep is nextstep” crap because it more closely follows cocoa. It is easy for people to read your message and believe what you’re saying than to actually take a look at the project itself!


(Gregory Casamento) #20

Then I’m glad your pet language is open source because I will fork it if necessary in order to introduce support.

Fortunately Swift has yet to take hold in the macOS development community which is the main set of developers that GNUstep is targeting.