Erica Sadun

Where technology meets something or other

Style: How would you fold this?

Here’s the stdlib implementation of zip:

public func zip<Sequence1 : Sequence, Sequence2 : Sequence>(
  _ sequence1: Sequence1, _ sequence2: Sequence2
) -> Zip2Sequence<Sequence1, Sequence2> {
  return Zip2Sequence(_sequence1: sequence1, _sequence2: sequence2)
}

So once again, I’m trying to figure out how I would fold this rationally. I’m not a huge fan of the parameter list on a single line like this, especially when there are both external (_) and internal labels involved, generic parameter types, and a complex return type.

I was thinking of something more like this:

public func zip<Sequence1, Sequence2> (
    _ sequence1: Sequence1,
    _ sequence2: Sequence2
)
    -> Zip2Sequence<Sequence1, Sequence2>
    where  Sequence1: Sequence, Sequence2: Sequence
{
    return Zip2Sequence(_sequence1: sequence1, _sequence2: sequence2)
}

This update moves each parameter to its own line and splits off both the return type and the constraint clause. What do you think? How would you personally fold it? Let me know and thanks.

Tweet this Post

6 Comments

  • Probably like that but the opening curly on the where line.

    • By Bas

    • I’d put the closing parentheses on the end of the previous line, but not the curly bracket. I would never want to hide the boundary between a function’s signature and the start of its statements.

  • Not sure if you were hoping for a response in comment form 🙂

    public func zip(
    _ sequence1: Sequence1,
    _ sequence2: Sequence2
) -> Zip2Sequence {
    return Zip2Sequence(
        _sequence1: sequence1,
        _sequence2: sequence2
    )
}
    • By Sasha

  • A one-line function containing 18 instances of the word “Sequence”, I’m wondering if that says something bad about Swift. Wasn’t one of the goals of the language and its style conventions to somewhat minimize repetitions of type names? I guess the generic types could be named to something like “S1” & “S2”, parameters similarly “s1” & “s2”, reducing 18 to 5, but is the end result an improvement? Not sure I have a point.

  • I use exactly the same style.

  • I’m with smallduck on this one. People talk about angle bracket blindness, but I think the leakage of signatures like _builtin2048piURLThunk: _underscoreInternalBoxWrapperImpl into the standard library’s public API is really ugly.

    Those signatures really hit home when Xcode suggests all 20 inherited-protocol implementations of nearly the same function with slightly different semantics and/or naming conventions, and they all include their generically-typed arguments in the autocompletion menu instead of the actual dynamic type (e.g. func reverse(_arg1: AnySlice) instead of func reverse(colors: Slice)).

    Don’t get me wrong, I’ve really loved learning, working, and playing with Swift (barring my everlasting 3.0 migration problems ????), but there are a few design decisions that I just don’t understand. But then again, my path to Swift was mostly web and server-oriented (HTML ~> CSS ~> JavaScript ~> PHP ~> C# ~> Python ~> Ruby ~> Objective-C ~> Swift), so maybe I just don’t understand the complexities of “real” programming languages (I mean, I’ll admit it: reading a few lines of C++ makes my head swirl).

    Also, am I alone in wondering why Swift 3 introduced the global type(of:) function to access the dynamic type of a value? In Objective-C, accessing an object’s dynamic type (or class, I guess) was short and sweet: `self.class`. Boom! You now have access to all your static class methods, and your class names can easily be changed without too much refactoring. In Swift 2.x, it was pretty easy, too: `self.dynamicType`. Boom! You’ve got your static properties, methods, et al. Now, in Swift 3.0, instead of naturally accessing the dynamic type with . notation, I have to pull out my JavaScript hat, and awkwardly spell out type( (with no help from Xcode’s autocompletion), followed by a pointless of: argument label, then my variable self.children, and finally, the closing parenthesis ). If I wrote my own programming language, I’d definitely opt for a built-in keyword at least, instead of polluting the Swift namespace with a free-floating function.

    As I said, I don’t know the first thing about building a lexer, parser, or compiler, but I can’t help but think that Apple has a few brilliant people working for them (as well as an awesome open-source community) that could probably fix some of these oddities. Oh, well …