Swifty Encounters[4]: Tuple surprises

Most of us who like to explore languages do love surprises. Exploration is all about surprises, right? However, software development is something beyond mere exploration (I’d like to say it is about create arenas for others to explore. Best practices of software development advocate the principle of least astonishment to reduce complexity. The WYSIWYG principle is like a corollary to the least surprise principle.

There was one feature in the Swift language which did take me by surprise and I loved it too. When it came to function application, a list of N arguments was equivalent to a N-tuple, provided the types matched. To a function taking three Ints, you could pass 3-tuple of Ints.

But for this feature to work, you’d need to use the _ extensively to have “nameless” arguments — which kind of hurts the Swift/ObjC philosophy.

The same “surprise” applied to closures. This is a reverse example — to a function taking a 3-tuple, you can pass 3 arguments of matching types.

Though such code compiles in Swift 2.2 with warnings, there has been an effort to cut down the surprise factor. For Swift 3, this proposal removed the implicit tuple splat — a tuple matching the argument list. The removal proposal describes this feature as:

“… syntactic sugar with no expressive ability …”

I agree. There is no value added by this feature.

When it comes to closure, we need a way to distinguish an argument list from a tuple. As of today, an argument list is (T,U,V) and a tuple also is (T,U,V). This new proposal provides a fine way of distinguishing argument lists from N-tuples. A tuple is wrapped in another set of parantheses.

I just love the way Swift is maturing. Happy Swifting!