<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="Apple-tab-span" style="white-space:pre">        </span>Having only recently run into issues with FileHandle throwing exceptions I can’t catch (luckily in a logging framework, so it’s not production code), I’ve only had the briefest of example of the frustration anyone trying to use it in Swift seriously must suffer. So there are probably two points here.<div class=""><br class=""></div><div class="">1. Is there anything developers can do today to use FileHandle safely in Swift? There doesn’t seem to be, which seems to me to justify rather extreme measures to fix the problem. As it stands right now FileHandle shouldn’t be used from Swift on Apple platforms, which is a rather poor experience all around.</div><div class=""><br class=""></div><div class="">2. How can the issue be fixed for Swift? I think part of (or most) the reason Charles originally suggested using the open source Foundation implementation was because of the (apparently) severely breaking changes that would be required on the Apple Foundation side to actually fix the issue. I also think a lot of the frustration in this thread came from the fact that these APIs have been known not to conform to best practices for over a decade now and yet haven’t been fixed, which then descended into complaints about Apple’s dev process in general. Not productive but I think indicative of the logic behind Charles original suggestion that the open source implementation be used instead of Apple’s. Correct me if I’m wrong Charles.</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span></div><div class="">It’s clear that there’s more here than just an evolution proposal for a new Swifty FileHandle API. What should the process be for proposals which may also require underlying Apple framework changes, like this one? A proposal for a new API that also references Radar(s)? Get the changes from Apple first and then make the proposal? Or a separate proposal that suggests a mechanism for implicitly catching Objective-C exceptions as Swift errors? This clearly should be fixed, so how should it be done?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Jon</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 16, 2017, at 7:05 PM, Greg Parker via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="" applecontenteditable="true"><div class="">Please take off-topic discussion elsewhere. Thank you.</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 16, 2017, at 3:35 PM, Maxim Veksler via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class="">An off-topic suggestion on radar bugs:<br class=""><br class="">Instead of closing as "dupe" why not call it "merged" into a known issue ?<br class=""><br class="">Same technical result but very different IMHO user experience that allow communicating to the reporter that his bug hasn't simply been wrote-off as a "plus 1" but was combined into a very long story of use cases and examples to be considered while working on finding the optimal balance solution for the issue at hand.<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, 17 Feb 2017 at 1:16 Zach Waldowski via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u class="gmail_msg"></u>




