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

[Rod Brown]

Sent from my iPhone
On 12 Jul. 2016, at 6:19 pm, Goffredo Marocchi <panajev at gmail.com> 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 <swift-evolution at swift.org> wrote:
>> 
>> After all… you clearly don’t know about your current state, so how can you know how to correctly recover from it?