… Ah OK, just forgetting part of the stack (= exceptions as in Java) is not possible because Swift does not have a tracing garbage collector, so failing is the only option so to speak: You try to bring together in Swift a) safeness (being “harmless”), b) efficiency, c) correctness, and d) having to “respect the stack” because of reference counting. Is this the “full picture”?
I would rather dream of a well written, educating, and illuminating official Swift Language Programming Book. 
1 Like
There are languages out there that aim towards this. You might want to look into Haskell for example. However, none is fully "safe". If you want to have more than a toy language, you'll want to offer foreign interface calls towards C or C++, and once you do that, it's over.
Also, while good on paper (i.e. it compiles, it works) it does affect developer friendliness and significantly rises the entry level (because of the constructs you'd need to understand in order to write code in such a language). Simply not a fit for Swift.
2 Likes
I think the official book is already quite good, and you can participate.
(...I was also thinking of contributing some of the bits I learned in this topic to the book, but maybe this is more for someone who knows more about the Swift internals and the intentions. In my last comment I speculated about reference counting — which I think is a very good thing — hindering an “isolation mechanism” akin to Java-like exceptions, but honestly I do not know enough about these issues to be in the positions to inform other people about it.)
Well, I know Haskell and today I am very much opposed to its strict functional idioms. This is a bit another topic than safeness, to my knowledge the addition of two numbers in Haskell overflows silently as in Java. And Haskell suffers a lot from unexpected changes in efficiency when changing the code, that gives you another kind of unsafeness; from what I have read the Swift people work very hard to avoid those traps. What is interesting about Haskell are its variants with dependent types.
Even if you don't know about the compiler internals, you can still contribute to TSPL. Sometimes I specifically avoid reading the compiler source code before I start writing, because I want to document the way something is intended to behave, rather than describing incidental details about how the implementation currently behaves.
6 Likes