Why is `std::env::consts::OS` a string and not a rust enum?

1

I get that strings are more flexible, and in the case where a new os is released but does not exist in the enum, then it would be incompatible with a traditional enum, but can't it be something like this:

enum OperatingSystem {
  Linux,
  Windows,
  MacOS,
  Android,
  IOS,
  // ...
  Other(String)
}

I get that the Other arm of the enum is very redundant, but I feel like making it an enum is just more developer friendly as well, as we get access to the pattern matching capabilities. I guess the only issue is the case where Other contains a value that may be related to the other known OSes.

2

If we did that, every new OS would need to be put in the Other variant, which doesn't really help type safety over just using a string in the first place.

3

It could have been a non_exhaustive enum instead. Obviously it could not be changed any longer though, it would be a breaking change.

2 Likes
4

#[non_exhaustive] wasn't stabilized until Rust 1.40. The constant was part of Rust 1.0. While there was a workaround, it's never great to rely on that.

2 Likes