<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 24, 2017, at 4:19 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I'm glad you've resurrected this idea. I think it's worth thinking about, certainly. At the moment, I do have some thoughts, some of which I may have already had but have now forgotten. They're more notions than objections, but I'll share them as they are:<div class=""><br class=""></div><div class="">* The new integer protocols now provide `bitWidth` (note the spelling) on all fixed-width integer types. Since Int is defined as 32 bits on 32-bit platforms and 64 bits on 64-bit platforms, it is possible to write `if Int.bitWidth == 64 { ... }`. It isn't a conditional compilation block as written, but as I understand it, the compiler either already does or should be able to make it effectively a compile-time conditional. The question remains if an explicit conditional compilation feature with a subtly different spelling makes possible significant additional use cases. I don't know the answer, but I think it's worth re-considering in light of the new protocols.</div><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>The requests were community driven. I'd defer to the community to decide whether compile-time conditional blocks or runtime would be better here.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">* The new integer protocols had one chunk sent back for revision, which consist of the parts about endianness. I think it might be wise to see how that plays out before considering a conditional compilation feature, for the reason that we may end up with a scenario similar to the one with `bitWidth`.</div></div></div></blockquote><div><br class=""></div><div>nod.</div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="">* I have concerns about `vendor`. I get that it (a) allows you to write something much shorter than `os(macOS) || os(iOS) || os(tvOS)`; and (b) lets you anticipate any future OS from the same vendor. But two issues that come to mind here are as follows. (1) In the Apple world, there's one vendor for multiple platforms, but in the Linux world, there'd be many vendors for one platform. It's unclear to me _how_ one might use `vendor` profitably when it's so different. Is the only or main practical use envisioned here a shorthand for Apple platforms? If so, couldn't we cut the pretense and just write `#if apple`? (2) I get that part of the motivation is that Apple may introduce a new platform and they often re-use their technologies, and it'd be nice to get your code working "for free" on a new platform. However, it seems to me that this would be unwise as a language feature. There are no guarantees at all about what a future Apple platform will look like. In other words, if `vendor(Apple)` is to evaluate `true` for every Apple OS, it is a meaningless condition, as Apple makes no guarantees whatsoever about commonalities between its current and future platforms, and one cannot reason at all about code written for such a scenario.</div><div class=""><br class=""></div><div class="">* Intuitively, `interop` seems fine, but I don't have much experience with Obj-C interop.</div><div class=""><br class=""></div><div class="">* I think a better option than testing the difference between `arch` and `os` would be great for detecting a simulator. I also think--just to bikeshed a little--we can save on having a new word for this: just have an optional argument in OS, since we're really asking is this "iOS" really the "iOS Simulator"? That is: `#if os(iOS, simulator)` vs `#if os(iOS, device)`. We can even have the compiler reject conditions such as `#if os(macOS, simulator)` if we want.</div></div></blockquote><div><br class=""></div><div><br class=""></div>At this point, I'm just probably going to backburner this as well. No one seems particularly interested in it.</div><div><br class=""></div><div>-- E</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Apr 24, 2017 at 3:07 PM, Erica Sadun via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">I'm going to throw this back out into the SE arena to see if there's still interest in these. <div class=""><br class=""></div><div class=""><a href="https://github.com/apple/swift-evolution/pull/369" target="_blank" class="">https://github.com/apple/<wbr class="">swift-evolution/pull/369</a></div><div class=""><br class=""></div><div class=""><div style="font-family:Palatino-Roman" class="">It seems to me that many of these are already incorporated into the language as private calls, and would only need minimal coding. Given the extremely limited timeline and the high volume of list traffic, I'm looking for specific concerns (or benefits) you see in this pitch. </div></div><div style="font-family:Palatino-Roman" class=""><br class=""></div><div style="font-family:Palatino-Roman" class="">Thank you,</div><div style="font-family:Palatino-Roman" class=""><br class=""></div><div style="font-family:Palatino-Roman" class="">-- Erica</div><div style="font-family:Palatino-Roman" class=""><br class=""></div><div class=""></div></div><br class="">______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div></div></div>
</blockquote></div><br class=""></body></html>