<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 6, 2016, at 10:30 AM, Don Wills <<a href="mailto:don.wills@portablesoftware.com" class="">don.wills@portablesoftware.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Alegreya-Regular; font-size: 15px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">The cost of !, ? and ?? everywhere in the language is a huge coding and maintenance inconvenience for the programmer error condition referencing a variable that contains the value null.</span><br style="font-family: Alegreya-Regular; font-size: 15px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote></div><br class=""><div class="">It’s not so much about null, as it is about whether a variable definitely contains a value or not. (You can have optionals for non-pointer types like ints.) It’s not what you’re used to. Some Mac/iOS programmers have been complaining because the bindings to Cocoa APIs were suboptimal and exposed a lot of optionals where they didn’t need to.</div><div class=""><br class=""></div><div class="">Basically this argument is like a JavaScript or Python programmer looking at Java or C# and complaining that static typing adds a huge coding and maintenance inconvenience with all those type declarations and casts. No, not really, and it has a ton of benefits to safety; it’s just not what they’re used to.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><span style="font-family: Alegreya-Regular;" class="">The fact that you claim Ints are primitives and Loïc Lecrenier in an email three minutes prior writes "Swift does not have primitives, but I consider that a plus..." Which is it?</span><br style="font-family: Alegreya-Regular;" class=""></blockquote><br class=""></div><div class="">I’m not sure what Loïc meant; maybe he can explain. Ints <i class="">are</i> primitives in that they are basically the same as ints in C or C++. They’re inline values of 1 to 8 bytes size that can be stored on the stack or inside structs/classes. I believe there’s some transparent boxing that goes on if you cast an int type to an Any value, but it’s more common to use generics for this.</div><div class=""><br class=""></div><div class="">Note that an Array<Int> is vastly more efficient than the Java equivalent, because the generated code will store the int values directly instead of boxing them up as objects. That is, a Swift Array<Int> is comparable in implementation and performance to a C++ std::vector<int> or a C int[].</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><span style="font-family: Alegreya-Regular;" class="">Swift doesn't have exceptions? What are the "throws" clause on funcs and the try and throw statements?</span><br style="font-family: Alegreya-Regular;" class=""></blockquote><br class=""></div><div class="">Please read the book! Swift error handling is syntactic sugar around the practice of having a function return a flag value on failure (false / nil / 0 / etc) combined with an ‘out’ parameter that will store an error object describing the failure. There is no stack unwinding going on.</div><div class=""><br class=""></div><div class=""> This convention has been used for a long time in the Cocoa frameworks and Swift basically bakes it into the language syntax, with some improvements. I think it’s an excellent compromise — the typical try/catch exception mechanism is very flexible but makes exceptions very expensive to throw and bloats the code to add all the metadata tables to handle recovery.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><span style="font-family: Alegreya-Regular;" class="">I come from the perspective of 45 years of experience in dozens of programming languages. Swift seems to be trying to be everything to everybody - a bridge from Obj-C, functional, imperative, procedural, object-oriented with a somewhat Java and C-like syntax.</span></blockquote><br class=""></div><div class="">*Shrug* If we’re comparing, I’ve got about 38 years’ experience if you count Tiny BASIC as a language. I don’t see Swift as having a kitchen-sink approach at all; keep in mind that it’s designed by people with a lot of experience designing and implementing languages that are heavily used for very pragmatic application and system programming.</div><div class=""><br class=""></div><div class="">I don’t know if you’ve been following the field of statically-compiled languages, but there’s been a lot of innovation recently after a long drought. Look at Rust and Go, for example. Both are subject to the same objections you made above. I just see it as language designers learning from the past and adopting new techniques that prove valuable.</div><div class=""><br class=""></div><div class="">Anyway, if there’s one thing I can leave you with, it’s: <b class="">Read The Fine Manual</b>. Swift came equipped from day one with a very well-written book that explains the language quite well. I don’t think you’ve read it, or if you did, it was much too quickly, because you’ve missed some fundamental points. There’s nothing wrong with skimming, but it doesn’t give you the authority to dismiss a language outright or make pronouncements about why it’s broken.</div><div class=""><br class=""></div><div class="">—Jens</div></body></html>