Empty array or nil

[Thomas Wetmore]

I've now ported quite a few thousand lines of C and Objective-C to Swift, enough to detect

patterns. I've tried out coding conventions and so on. I've rejected many and kept a few.

One issue has come up frequently enough to bang me on the head the threshold number

of times to make itself known.

I have gotten very used to optionals now, as they really become a major part of your coding

life with Swift. And many of the methods I have written return optionals to good effect.

But what about methods that should return arrays of objects, and when called, a particular

execution has no objects to return in the array. In this case the programmer has the option to

return either an empty array or to return nil. Looking through my code I discover that I

am doing both with little discrimination as to which is the better (or at least consistent)

approach.

But I like consistency. So I've been going back through and converting all my:

func method (...) -> [SomeType]

methods into

func method (...) -> [SomeType]?

methods. Of course I could go the other way. One criteria I like to use is to choose the

approach the minimizes the number of lines of code that need to be written. It is still

not clear to me which solution meets this criteria better. After a few more thousand lines

of code that may be clearer.

Anyone else come across this issue and willing to share thoughts?

Tom in Massachusetts

[Thomas Wetmore]

And I should say that another criteria I use is to select the approach that minimizes the number

of objects that must be allocated on the heap. This also argues for the [SomeType]? approach.

[Jens Alfke]

On Aug 2, 2014, at 5:14 AM, Thomas Wetmore <ttwet...@gmail.com> wrote:

And I should say that another criteria I use is to select the approach that minimizes the number

of objects that must be allocated on the heap. This also argues for the [SomeType]? approach.

That depends on the implementation of arrays. It’s possible, I think, that a empty array could have no heap-based component, since arrays are now passed by value. (For example, an array reference might be a {length, pointer-to-first-element} structure, where an empty array is {0, NULL}.)

Has anyone deciphered the current array implementation’s data structures?

—Jens

[Garth Snyder]

I suspect that in the great majority of cases, worrying about the overhead of allocating an empty array is a form of premature optimization. 

Even in genuinely performance-critical code, you could return a statically-defined empty array in the case that there are no results. So overall, I'd be inclined to just ignore performance implications. Getting the API right is more important.

Given that, I would avoid returning a nil optional unless that case represents a genuinely distinct situation or result. It shouldn't simply be a stand-in for an empty array. An empty array represents itself just fine.

If you anticipate that callers will have separate code paths for the zero-elements case, you might consider reifying that in the API. For example, if the leaf nodes of a graph are likely to receive special treatment, define an isLeafNode() method rather than making the client call childNodes() and check the length of the returned array.

Garth

On Aug 2, 2014, at 5:08 AM, Thomas Wetmore <ttwet...@gmail.com> wrote:

...what about methods that should return arrays of objects, and when called, a particular

execution has no objects to return in the array. In this case the programmer has the option to

return either an empty array or to return nil...