[swift-dev] [RFC] Finer grained OS checks
Saleem Abdulrasool
compnerd at compnerd.org
Tue Jul 12 22:13:06 CDT 2016
On Mon, Jul 11, 2016 at 2:33 PM, Karl Wagner <razielim at gmail.com> wrote:
> I remember somebody telling me it was, but it was years ago and I'm
> probably remembering it wrong. Fair enough though; I got told on that one
> 😶
>
> I'm standing by the principle - it shouldn't matter if you're running in a
> simulator or not. Use a compile flag if you must know, but in general I
> disagree with a compiler flag for determining the runtime platform for two
> platforms with the same API and triple.
>
> Karl
>
> On Jul 11, 2016 at 11:26 PM, <Greg Parker <gparker at apple.com>> wrote:
>
>
> On Jul 11, 2016, at 9:50 AM, Karl Wagner via swift-dev <
> swift-dev at swift.org> wrote:
>
> - 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?
>
>
> The iOS simulator is not literally x86 iOS. It has changed ABI in
> incompatible ways in the past and reserves the right to do so in the
> future. Any real x86 iOS would have a real ABI which would likely differ
> from today's simulator.
>
>
> --
> Greg Parker gparker at apple.com Runtime Wrangler
>
>
Well, the name that I went with was environment was derived from the fact
that it was based on the "environment" component of the "triple". That
said, an alternative idea is to make a more invasive change:
`host(...)`: where we can actually do a more target specific component
matching. Something like:
#if host(Windows, msvc)
#elseif host(Linux, musl)
#elseif host(iOS, ARM)
#endif
--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160712/0644cbb0/attachment.html>
More information about the swift-dev
mailing list