<div dir="ltr"><div>>Because it means that there is exactly one API: not a canonical API and a similar-but-different and less efficient wrapper.</div><div><br></div>Fair enough. <div><br></div><div>>The approach taken here generalizes to other (similarly structured) C APIs as well.</div><div><br></div><div>I don't see any mention of this in the proposal. Is this related to the other C api translation proposal?<br><div><br></div><div>>Why not do it?</div><div><br></div><div>Well, I want "equal opportunity" for all libraries. I am a huge fan of the structured concurrency scheme that <a href="https://github.com/VeniceX/Venice">Venice</a> provides by wrapping libmill, and I don't want it (or any other C libraries) to lag behind LibDispatch simply because it is not Apple's own. If the changes in this proposal do affect all c libraries, then obviously I am all for it. But the way I see it, and please correct me if I am mistaken, giving LibDispatch special treatment adds an extra crutch to other third party libraries which would otherwise be on a level playing field.</div></div><div><br></div><div>Dan</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, May 19, 2016 at 10:05 PM Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On May 19, 2016, at 10:02 PM, Dan Appel <<a href="mailto:dan.appel00@gmail.com" target="_blank">dan.appel00@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div>>Swift 2.2 code should be run through a migrator, which is able to automatically handle changes like this.</div><div><br></div>Yes, but that's not really my point. Why do it this "magical" way? </div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>Because it means that there is exactly one API: not a canonical API and a similar-but-different and less efficient wrapper. The approach taken here generalizes to other (similarly structured) C APIs as well.</div><div><br></div><div>As I mentioned before this isn’t about breaking code, so let me flip your question around: Why not do it? </div></div></div><div style="word-wrap:break-word"><div><div><br></div><div>-Chris</div></div></div><div style="word-wrap:break-word"><div><div><br></div><br><blockquote type="cite"><div><div dir="ltr">It's already possible (and actually very easy) to wrap C modules such as libdispatch in a Swifty API (see <a href="https://github.com/VeniceX/Venice" target="_blank">Venice</a>, <a href="https://github.com/Zewo/OpenSSL" target="_blank">OpenSSL</a>, <a href="https://github.com/Zewo/PostgreSQL" target="_blank">PostreSQL</a> as examples). I know that LibDispatch is special to Swift and Apple, but I just don't see a reason to give it such a special treatment.<div><br></div><div>Dan</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, May 19, 2016 at 9:56 PM Chris Lattner <<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On May 19, 2016, at 9:53 PM, Dan Appel <<a href="mailto:dan.appel00@gmail.com" target="_blank">dan.appel00@gmail.com</a>> wrote:<br>
><br>
> Does this mean that all current code using Dispatch is broken?<br>
<br>
Are you asking about Swift 2.2 code?<br>
<br>
Swift 2.2 code is generally completely incompatible with Swift 3 for a lot of other reasons (e.g. major changes to the standard library APIs). Swift 2.2 code should be run through a migrator, which is able to automatically handle changes like this.<br>
<br>
-Chris</blockquote></div><div dir="ltr">-- <br></div><div><div dir="ltr"><div><div>Dan Appel<br></div></div></div></div>
</div></blockquote></div></div></blockquote></div><div dir="ltr">-- <br></div><div><div dir="ltr"><div><div>Dan Appel<br></div></div></div></div>