On May 14, 2015, at 09:50 , William Squires <wsqui...@satx.rr.com> wrote: > > 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)
The problem being solved in Swift is to *eliminate* the brute-force initialization of instance variables. That’s in part because the Obj-C standard of getting all-zero-bits isn’t necessarily the correct value in all cases, and in part because the zeroing is duplicative when there is code to initialize ivars explicitly too. You may think this duplication is minor, but it starts to matter when the language (e.g. Swift) has “value classes” (i.e. structs that can have initializers and methods). In that case, there can be a lot of creating new struct instances, and it’s desirable to avoid emitting code for unnecessary initializations. > There's not really any need for optional values if all variables are always > initialized. I think you’re utterly wrong about this. Optionality is not just about making sure that variables are initialized. It’s also about introducing a language construct that expresses the fact that some variables don’t always have a value. For example, you can’t put nil pointers in a NSArray, which means you can’t easily have a sparse array. Similarly, you don’t have a direct way of expressing the fact that a function might return a value or not. This is not about initialization, it’s about optionality of values, so why not have optionality as a first class language concept? > 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. Yes, we have [NSNull null] and NSNotFound, for example. However, these are *terrible* solutions to the problem — though the only solution Obj-C has, so they don’t always seem terrible when you’re used to them. The problem with [NSNull null] is that it has the wrong class. That means you always have to code around it. NSNotFound has several problems: — You don’t (officially) know *where* in the range of possible integer numbers it is, so you don’t know when calculations near that value are dangerous — It’s used in both signed and unsigned contexts, so it really has 2 values — Archiving a variable with the value NSNotFound is dangerous, because it’s not 32/64-bit agnostic. That is, if you archive it when NSUInteger is 32 bits, and unarchive it when NSUInteger is 64 bits, it’s not going to be NSNotFound any more. _______________________________________________ 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
