or, to put it another way; "optional Optionals, a better <forced unwrapping of 'option'>" :)
Option 1 (1?): Have the compiler/linker enforce that all variables are initialized to zero (Int, Float, Double), false (Bool), empty (String, array, dictionary), or nil (object reference) if the coder doesn't specify them. (in the case of an enumeration, it would either be the 1st enumerated constant, or the one whose raw value = 0; implicitly or explicitly) If i say: var i: Int I should get i = 0 by default, but I could still write var i: Int = 3 if I want i to start with the value of 3. I can even do: var i: Int i = 3 if I want, but at least I won't get a random value (like in C) if I do forget to initialize it myself. There's not really any need for optional values if all variables are always initialized. And - as a programmer - you can always revert to initializing it to a 'canary' value (with an appropriately named constant; no magic numbers, please!) that you can test against after receiving user input, which IMHO, is good defensive programming, anyway. Swift shows promise, but - like all computer languages - it's a trade-off between generated code side, and the amount of abstraction the language presents to those using it, making it easier to turn ideas into code. Making a (more abstract) language unnecessarily complicated with '?' and '!' doesn't seem to be going in the right direction, while making string concatenation less complicated with an overloaded '+' operator does seem to be going in the right direction (now, if we can only make extracting substrings less complicated, that'll be even better! It's currently a pain-in-the-compiler-backend!) Option 2: The other option would be to have methods/functions that return an optional be named in such a way that indicates you're going to receive an optional as a return value. For example: var str = "123" var i: Int = str.toInt() would, on the surface of it, seem fairly obvious. But this is a trap for noobs - .toInt() returns String?, not String, thus you'll get a compiler error. OTOH, if it were called, ".toIntQuestion" as: var i: Int = str.toIntQuestion() // Now it's fairly obvious you forgot the "?" somewhere! then the method name would indicate that you should expect to receive an Int?, making it much more obvious why the compiler is asking if you want to "fix" it by inserting a "?" or "!" Likewise, if a method returns NSTableViewCell!, then it would be named, ".toNStableViewCellBang", or "toNSTableViewCellExclam" (or some such). This isn't necessary with outlets, though, as IB will generate the proper syntax for you if you control-drag from the control to the .swift file; you'll get @IBOutlet weak var tableView: NSTableView! with no muss or fuss, assuming you named the outlet "tableView". _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
