Re: [swift-evolution] Pitch: Replacement for FileHandle

[Charles Srstka via swift-evolution]

> On Feb 16, 2017, at 8:26 PM, Jon Shier via swift-evolution 
>  wrote:
> 
> 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.

Yeah, it is a bit of a ticking time bomb on Swift. So is Process/NSTask.

> 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.

Currently the only way to handle a runtime error with either of these classes 
is to catch the exception, and parse it. So if you changed NSFileHandle itself, 
you’d have to make the existing API into a wrapper over the new one, catching 
the errors and converting them into exactly the same exceptions as before. 
Obviously it’s doable, but it just seemed easier to use the existing 
open-source implementation to me. If Tony says they’ll fix the Objective-C 
implementation in Foundation, though, I certainly won’t complain if that 
happens.

> 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?

I don’t think Objective-C exceptions should be caught as Swift errors. 99% of 
the time, they’re not things that should be caught, and we ought to just get 
rid of that remaining 1%.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Jon Shier via swift-evolution]

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.

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.

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.

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?



Jon

> On Feb 16, 2017, at 7:05 PM, Greg Parker via swift-evolution 
>  wrote:
> 
> Please take off-topic discussion elsewhere. Thank you.
> 
> 
>> On Feb 16, 2017, at 3:35 PM, Maxim Veksler via swift-evolution 
>> > wrote:
>> 
>> An off-topic suggestion on radar bugs:
>> 
>> Instead of closing as "dupe" why not call it "merged" into a known issue ?
>> 
>> 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.
>> On Fri, 17 Feb 2017 at 1:16 Zach Waldowski via swift-evolution 
>> > wrote:
>> 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.
>> 
>> Best,
>> Zachary
>> 
>> On Thu, Feb 16, 2017, at 08:08 AM, Nick Keets via swift-evolution wrote:
>>> 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.
>>> 
>>> 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.
>>> 
>>> So to me, when an Apple developer asks me to file a radar, it feels like 
>>> they are asking me to do their job.
>>> 
>>> I’m sorry for the off-topic rant.
>>> 
>>> On Thu, Feb 16, 2017 at 1:45 AM, Tony Parker via swift-evolution 
>>> > wrote:
>>> 
 On Feb 15, 2017, at 2:25 PM, Charles Srstka > wrote:
 
> On Feb 15, 2017, at 3:11 PM, Itai Ferber  > 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 

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Greg Parker via swift-evolution]

Please take off-topic discussion elsewhere. Thank you.


> On Feb 16, 2017, at 3:35 PM, Maxim Veksler via swift-evolution 
>  wrote:
> 
> An off-topic suggestion on radar bugs:
> 
> Instead of closing as "dupe" why not call it "merged" into a known issue ?
> 
> 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.
> On Fri, 17 Feb 2017 at 1:16 Zach Waldowski via swift-evolution 
> > wrote:
> 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.
> 
> Best,
> Zachary
> 
> On Thu, Feb 16, 2017, at 08:08 AM, Nick Keets via swift-evolution wrote:
>> 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.
>> 
>> 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.
>> 
>> So to me, when an Apple developer asks me to file a radar, it feels like 
>> they are asking me to do their job.
>> 
>> I’m sorry for the off-topic rant.
>> 
>> On Thu, Feb 16, 2017 at 1:45 AM, Tony Parker via swift-evolution 
>> > wrote:
>> 
>>> On Feb 15, 2017, at 2:25 PM, Charles Srstka >> > wrote:
>>> 
 On Feb 15, 2017, at 3:11 PM, Itai Ferber > 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 <> and rdar://30543133 <>.
>>> 
>>> Charles
>>> 
>> 
>> 
>> 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, 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@swift.org 
>> 

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Maxim Veksler via swift-evolution]

An off-topic suggestion on radar bugs:

Instead of closing as "dupe" why not call it "merged" into a known issue ?

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.
On Fri, 17 Feb 2017 at 1:16 Zach Waldowski via swift-evolution <
swift-evolution@swift.org> wrote:

> 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.
>
> Best,
> Zachary
>
> On Thu, Feb 16, 2017, at 08:08 AM, Nick Keets via swift-evolution wrote:
>
> 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.
>
> 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.
>
> So to me, when an Apple developer asks me to file a radar, it feels like
> they are asking me to do their job.
>
> I’m sorry for the off-topic rant.
>
> On Thu, Feb 16, 2017 at 1:45 AM, Tony Parker via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Feb 15, 2017, at 2:25 PM, Charles Srstka 
> wrote:
>
> On Feb 15, 2017, at 3:11 PM, Itai Ferber  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 and rdar://30543133.
>
> Charles
>
>
> 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, 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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> *___*
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Zach Waldowski via swift-evolution]

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.


Best,

Zachary



On Thu, Feb 16, 2017, at 08:08 AM, Nick Keets via swift-evolution wrote:
> 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.
> 

> 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.
> 

> So to me, when an Apple developer asks me to file a radar, it feels
> like they are asking me to do their job.
> 

> I’m sorry for the off-topic rant.

> 

> On Thu, Feb 16, 2017 at 1:45 AM, Tony Parker via swift-evolution  evolut...@swift.org> wrote:
>> 

>>> On Feb 15, 2017, at 2:25 PM, Charles Srstka
>>>  wrote:
>>> 

 On Feb 15, 2017, at 3:11 PM, Itai Ferber  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 and rdar://30543133.
>>> 

>>> Charles

>>> 

>> 

>> 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, 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@swift.org

>> https://lists.swift.org/mailman/listinfo/swift-evolution

>> 

> _

> swift-evolution mailing list

> swift-evolution@swift.org

> https://lists.swift.org/mailman/listinfo/swift-evolution


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Aaron Crespo via swift-evolution]

Just in case: https://www.openradar.appspot.com/radar?id=5046886029328384

On Wed, Feb 15, 2017 at 1:41 PM, Charles Srstka via swift-evolution <
swift-evolution@swift.org> wrote:

> On Feb 15, 2017, at 10:52 AM, Tony Parker 
> wrote:
>
>
> Hi Charles,
>
> Have you happened to file a radar for Foundation that I can look up (for
> both this and process)?
>
> We are working hard on making sure that our API is right for Swift, and
> areas like this where we can make fairly trivial improvements are things
> that we can try to prioritize. As you say, the purpose of
> swift-corelibs-foundation is to present a unified API and prevent the need
> to fork. That means the best possible solution is to improve the API in
> Objective-C (where exceptions-as-control flow is wrong too) first, and then
> naturally flow that into Swift.
>
> Thanks,
> - Tony
>
>
> Honestly? I don’t remember. I feel like I would have sometime around 2005
> or 2006 or so, since that’s probably about when this first started
> bothering me, but it’s been a decade, so my memory is hazy. I do know that
> in the meantime, “considered harmful”-type articles have been written about
> these classes, like this one from eight years ago:
>
> https://mikeash.com/pyblog/friday-qa-2009-11-13-dangerous-cocoa-calls.html
>
> If you think it will actually prompt someone to change this, I’d be happy
> to write up a new one, although I figure it would almost certainly just get
> flagged as a duplicate.
>
> Charles
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Derrick Ho via swift-evolution]

I agree that the current state of bug reporting through radars is
unmotivating.

We file these bug reports and have no idea if it even made a difference.
After seeing this many times we just don't bother with bug reports.

Sure I understand that internally apple uses duplicated issues to show how
often an issue is happening. I guess those numbers motivate an apple
engineer to work on it. Well guess what, those numbers could motivate every
non-apple developer as well! We want to know that our "vote" counts!

Maybe the reason is that apple doesn't want to expose to the world that a
bug exists and therefore keeps it a secret. It is hard to keep bugs a
secret because eventually someone will blog about it or talk about it in a
public MAILING LIST.

I would very much like it if we could see the original bug report and
references to the duplicate reports so we know that our report made a
difference.

Are there down sides to exposing bug reports to the public?

(Sorry for going off topic as well)
On Thu, Feb 16, 2017 at 8:09 AM Nick Keets via swift-evolution <
swift-evolution@swift.org> wrote:

> 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.
>
> 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.
>
> So to me, when an Apple developer asks me to file a radar, it feels like
> they are asking me to do their job.
>
> I’m sorry for the off-topic rant.
>
>
> On Thu, Feb 16, 2017 at 1:45 AM, Tony Parker via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Feb 15, 2017, at 2:25 PM, Charles Srstka 
> wrote:
>
> On Feb 15, 2017, at 3:11 PM, Itai Ferber  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 and rdar://30543133.
>
> Charles
>
>
> 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, 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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Nick Keets via swift-evolution]

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.

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.

So to me, when an Apple developer asks me to file a radar, it feels like
they are asking me to do their job.

I’m sorry for the off-topic rant.


On Thu, Feb 16, 2017 at 1:45 AM, Tony Parker via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Feb 15, 2017, at 2:25 PM, Charles Srstka 
> wrote:
>
> On Feb 15, 2017, at 3:11 PM, Itai Ferber  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 and rdar://30543133.
>
> Charles
>
>
> 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, 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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Charlie Monroe via swift-evolution]

> On Feb 16, 2017, at 7:18 AM, Kevin Nattinger via swift-evolution 
>  wrote:
> 
> 
>> On Feb 15, 2017, at 3:45 PM, Tony Parker via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On Feb 15, 2017, at 2:25 PM, Charles Srstka >> > wrote:
>>> 
 On Feb 15, 2017, at 3:11 PM, Itai Ferber > 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  and rdar://30543133 .
>>> 
>>> Charles
>>> 
>> 
>> 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@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Kevin Nattinger via swift-evolution]

> On Feb 15, 2017, at 3:45 PM, Tony Parker via swift-evolution 
>  wrote:
> 
>> 
>> On Feb 15, 2017, at 2:25 PM, Charles Srstka > > wrote:
>> 
>>> On Feb 15, 2017, at 3:11 PM, Itai Ferber >> > 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 
>>  and rdar://30543133 .
>> 
>> Charles
>> 
> 
> 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 ;-)

> 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@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Tony Parker via swift-evolution]

> On Feb 15, 2017, at 2:25 PM, Charles Srstka  wrote:
> 
>> On Feb 15, 2017, at 3:11 PM, Itai Ferber > > 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 
>  and rdar://30543133 .
> 
> Charles
> 

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, 
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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Charles Srstka via swift-evolution]

> On Feb 15, 2017, at 3:11 PM, Itai Ferber  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 
 and rdar://30543133 .

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Itai Ferber via swift-evolution]

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".


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.


On 15 Feb 2017, at 10:41, Charles Srstka via swift-evolution wrote:

> On Feb 15, 2017, at 10:52 AM, Tony Parker  
wrote:


Hi Charles,

Have you happened to file a radar for Foundation that I can look up 
(for both this and process)?


We are working hard on making sure that our API is right for Swift, 
and areas like this where we can make fairly trivial improvements are 
things that we can try to prioritize. As you say, the purpose of 
swift-corelibs-foundation is to present a unified API and prevent the 
need to fork. That means the best possible solution is to improve the 
API in Objective-C (where exceptions-as-control flow is wrong too) 
first, and then naturally flow that into Swift.


Thanks,
- Tony


Honestly? I don’t remember. I feel like I would have sometime around 
2005 or 2006 or so, since that’s probably about when this first 
started bothering me, but it’s been a decade, so my memory is hazy. 
I do know that in the meantime, “considered harmful”-type articles 
have been written about these classes, like this one from eight years 
ago:


https://mikeash.com/pyblog/friday-qa-2009-11-13-dangerous-cocoa-calls.html 



If you think it will actually prompt someone to change this, I’d be 
happy to write up a new one, although I figure it would almost 
certainly just get flagged as a duplicate.


Charles




___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Charles Srstka via swift-evolution]

> On Feb 15, 2017, at 10:52 AM, Tony Parker  wrote:
> 
> Hi Charles,
> 
> Have you happened to file a radar for Foundation that I can look up (for both 
> this and process)?
> 
> We are working hard on making sure that our API is right for Swift, and areas 
> like this where we can make fairly trivial improvements are things that we 
> can try to prioritize. As you say, the purpose of swift-corelibs-foundation 
> is to present a unified API and prevent the need to fork. That means the best 
> possible solution is to improve the API in Objective-C (where 
> exceptions-as-control flow is wrong too) first, and then naturally flow that 
> into Swift.
> 
> Thanks,
> - Tony

Honestly? I don’t remember. I feel like I would have sometime around 2005 or 
2006 or so, since that’s probably about when this first started bothering me, 
but it’s been a decade, so my memory is hazy. I do know that in the meantime, 
“considered harmful”-type articles have been written about these classes, like 
this one from eight years ago:

https://mikeash.com/pyblog/friday-qa-2009-11-13-dangerous-cocoa-calls.html 


If you think it will actually prompt someone to change this, I’d be happy to 
write up a new one, although I figure it would almost certainly just get 
flagged as a duplicate.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Tony Parker via swift-evolution]

Hi Charles,

