<div dir="ltr">Hi,<div><br></div><div>Id like to revive the discussion around OS "variants". I've been doing some work to bring up Windows without any emulation layer (MSVCRT based) as a viable host environment. This work is bringing to light the need for more finer grained OS checks.</div><div><br></div><div>Currently, we have the `os` compilation condition. However, this doesn't provide sufficiently detailed information for Windows. On Windows, we have at least 4 different "variants":</div><div><br></div><div>- "msvc" (Microsoft's environment)</div><div>- "itanium" (MS ABI for C, Itanium ABI for C++)</div><div>- "gnu" (MinGW)</div><div>- "cygnus" (cygwin)</div><div><br></div><div>Each one of these is slightly different and requires particular handling in the runtime. However, the OS for each one of these is windows, and so `os(Windows)` yields true on all of them.</div><div><br></div><div>This is not a problem strictly limited to Windows. It also appears in other OSes. As a concrete example, Linux has traditionally had the "gnu" environment (libc). However, there is also "uclibc" which is pretty common, and these days, "musl" as different targets. Swift also supports android, which is a Linux environment variant.<br><br>As deeper system integration occurs with swift, the need for finer grained os detection logic is probably going to be needed.</div><div><br></div><div>To keep things simple, I would like to propose the "environment" conditional compilation directive. It would yield true for the appropriate environment with one of the previously mentioned values for windows and true for "android" on Android. It would sit as a peer to `os` and allow for finer grained querying of the host environment.</div><div><br></div><div>-- <br><div data-smartmail="gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div>
</div></div>