<div dir="ltr">I made a PR <a href="https://github.com/apple/swift/pull/2351">https://github.com/apple/swift/pull/2351</a> introducing os(Cygwin).<div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-04-27 5:54 GMT+09:00 John McCall <span dir="ltr">&lt;<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">&gt; On Apr 26, 2016, at 1:39 PM, Joe Groff &lt;<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>&gt; wrote:<br>
&gt;&gt; On Apr 26, 2016, at 1:24 PM, John McCall via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt; On Apr 26, 2016, at 1:03 PM, Sangjin Han &lt;<a href="mailto:tinysun.net@gmail.com">tinysun.net@gmail.com</a>&gt; wrote:<br>
&gt;&gt;&gt; The problem can be solved by modifying that code. Thanks you. I thought that code will affect only to the CLong type not Int.<br>
&gt;&gt;<br>
&gt;&gt; It changes what &#39;long&#39; gets imported as.  If there&#39;s a Windows API defined using &#39;long&#39; (rather than some more meaningful typedef like &#39;size_t&#39;), it&#39;s important for it to be imported as Int32 rather than Int, since &#39;long&#39; is always 32 bits under MSVC.<br>
&gt;&gt;<br>
&gt;&gt;&gt; But I meet another problem to fix it. I couldn&#39;t find the conditional method to distinct x86_64-*-windows-msvc with x86_64-*-windows-cygnus in Swift source.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; &quot;#if os(Windows)&quot; can not distinct MSVC from Cygwin.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Should I add new condition &#39;env()&#39; for the environment?<br>
&gt;&gt;<br>
&gt;&gt; That is an excellent question.<br>
&gt;&gt;<br>
&gt;&gt; My understanding / memory is that, as far as their programming interfaces goes, Cygwin and MSVC are very, very different environments.  Maybe it&#39;s useful to have a condition that&#39;s true for both environments — although I&#39;m not sure why it would — but I don&#39;t think it deserves to be as prominent as os(Windows).  So my gut reaction is that, rather than adding a #env, we ought to just reserve os(Windows) for MSVC compatibility and make a new os(Cygwin) for Cygwin.<br>
&gt;&gt;<br>
&gt;&gt; This needs to be raised on swift-evolution, though.  CC&#39;ing that list.<br>
&gt;<br>
&gt; It&#39;s an interesting question. Mingw, Cygwin, and MSVC definitely vary greatly in ABI and C language level behavior, but the underlying Win32 system libraries remain the same. I think it makes sense to consider them different os(...) environments, but it would also make sense IMO to have a broader platform check for Win32.<br>
<br>
</span>If, after import and however much magic, they both end up exposing a similarly-typed set of system APIs, I agree that it makes sense to have a condition that says &quot;yes, the target has those APIs&quot;.  It certainly seems like a worthwhile goal for Swift to present them with the same imported types.<br>
<span class="HOEnZb"><font color="#888888"><br>
John.</font></span></blockquote></div><br></div>