[swift-evolution] Pitch: Replacement for FileHandle
charlie at charliemonroe.net
Thu Feb 16 00:49:16 CST 2017
> On Feb 16, 2017, at 7:18 AM, Kevin Nattinger via swift-evolution <swift-evolution at swift.org> wrote:
>> On Feb 15, 2017, at 3:45 PM, Tony Parker via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> On Feb 15, 2017, at 2:25 PM, Charles Srstka <cocoadev at charlessoft.com <mailto:cocoadev at charlessoft.com>> wrote:
>>>> On Feb 15, 2017, at 3:11 PM, Itai Ferber <iferber at apple.com <mailto:iferber at apple.com>> wrote:
>>>> FYI, Tony is the manager of the Foundation team. :)
>>>> 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".
>>> 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.
>>> 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.
>>>> 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.
>>> 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: rdar://30543037 <rdar://30543037> and rdar://30543133 <rdar://30543133>.
>> Thanks for filing these.
>> 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,
> At the risk of getting off-topic, I think it would defuse a lot of developer frustration around that to just show the status (open/fixed/wontfix/correct) of the root bug. Filed radar 30551245 suggesting as much ;-)
Wouldn't it be possible for Apple to add a checkbox next to the issue that the reporter can check consenting the issue becoming public? I fully understand that many of the issues reported are confidential (security issues, attached code, etc.); but there are many, many, many issues that I'd be comfortable with becoming public so that others can just +1 them and see their status; or even comment on them, suggest workarounds. Something like OpenRadar does...
>> but our intent is simply to consolidate the reports we have so that we know that the issue is serious.
>> 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.
>> 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.
>> - Tony
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution