Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

Tue, 12 Jul 2016 01:48:07 -0700 


Sent from my iPhone
On 12 Jul. 2016, at 6:19 pm, Goffredo Marocchi <[email protected]> wrote:

>> After all… you clearly don’t know about your current state, so how can you 
>> know how to correctly recover from it?
> 
> This a bit of a stretch, it is often the case but      not a necessary 
> conclusion. Both C++ and Java have a model where it is not uncommon to 
> recover from exceptions instead of crashing. You might know enough about your 
> context to be able to go back to a safe point in time/app lifecycle and 
> resume from there. 

I was not meaning to state that as an absolute, but as a generalisation. As I 
mentioned later, I do have cases where it's appropriate to use an ifExists 
subscript.

That said, Swift's safety isn't generally built around "safe from crashes". 
After all, unwrapping an optional in Swift is a fatal error, and sending a 
message to nil in Obj-C is a no-op! So Obj-C is safer! ... um... no. It's safer 
in that it forces you to reason about your code rather than letting nil be 
no-op. That sounds remarkably similar to making someone reason about accessing 
an array and crashing, rather than just letting it be a no-op.

You'll also notice that Swift doesn't have the exception handling that C++ and 
Java do, as you referenced. Again, this appears to be in the same train of 
thought: if you've met an exception, you didn't reason about your code, and the 
safest thing to do is quit. Swift does have error handling, on the other hand, 
understanding that errors can occur that are not related to inconsistent 
reasoning about your code.

Are there ways you could recover? Sure, in some circumstances. I could say the 
same thing about incorrectly unwrapping nil, or any other error of logic. I 
think Swift comes down hard on the side of "if there are errors in logic, just 
crash now, it's the best overall choice."

Do I agree with it? Personally, I do, as I think it's a pragmatic decision 
overall. I can definitely see why others may disagree, and please feel free to 
add ifExists subscript in your projects like I have.

> 
> Also, the more scenarios we want to code in pure Swift in the more cases in 
> which other languages offer features we do not want in Swift now we are going 
> to encounter. The pragmatic voice in engineers will start asking "why do I 
> need to jump through hoops for purity's sake"? 

I don't think this is a purity issue. It seems pragmatic to crash as it's 
almost always a programmer error that would cause this situation. A simple 
check on count would fix this in any other cases. Encouraging people to Handle 
programmer errors rather than simply Fix them seems rather odd to me.

> 
> Sent from my iPhone
> 
>> On 12 Jul 2016, at 09:10, Rod Brown via swift-evolution 
>> <[email protected]> wrote:
>> 
>> After all… you clearly don’t know about your current state, so how can you 
>> know how to correctly recover from it?
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution





























					Reply via email to