<div class="gmail_msg"><div style="font-family:Arial" class="gmail_msg">I can scarcely think of a less productive or more disrespectful thing to do in a thread chock full of Apple engineers actively trying to help you out. They're just humans, led by other humans. They can't divine the presence of issues, just like they can't divine the priorities of individual tasks without a holistic view of them. It would be far more productive to figure out how we can get the changes we want done in a public release of software as soon as possible. Everything else is extraneous.<br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg"><br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg">Best,</div>
<div style="font-family:Arial" class="gmail_msg">Zachary</div></div><div class="gmail_msg">
<div class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg">On Thu, Feb 16, 2017, at 08:08 AM, Nick Keets via swift-evolution wrote:<br class="gmail_msg"></div>
<blockquote type="cite" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_msg">I’m going OT here, but even though I understand your reasons, you need to acknowledge that for developers the rational thing to do is to not file radars at all.<br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg"><br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg">Any bug fix will get released at best a few months later and you can only actually take advantage of it a few years later (if you care about supporting older versions). More realistically we are talking 3-4 years of having to work around it (in the best cases). This is a lot of work (with almost zero feedback) for some far future benefit that probably will not even be relevant to you then.<br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg"><br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg">So to me, when an Apple developer asks me to file a radar, it feels like they are asking me to do their job.<br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg"><br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg">I’m sorry for the off-topic rant.<br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg"><br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg">On Thu, Feb 16, 2017 at 1:45 AM, Tony Parker via swift-evolution <span dir="ltr" class="gmail_msg">&lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br class="gmail_msg"></div>
</div>
</blockquote><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex" class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div style="font-family:Arial" class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Feb 15, 2017, at 2:25 PM, Charles Srstka &lt;<a href="mailto:cocoadev@charlessoft.com" class="gmail_msg" target="_blank">cocoadev@charlessoft.com</a>&gt; wrote:<br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg"><blockquote type="cite" class="gmail_msg">On Feb 15, 2017, at 3:11 PM, Itai Ferber &lt;<a href="mailto:iferber@apple.com" class="gmail_msg" target="_blank">iferber@apple.com</a>&gt; wrote:<br class="gmail_msg"></blockquote><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div style="font-family:Arial" class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg"><p style="font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg"><span class="gmail_msg m_3193624783512539688font" style="font-family:sans-serif"><span class="gmail_msg m_3193624783512539688size" style="font-size:12px">FYI, Tony is the manager of the Foundation team. :)<br class="gmail_msg">We care very much about making sure that the experience of using our framework is a positive one — the more Radars we get, the better we can prioritize improving APIs that are not working as well as they could be for our users. Even if the Radar gets duped to an existing one, thats one more +1 for that Radar saying "this is a problem".</span></span></p></div>
</blockquote><div class="gmail_msg">Yeah I know, but it’s a frustrating experience, spending a half hour writing a detailed bug report (sometimes with videos attached to demonstrate the issue), just to effectively do the same thing as spending 5 seconds to hit the +1 button on most issue trackers you come across.<br class="gmail_msg"></div>
<div class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg">Especially since you never find out what happened to the original bug report. You can see if it’s open or closed, but did they fix it in some internal build? Did they decide it “behaves correctly?” Did somebody just skim your report, and mistakenly attach it to some other, unrelated issue? There’s no way to know.<br class="gmail_msg"></div>
<blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><p style="font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg"><span class="gmail_msg m_3193624783512539688font" style="font-family:sans-serif"><span class="gmail_msg m_3193624783512539688size" style="font-size:12px">I will search for your old Radar, but in any case, please do file a new one about this, and about any other issues you have, because we are indeed listening.</span></span><br class="gmail_msg"></p></div>
</blockquote></div>
<div class="gmail_msg">I was pretty sure I'd submitted something way, way back in the misty days of yore, but I can’t find it. I’ve filed a couple of new ones:&nbsp;<a class="gmail_msg">rdar://30543037</a>&nbsp;and <a class="gmail_msg">rdar://30543133</a>.<br class="gmail_msg"></div>
<div class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg">Charles<br class="gmail_msg"></div>
<div class="gmail_msg"><br class="gmail_msg"></div>
</div>
</div>
</blockquote></div>
<div style="font-family:Arial" class="gmail_msg"><br class="gmail_msg"></div>
</div>
</div>
<div class="gmail_msg">Thanks for filing these.<br class="gmail_msg"></div>
<div class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg">Sometimes, for process reasons, we do indeed mark bugs as dupes of other ones. Usually the polite thing to do is to dupe to the earliest filed one. Sometimes this comes across with an appearance of not caring to the filer of the new bug, but our intent is simply to consolidate the reports we have so that we know that the issue is serious.<br class="gmail_msg"></div>
<div class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg">We do not make API changes without going through a vigorous review process, to avoid churn for the many clients above us. The flip side is that this can take some time. I’m sure you understand that all software engineering is about tradeoffs.<br class="gmail_msg"></div>
<div class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg">All of that said, we’ll take a look at these and see what improvements we can make here. As I said, I’m not a fan of exception-based API.<br class="gmail_msg"></div>
<div class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg">- Tony<br class="gmail_msg"></div>
<div class="gmail_msg"><br class="gmail_msg"></div>
<div class="gmail_msg"><br class="gmail_msg"></div>
</div>
<div style="font-family:Arial" class="gmail_msg"><br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg">_______________________________________________<br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg"> swift-evolution mailing list<br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg"> <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg"> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg"> <br class="gmail_msg"></div>
</blockquote></div>
</div>
<div class="gmail_msg"><u class="gmail_msg">_______________________________________________</u><br class="gmail_msg"></div>
<div class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"></div>
<div class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"></div>
<div class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div>
</blockquote><div style="font-family:Arial" class="gmail_msg"><br class="gmail_msg"></div>
</div>

_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>
_______________________________________________<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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>