add Apple predefined version to cover OSX, iOS, TVOS, WatchOS and Vis…

[WalterBright]

…ionOS

The Apple operating systems OSX, iOS, TVOS, WatchOS and VisionOS are close enough that we see various sequences of the following code repeated in druntime:

version (OSX)
    version = Darwin;
else version (iOS)
    version = Darwin;
else version (TVOS)
    version = Darwin;
else version (WatchOS)
    version = Darwin;

Like Windows covers both Win32 and Win64, Apple will cover those versions.

[dlang-bot]

Thanks for your pull request, @WalterBright!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#21471"

[thewilsonator]

You will need to update druntime/test/importc_compare/src/importc_compare.d which does

version (OSX)
    version = Apple;
version (iOS)
    version = Apple;
version (TVOS)
    version = Apple;
version (WatchOS)
    version = Apple;

which will now fail because it tries to define a redefined version.

Please also open a corresponding Spec PR to add the version.

Please also update the verion predefined tests compiler/test/fail_compilation/reserved_version.d and compiler/test/fail_compilation/reserved_version_switch.d for this predefined version.

[LunaTheFoxgirl]

I propose adding 2 new version definitions: AppleOS (already used in D packages) as well as AppleMobileOS to cover OSes derived from iOS, such as iPadOS, watchOS and tvOS.

iOS derived platforms have their own set of (higher level) APIs which are incompatible with the desktop and visionOS APIs. (Eg. AppKit vs UIKit)

[WalterBright]

dlang/dlang.org#4253

implemented requested changes

[WalterBright]

@LunaTheFoxgirl Thank you for your suggestions! Apple is a bit shorter than AppleOS. Is there a constituency for AppleMobileOS? I don't see it in druntime. Maybe MobileOS would be more consistent with the other names for Apple OS's?

[adamdruppe]

AppleMobile (or whatever you call it) is relevant as soon as you move beyond the basics of druntime (the basics are the same as Apple/Darwin but then the event loop and ui stuff is different). I agree it'd be useful, right now libraries there do a similar dance to druntime.

For the redefinition error, you might say assigning a predefined version is a no-op. So if you're on Windows and do version=Windows; it just silently proceeds, whereas when not on Windows that'd be a compile failure. This way you can predefined something that's already in use without breaking all the code that touches it.

[adamdruppe]

interesting that this is there, yeah i do kinda recall the old days of D when it used this instead of OSX or whatever, but i forgot all about it.

[LunaTheFoxgirl]

@LunaTheFoxgirl Thank you for your suggestions! Apple is a bit shorter than AppleOS. Is there a constituency for AppleMobileOS? I don't see it in druntime. Maybe MobileOS would be more consistent with the other names for Apple OS's?

it'll be less useful in druntime and more useful in graphical apps; the low level stuff is mostly the same; where it differs is in the APIs for stuff like opening a window, drawing widgets, opening file selection dialogs, etc. libraries targeting iOS derivatives as well as macOS right now have to do the same as druntime with the Darwin thing; just with a subset of Apple platforms that target their mobile APIs.

Eg. If you want to draw with Metal onto a view currently you'd need to implement the NSView protocol on macOS, and UIView on iOS, iPadOS, watchOS and tvOS. The protocols are not compatible so you'd need to have a version that only is compiled and linked on macOS, and one only compiled on the iOS derived platforms.

visionOS counts as a bit of its own platform since it has its own third API set for its foveated rendering.

[Herringway]

I see no problem here. I would really like to see these definitions moved out of the compiler and into some form of external platform configuration, though. Maybe someday far in the future.

[WalterBright]

Frankly, I am thinking the panoply of Apple operating system predefines has gone overboard. The symptom of that is the prevalence of this and related sequences:

version (OSX)
    version = Darwin;
else version (iOS)
    version = Darwin;
else version (TVOS)
    version = Darwin;
else version (WatchOS)
    version = Darwin;

It tells me that, as far as the compiler's code generation is concerned, there is not a substantive difference between them. I'd be happy with just Apple as the predefined version and the others can be manually set as needed.

[ibuclaw]

What are the target triplets for these mobile systems?

[LunaTheFoxgirl]

What are the target triplets for these mobile systems?

• x86_64-apple-macos(version) or x86_64-apple-darwin (x86_64 macOS)
• arm64-apple-macos(version) or arm64-apple-darwin (arm64 macOS)
• x86_64-apple-ios(version)-simulator (x86_64 iOS simulator for x86_64 macOS installs)
• arm64-apple-ios(version) (arm64 iOS, watchOS, tvOS, etc.)

(version) is defined by MACOSX_DEPLOYMENT_TARGET and IPHONEOS_DEPLOYMENT_TARGET

[LunaTheFoxgirl]

Frankly, I am thinking the panoply of Apple operating system predefines has gone overboard. The symptom of that is the prevalence of this and related sequences:

version (OSX)
    version = Darwin;
else version (iOS)
    version = Darwin;
else version (TVOS)
    version = Darwin;
else version (WatchOS)
    version = Darwin;

It tells me that, as far as the compiler's code generation is concerned, there is not a substantive difference between them. I'd be happy with just Apple as the predefined version and the others can be manually set as needed.

The difference between them are mainly outside of the D runtime's scope. But for all intents and purposes they are seperate systems and having the seperation is useful if you for example develop apps that you want to be portable across macOS, iOS and iPadOS.

While iPadOS and iOS count both as "iOS"; in reality there's important API differences that would cause compilation errors or segfaults. Having the D compiler provide these is useful for developers; in that we don't have to redefine it for every library and application we make.