This is clever, but I’m not sure it’d get used anywhere else. In particular, I don’t think we want to demote the Apple OSs to be “Apple.OSX” and “Apple.iOS”, even though asking “am I on an Apple platform” is a reasonable question. Similarly, “POSIX?” is a reasonable query to ask of most OSs, but doesn’t fit into a hierarchy.
That said, sub-OSs of “Linux” would probably make plenty of sense…other than when a distro is forked. Hm. Jordan > On May 4, 2016, at 09:07, Michael Peternell <[email protected]> wrote: > > Hi, > > just a quick question... would it maybe be feasible or practical to have > "sub-OSes", like e.g. `#if os(Windows.MSVC)`, `#if os(Windows.Cygwin)` or > `#if os(Windows.MinGW)`? > > -Michael > >> Am 03.05.2016 um 20:43 schrieb Jordan Rose via swift-evolution >> <[email protected]>: >> >> We’ve had this kind of thing come up before, too, with the >> Linux/FreeBSD/Android group vs. the OSX/iOS/watchOS/tvOS group, or with >> 32-bit architectures vs. 64-bit architectures. Erica Sadun wrote up quite a >> few of the choices here: >> http://thread.gmane.org/gmane.comp.lang.swift.evolution/12161/ >> >> …none of which quite match the MSVC vs. Cygwin distinction. (And where does >> MinGW fit in?) >> >> (I think there was another thread with even more possible platform >> conditions, but I can’t find it.) >> >> One thing that I’d like to keep is that os(…) (like arch(…)) is (a) >> non-overlapping and (b) covers everything, i.e. there should never be a >> platform Swift supports for which no os(…) predicate is true. That doesn’t >> have to be the case for other, new predicates, though. >> >> I think one of the big questions (already identified in this thread) is “how >> often does the same code apply for both Cygwin and Windows?” If the answer >> is “pretty much never” or even “rarely", then treating them as separate >> “OSs” seems fine—in the rare case someone can use “os(Windows) || >> os(Cygwin)”. However, if the answer is “most of the time” (leaving the >> standard library out of it, since that’s not representative of average user >> code), then it feels like the common “os(Windows)” predicate makes more >> sense, and we should come up with something else to distinguish them. >> >> (Again, “where does MinGW fit in?” might help clarify this direction.) >> >> We’re also free to rename things in this discussion. If it turns out there’s >> a better word than “os”, we can switch to it. >> >> Jordan >> >> >> >>> On May 2, 2016, at 22:00, Sangjin Han via swift-evolution >>> <[email protected]> wrote: >>> >>> Hello swift-evolution, >>> >>> This is continued from PR #2351(https://github.com/apple/swift/pull/2351). >>> >>> Here is the brief history. (To avoid confusion, I used MSVC refer to >>> *-*-windows-msvc and Cygwin refer to *-*-windows-cygnus in LLVM.) >>> >>> I needed the #if method to distinct MSVC from Cygwin, for mapping the Int >>> to CLongLong not CLong on MSVC. >>> In PR #2351, I simply added 'os(Cygwin)' and restrict 'os(Windows)' to >>> *-*-windows-msvc from *-*-windows-*, this solved my problem. >>> >>> Jake(@jakepetroules) pointed out that Cygwin is not an OS and it will never >>> fixed to avoid breaking user applications. >>> There is more participants and opinions, briefly, >>> - introduce another new one such as 'env(cygnus)' or 'triple(Cygwin)' >>> - the usability of the common condition 'os(Windows)' for *-*-windows-* >>> - fundamentally, what do we gain from asking which os() is in use? >>> - 'env()' is too vague >>> - what the right questions? >>> >>> Forgive me the poor quotations of valuable opinions. >>> >>> >>> I hope we find out the solution or method everybody satisfied. >>> >>> >>> -Han Sangjin >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