Have you happened to file a radar for Foundation that I can look up (for both 
this and process)?

We are working hard on making sure that our API is right for Swift, and areas 
like this where we can make fairly trivial improvements are things that we can 
try to prioritize. As you say, the purpose of swift-corelibs-foundation is to 
present a unified API and prevent the need to fork. That means the best 
possible solution is to improve the API in Objective-C (where 
exceptions-as-control flow is wrong too) first, and then naturally flow that 
into Swift.

Thanks,
- Tony

> On Feb 14, 2017, at 12:46 PM, Charles Srstka  wrote:
> 
>> On Feb 14, 2017, at 1:05 PM, Tony Parker > > wrote:
>> 
>> Hi Charles,
>> 
>> For both this and the Process proposal - why would we not just improve the 
>> API on the existing types instead of renaming them?
>> 
>> - Tony
> 
> 1) The Objective-C Foundation isn’t open source. It’s now 14 years since the 
> introduction of NSError, and those types still throw exceptions when they hit 
> runtime errors, despite the community consistently complaining about this 
> during the intervening decade and a half. I just don’t think it’s going to 
> happen. Those of us that asked for the change have mostly given up and 
> resigned ourselves to either writing our own file handle classes or using 
> exception handling for these things years ago (I would presume the problem is 
> backwards compatibility; there might be some legacy code out there that 
> depends on the exceptions being thrown, and that might prevent the change—an 
> issue that doesn’t exist for Swift code, since it can’t catch exceptions). 
> The Swift solution would start from code which is open-source, meaning that 
> implementation could be done by the community, without depending on the 
> Foundation team.
> 
> 2) For any changes that are made to the API for the Objective-C types, the 
> same changes will have to be made to the corelibs types anyway for 
> cross-platform source compatibility. Presumably, the unimplemented parts in 
> corelibs are going to need to be implemented as well in order for that 
> project to be complete. So why not kill two birds with one stone?
> 
> Charles
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Charles Srstka via swift-evolution]

> On Feb 14, 2017, at 1:05 PM, Tony Parker  wrote:
> 
> Hi Charles,
> 
> For both this and the Process proposal - why would we not just improve the 
> API on the existing types instead of renaming them?
> 
> - Tony

1) The Objective-C Foundation isn’t open source. It’s now 14 years since the 
introduction of NSError, and those types still throw exceptions when they hit 
runtime errors, despite the community consistently complaining about this 
during the intervening decade and a half. I just don’t think it’s going to 
happen. Those of us that asked for the change have mostly given up and resigned 
ourselves to either writing our own file handle classes or using exception 
handling for these things years ago (I would presume the problem is backwards 
compatibility; there might be some legacy code out there that depends on the 
exceptions being thrown, and that might prevent the change—an issue that 
doesn’t exist for Swift code, since it can’t catch exceptions). The Swift 
solution would start from code which is open-source, meaning that 
implementation could be done by the community, without depending on the 
Foundation team.

2) For any changes that are made to the API for the Objective-C types, the same 
changes will have to be made to the corelibs types anyway for cross-platform 
source compatibility. Presumably, the unimplemented parts in corelibs are going 
to need to be implemented as well in order for that project to be complete. So 
why not kill two birds with one stone?

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Replacement for FileHandle

[David Smith via swift-evolution]

> On Feb 14, 2017, at 7:18 AM, Charles Srstka via swift-evolution 
>  wrote:
> 
> MOTIVATION:
> 
> In Swift 3, NSFileHandle was renamed to FileHandle, making it the de facto 
> file handle class for use in Swift applications. Unfortunately, it’s not a 
> very good API. NSFileHandle supports no error reporting whatsoever, instead 
> throwing Objective-C exceptions whenever something goes wrong during reading 
> or writing. There is no way that I know of to catch these exceptions in 
> Swift, meaning that if a write failed because the disk ran out of space or 
> something, there’s no way to deal with that other than crashing the whole 
> application.
> 
> In addition, NSFileHandle’s asynchronous API is broken. It provides a 
> readabilityHandler property which allows blocks-based reading of files, but 
> this handler does not provide any way to detect when the end of the file is 
> reached, which makes it not useful for many applications.

For what it's worth, the readability handler is intended to be an analogue to 
select, kevent, or DISPATCH_SOURCE_TYPE_READ, not an async reading mechanism 
itself. Using real async IO like readInBackground* will be more efficient, and 
get you the EOF handling you expect. It's somewhat unfortunate that this 
relatively specialized API ended up looking so much more appealing than the 
more generally useful one, and that's something that could be improved in the 
future.

