<html><head></head><body><div>My thoughts:</div><div><br></div><div>I don't like the idea of additional qualifiers after OS. Perhaps we could rename it something more generic like "SDK" or split the non-common stuff in to a seprarate module?</div><div><br></div><div>As for the proposal (I know it's too late for Swift 3, but I read it so I might as well say what i thought about it):</div><div>- I don't like "vendor"; it's too vague to give useful guarantees. Even the Apple platforms can be wildly different. I would prefer a group SDK target instead, like "mobileDarwin", or even something better than that (the "canImport" idea is even better - so you can test for the presence of frameworks such as UIKit directly, and the compiler will/should use @availability attributes to ensure it is safe for all of your deployment targets)</div><div>- Also don't like the simulator condition variable. The iOS simulator is literally x86 iOS. If there was an x86 iPhone, theoretically your binaries would be compatible. The fact that it runs on a simulator instead of a real device is not such a vital distinction (or shouldn't be) that we need integrate it in the language. What would we do in the future if there ever was a real x86 iOS target?</div><div><div class="acompli_signature"></div></div><div><br></div><div>Sorry to give a list of stuff I don't like, but it's easier that way because the rest of it is good. Endianness, word-size and Interop availability are useful things to know and really are compile-time options, and as I said canImport is also a very good idea.</div><div><br></div><div>Karl</div><br><br><br>
<div class="gmail_quote">On Fri, Jul 8, 2016 at 3:17 AM +0200, "Saleem Abdulrasool via swift-dev" <span dir="ltr"><<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>></span> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="3D"ltr"">
<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>
</div>
</blockquote>
</div>
</body></html>