Why does NSArray arrayWithObjects require a terminating nil?

Question

I understand that it marks the end of a set of varargs, but why can't it be implemented in such a way that doesn't require the nil?

Answer 1

Any varargs function requires someway to know how many parameters are present -- if you don't nil terminate, you would just need something else. In this case the obvious alternative is a length, but then you'd need to update the length argument everytime you changed how many items were in the array, and that could be cumbersome, or worse broken.

I am guessing you have an array that may contain nil?

Answer 2

OllieJ is correct. Keep in mind that obj-C is a proper superset of C. What you're suggesting is introducing a special case in the compiler where it has to care what class and selector you're using.

Answer 3

It all has to do with the C calling ABI.

Consider these methods:

- (id)initWithFormat:(NSString *)format, ...;
+ (id)arrayWithObjects:(id)firstObj, ...;
+ (id)dictionaryWithObjectsAndKeys:(id)firstObject, ...;

The ... tells the compiler that a variable number of arguments of any type may be present. There is no way for the compiler to know what those types are required to be (the real definitions have markers that help with that).

Now, consider the three methods. All three have vastly different requirements for what might be present in the variable argument list. An array must be a bunch of objects followed by a nil. The dictionary requires a bunch of pairs of objects followed by a nil. Finally, the string method requires a bunch of arguments that match the types in the format string.

All of these behaviors are directly tied to the method being invoked and, if the author of an API decided to go for "hard to use", the behavior of decoding the variable arguments could be modified at runtime, just to make life difficult.

Bottom line: The C ABI doesn't have a syntax that allows for specifying that a method or function takes a variable number of arguments with any kind of set of constraints on the arguments or their termination.

Objective-C could change the rules just for method declarations & invocations, but that wouldn't help with C functions or C++, both of which Objective-C must remain compatible with.

Answer 4

@bbum gives some great technical details. Here are some thoughts on the practical "why don't they fix it?"

Remember: C is just assembler and Obj-C is just C... It could be redesigned of course, but there's almost no pressure to do so. You still couldn't put nil in an array (that would require a huge change). The compiler now warns you if you forget the nil, so it's not something developers complain a lot about. The trade-off is keeping the language much (much!) simpler than its kin, getting the benefits of decades of C-compiler optimizations and guaranteed compatibility with C code.

One thing that should become clear from @bbum's discussion: NSArray is not a language feature of Objective-C. C-arrays are a language feature, but NSArrays are just another object, no different than the objects you write.

Answer 5

I just wonder how [NSString stringWithFormat:(NSString *)format, ...] works? I never put nil as a last argument in it! May be it counts argument placeholders in format string?

Answer 6

Objective c actually passes hidden arguments after your arguments like "self", so the nil terminator really shouldn't technically be required for most applications, as proven by NSString's +stringWithFormat:format,... method. As for how to implement something like stringWithFormat, I hope that someone posts an answer. There are various workarounds, but my current favorite is good for apps more than for released frameworks. Accept an NSArray in your method instead of "...", and then fill it with the convenience macro below, which is placed in your prefix file or utility header.

#define $array(objs...) [NSArray arrayWithObjects: objs, nil]

It'll allow for multiple well labeled variable length arguments and you'll free yourself from the archaic pattern of having to use the first argument and then va_list and its brothers in favor of a for-in loop or the many other collection tools available.

[self findMatchingSetAndAlert:@"title" ties:$array(tie1, tie2, tie3) shirts:$array(shirt1, shirt2, shirt3, shirt4)];

If someone knows how to implement a non-nil-delimited list such as stringWithFormat, please let us know! It uses attributes and macros or something designed specifically for formatting, but those are implemented somehow.