<div dir="ltr"><div>&gt;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>&gt;The approach taken here generalizes to other (similarly structured) C APIs as well.</div><div><br></div><div>I don&#39;t see any mention of this in the proposal. Is this related to the other C api translation proposal?<br><div><br></div><div>&gt;Why not do it?</div><div><br></div><div>Well, I want &quot;equal opportunity&quot; 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&#39;t want it (or any other C libraries) to lag behind LibDispatch simply because it is not Apple&#39;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 &lt;<a href="mailto:clattner@apple.com">clattner@apple.com</a>&gt; 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 &lt;<a href="mailto:dan.appel00@gmail.com" target="_blank">dan.appel00@gmail.com</a>&gt; wrote:</div><br><div><div dir="ltr"><div>&gt;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&#39;s not really my point. Why do it this &quot;magical&quot; 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&#39;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&#39;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 &lt;<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
&gt; On May 19, 2016, at 9:53 PM, Dan Appel &lt;<a href="mailto:dan.appel00@gmail.com" target="_blank">dan.appel00@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; 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>