Question

I’m declaring:

static NSString *a = @"a";

and this is a correct declaration in iOS6 (it should be more correct to use the compiler version but I do not know it at the moment). I thought that with number literals also:

static NSNumber *b=@1;

could be a valid declaration. Compiler tells me that initializer element is not a compile time constant. This surprises me a bit. Since NSNumber is immutable as NSString and since I’m using a literal as in string case, I thought it could be valid as well.

Does anybody have a reasonable explanation about this difference?

Answer 1

The first line is a compile-time constant since you are assigning @"a" and not something like static NSString *a = [NSString stringWithFormat:@"a"];(That will throw the same error)

But for an NSNumber, static NSNumber *b = @1; is actually equivalent to static NSNumber *b = [NSNumber numberWithInt:1];. For more details check Objective-C Literals.

Note that in the above case, the right side is not a compile-time constant. It is an expression that must be evaluated at runtime. In C and Objective-C, static variables must be initialized with compile-time constants.

If you want to have NSNumber as a const you can check with the approaches mentioned here Objective C – How to use extern variables?.

Also check this on Objective C literals from Mike Ash,

It’s important to note that none of the new literal syntax qualifies
as a compile-time constant.

And,

NSString literals are also compile-time constants, because of a tight
coupling between the compiler and the libraries. There’s a special
NSString subclass called NSConstantString with a fixed ivar layout:

This tight coupling has advantages, like producing legal global
variable initializers, and requiring no extra code to run to build the
object at runtime. However, there are big disadvantages as well. The
NSConstantString layout is set forever. That class must be maintained
with exactly that data layout, because that data layout is baked into
thousands of third-party apps. If Apple changed the layout, those
third-party apps would break, because they contain NSConstantString
objects with the old layout.

If NSArray literals were compile-time constants, there would need to
be a similar NSConstantArray class with a fixed layout that the
compiler could generate, and that would have to be maintained
separately from other NSArray implementations. Such code could not run
on older OSes which didn’t have this NSConstantArray class. The same
problem exists for the other classes that the new literals can
produce.

This is particularly interesting in the case of NSNumber literals.
Lion introduced tagged pointers, which allow an NSNumber’s contents to
be embedded directly in the pointer, eliminating the need for a
separate dynamically-allocated object. If the compiler emitted tagged
pointers, their format could never change, and compatibility with old
OS releases would be lost. If the compiler emitted constant NSNumber
objects, then NSNumber literals would be substantially different from
other NSNumbers, with a possible significant performance hit.

Instead, the compiler simply emits calls into the framework,
constructing the objects exactly like you would have done manually.
This results in a bit of a runtime hit, but no worse than building
them yourself without the new syntax, and makes for a much cleaner
design.