History: Why does closure syntax use the keyword `in`?

I have a friend who is learning Swift and she doesn’t understand why closure syntax uses the keyword in. Honestly, I don’t understand either. Can someone link to or provide an authoritative answer regarding the choice of the keyword? Thanks!

8 Likes

It's my fault, sorry. In the early days of Swift, we had a closure syntax that was very similar to traditional Javascript, func (arg: Type, arg: Type) -> Return { ... }. While this is nice and regular syntax, it is of course also very bulky and awkward if you're trying to support expressive functional APIs, such as map/filter on collections, or if you want libraries to be able to provide closure-based APIs that feel like extensions of the language. Our earliest adopters at Apple complained about this, and mandated that we support Ruby-style trailing closure syntax. This is tricky to fit into a C-style syntax like Swift's, and we tried many different iterations, including literally Ruby's {|args| } syntax, but many of them suffered from ambiguities or simply distaste and revolt from our early adopters. We wanted something that still looked like other parts of the language, but which could be parsed unambiguously and could span the breadth of use cases from a fully explicit function signature to extremely compact. We had already taken in as a keyword, we couldn't use -> like Java does because it's already used to denote the return type, and we were concerned that using => like C# would be too visually confusing. in made xs.map { x in f(x) } look vaguely like for x in xs { f(x) }, and people hated it less than the alternatives.

105 Likes

No need to apologize; you helped make the greatest programming language ever made. :blush:

I didn’t expect such a fast and detailed response. Thank you!

12 Likes

@fumoboy007, thanks for the question, as it's bugged me since I first saw it.
And thanks @Joe_Groff for the answer; even if I still find the syntax awkward. (I love trailing closures. I just dislike the "in" syntax.)

1 Like

@fumoboy007 When teaching, I explain it as actors (parameters) starring in a movie (block of code). That seems to help students learn/remember the syntax.

24 Likes

I'd love to see a series of short blogposts with background information like this...

8 Likes

A good amount of our early syntax wars is still preserved in the compiler's git history, at least.

3 Likes

There's also an analogy with ML's let x = 42 in .... I was already familiar with that so I guess it has always made sense to me for that reason.

1 Like

True, with capture lists, closures are also secret let-expressions…

5 Likes

I like "starring in" better than the official explanation! :slight_smile:

3 Likes

The entry for this in the changelog is at the very bottom of the file. :slight_smile:

19 Likes

I love the “starring in” approach! I’ve previously explained it as the dramatis personæ of the function, but I think the movie stars analogy works even better.

1 Like

This is a great question and a great answer. For another perspective: I'm very new to Swift and come from Python. I found in for closures confusing because I am used to it being heavily used for testing membership, mainly with iterators.