5 days ago
On Sunday, 22 June 2025 at 00:44:42 UTC, Jonathan M Davis wrote:
>
> As for Darwin or whether we need `__APPLE__` (or whatever we call it) as a replacement, well, I'm not familiar enough with Apple's OSes to weigh in on that.
>
> - Jonathan M Davis

Maybe in that case we can fix all other versions as well..
And just some examples from other langs (from gpt)

```rust
use std::env;

fn main() {
    let os = if cfg!(target_os = "linux") {
        "linux"
    } else if cfg!(target_os = "macos") {
        "macos (Darwin)"
    } else if cfg!(target_os = "ios") {
        "ios (Darwin)"
    } else if cfg!(target_os = "windows") {
        "windows"
    } else {
        "unknown"
    };

    println!("Running on: {}", os);
}
```

Rust: all small letters - consistent

```swift
import Foundation

func getOSName() -> String {
    #if os(Linux)
    return "linux"
    #elseif os(macOS)
    return "macos (Darwin)"
    #elseif os(iOS)
    return "ios (Darwin)"
    #else
    return "unknown"
    #endif
}

print("Running on: \(getOSName())")
```

Swift: playing with all proper names (see Linux with capital)

```go
package main

import (
	"fmt"
	"runtime"
)

func main() {
	os := runtime.GOOS
	var osName string

	switch os {
	case "linux":
		osName = "linux"
       case "ios":
                osName = "darwin (iOS)"
	case "darwin":
		osName = "darwin (macOS)"
	default:
		osName = "unknown"
	}

	fmt.Printf("Running on: %s\n", osName)
}
```

Go: all small letters as well ("ios" support is a bit cumbersome though)

Consistency everywhere
5 days ago
On Sunday, 22 June 2025 at 03:40:44 UTC, Walter Bright wrote:
> Lots of good points, Jonathan.
>
> The current situation for C #defines for operating systems is an utter disaster. I can find zero official guidance from Apple on what to use.
>
> People have remarked that I was denigrating Linux by using lowercase "linux" as the version, but nothing of the sort was my intention. It was simply that "linux" was the most commonly used predefine in the Linux world.
>
> Maybe we should simply go with "Apple" as the umbrella for the various Apple operating systems, and be done with it. Maybe we can set a positive trend there! Wouldn't that be nice!

I’d propose 2 predefined versions;
'AppleOS` for all Darwin/mach derived apple OSes
'AppleMobileOS` for all apple OSes that use the mobile set of APIs (there’s different APIs between the mobile and desktop APIs)

This would make it easier to write software that targets both desktop and mobile Apple OSes.

5 days ago
On Sunday, 22 June 2025 at 14:25:37 UTC, Luna wrote:
> On Sunday, 22 June 2025 at 03:40:44 UTC, Walter Bright wrote:
>> [...]
>
> I’d propose 2 predefined versions;
> 'AppleOS` for all Darwin/mach derived apple OSes
> 'AppleMobileOS` for all apple OSes that use the mobile set of APIs (there’s different APIs between the mobile and desktop APIs)
>
> This would make it easier to write software that targets both desktop and mobile Apple OSes.

I like Luna's Solution. I already use `AppleOS` in my engine as well for handling that same issue.
4 days ago
And a PR:

https://github.com/dlang/dmd/pull/21471
4 days ago
Unfortunately, due to the needs of legacy compatibility, one winds up with multiple ways to express the same thing. Then we wind up with Apple's conundrum with Darwin, darwin, DARWIN, `__DARWIN__`, `__APPLE__`, `__MACH__`, etc.
1 day ago

On Sunday, 22 June 2025 at 00:44:42 UTC, Jonathan M Davis wrote:

>

[I]f we were redoing them, maybe it would be better to just make them all of the predefined ones start with __ so that any that start with __ but aren't known are an error, significantly reducing the bugs related to mistyping version identifers - not that that would entirely fix the problem, since someone could still forget a _ and make it look like a user-defined one (and of course, we can't fix the problem with user-defined ones unless we do something like require that a list of all valid version identifiers be provided somehow).

A different approach could be to special-case version identifiers and require them to be ASCII-only and partially case-insensitive. The latter means that X and x are considered essentially the same, but only one of them is correct and defining it makes using the other an error. That means the built-in ones linux, Windows, iOS, etc., make it an error to use Linux, windows, or IOS. The error message can tell you what the correct spelling is. There’s no use case for the same identifier with different casing. I’d also ban version user-defined version identifiers with upper-case letters and reserve them for the language.

Maybe also change all the built-in ones to include an upper case letter.

It’s a breaking change, but one that can be mitigated by search and replace.

version(Linux) {} // error: Use `linux`
version(OSx) {} // error: Use `OSX`
version(Win) {} // error: `Win` is not a built-in version identifier
version(win) {} // okay
1 day ago
> I'd never thought of that, I was just following normal C practice with the predefines.

Your idea is a good one, but I think it's a bit too late. I'm concerned about the disruption it could cause. People with a lot of code just don't care for even simple changes like search/replace. We've inflicted enough of that.
1 day ago

On Thursday, 26 June 2025 at 17:03:33 UTC, Walter Bright wrote:

> >

I'd never thought of that, I was just following normal C
practice with the predefines.

Your idea is a good one, but I think it's a bit too late. I'm concerned about the disruption it could cause. People with a lot of code just don't care for even simple changes like search/replace. We've inflicted enough of that.

Most of the time, following C is a mistake, but in most cases, it's okay (simplicity & efficiency).

It is obvious that following C is incorrect when it comes to OS predefines.

In my view, version (OS) was a mistake.

  1. Not type safe
  2. Inconsistent
  3. Prone to mistakes

D needs secure built-ins that are type-checked at COMPILE time.

static if (builtin.OS.tag == $Linux) {}
``


The benefit of using $ is that it eliminates the need to enforce an import, prevents internal modules from being revealed, or just eliminates the need to use the unsafe `version`.

By default, the most compelling and user-friendly code should be the most secure.

It should be annoying to use something unsafe.
1 2
Next ›   Last »