David 

> 
> PROPOSED SOLUTION:
> 
> Rename FileHandle back to NSFileHandle, and provide a Swift-native FileHandle 
> class for Foundation in Swift 4 that mimics NSFileHandle’s interface, but 
> provides throwing versions of all the read and write methods:
> 
> open class FileHandle : NSObject, NSSecureCoding {
> open func readDataToEndOfFile() throws -> Data
> 
> open func readData(ofLength length: Int) throws -> Data
> 
> open func write(_ data: Data) throws
> 
> // etc.
> }
> 
> Much of the work for this is already done, in the swift-corelibs-Foundation 
> project. The main thing that would need to be done for the synchronous APIs 
> would be simply to replace the fatalErrors with throws, a simple enough 
> operation. The asynchronous  read/write APIs are still unimplemented in 
> corelibs, but given that a new implementation of those based on DispatchIO 
> could be engineered in such a way that it would correctly report EOF, the 
> benefits to the end-user would likely justify the expense.
> 
> For backward source compatibility, the existing, non-throwing APIs could be 
> provided as well, but deprecated. These could simply call the throwing APIs 
> and either call fatalError() or throw an NSException when an error is caught.
> 
> Since FileHandle is just a wrapper around a file descriptor, bridging to 
> Objective-C should not be difficult; just use the file descriptor from one 
> side to build a handle on the other side.
> 
> IMPACT ON EXISTING CODE:
> 
> Since the new class would have the same name as the existing FileHandle 
> class, as it is exposed to Swift, this would not break source compatibility. 
> It would break binary compatibility, which makes it a consideration for Swift 
> 4.
> 
> Charles
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Tony Parker via swift-evolution]

> On Feb 14, 2017, at 7:18 AM, Charles Srstka via swift-evolution 
>  wrote:
> 
> MOTIVATION:
> 
> In Swift 3, NSFileHandle was renamed to FileHandle, making it the de facto 
> file handle class for use in Swift applications. Unfortunately, it’s not a 
> very good API. NSFileHandle supports no error reporting whatsoever, instead 
> throwing Objective-C exceptions whenever something goes wrong during reading 
> or writing. There is no way that I know of to catch these exceptions in 
> Swift, meaning that if a write failed because the disk ran out of space or 
> something, there’s no way to deal with that other than crashing the whole 
> application.
> 
> In addition, NSFileHandle’s asynchronous API is broken. It provides a 
> readabilityHandler property which allows blocks-based reading of files, but 
> this handler does not provide any way to detect when the end of the file is 
> reached, which makes it not useful for many applications.
> 
> PROPOSED SOLUTION:
> 
> Rename FileHandle back to NSFileHandle, and provide a Swift-native FileHandle 
> class for Foundation in Swift 4 that mimics NSFileHandle’s interface, but 
> provides throwing versions of all the read and write methods:
> 
> open class FileHandle : NSObject, NSSecureCoding {
> open func readDataToEndOfFile() throws -> Data
> 
> open func readData(ofLength length: Int) throws -> Data
> 
> open func write(_ data: Data) throws
> 
> // etc.
> }
> 

Hi Charles,

For both this and the Process proposal - why would we not just improve the API 
on the existing types instead of renaming them?

- Tony

> Much of the work for this is already done, in the swift-corelibs-Foundation 
> project. The main thing that would need to be done for the synchronous APIs 
> would be simply to replace the fatalErrors with throws, a simple enough 
> operation. The asynchronous  read/write APIs are still unimplemented in 
> corelibs, but given that a new implementation of those based on DispatchIO 
> could be engineered in such a way that it would correctly report EOF, the 
> benefits to the end-user would likely justify the expense.
> 
> For backward source compatibility, the existing, non-throwing APIs could be 
> provided as well, but deprecated. These could simply call the throwing APIs 
> and either call fatalError() or throw an NSException when an error is caught.
> 
> Since FileHandle is just a wrapper around a file descriptor, bridging to 
> Objective-C should not be difficult; just use the file descriptor from one 
> side to build a handle on the other side.
> 
> IMPACT ON EXISTING CODE:
> 
> Since the new class would have the same name as the existing FileHandle 
> class, as it is exposed to Swift, this would not break source compatibility. 
> It would break binary compatibility, which makes it a consideration for Swift 
> 4.
> 
> Charles
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution