[potlee]

Some nice improvements but could have really used a syntax for anonymous functions that makes.

Why did they choose this wierd

{ parameter in doSomething(parameter) }

syntax?

[nielsbot]

I think Swift's philosophy is to use keywords when possible instead of symbols, for better typability.

[thedjinn]

Looks fine to me. What's wrong about that syntax?

[Groxx]

Feels backwards to me, at least as a gut feel.

    groceriesByDepartment.mapValues { items in items.count }

vs e.g. Ruby (or at least close, it has been a while):

    groceriesByDepartment.map { |item| item.count }

The "in" makes it feel like you're calling "items.count" on...? and then getting the "items" from it (since it sorta implies that items are in items.count, which seems like nonsense).

E.g. this reads more naturally to me:

    groceriesByDepartment.mapValues { item.count in item }
    otherStuff.do { a.value + b.value in a, b }

which would also move the "what it does" further to the left, rather than having to skip over the argument names (which are frequently obvious in context, and/or something trivial like "it" or "item" or "x").

---

That said, if you consider it as "use 'items' in [a block of code]" it basically makes sense, and I could probably learn to stop worrying, and love the syntax.

[Camillo]

I agree, the examples in the article look terribly confusing. And they're inconsistent with Swift's own for loop syntax: https://developer.apple.com/library/content/documentation/Sw...

    for item in groceries { print item.department }

versus:

    Dictionary(grouping: groceries by: { item in item.department })

The people who chose this syntax probably said "hey, it's VARIABLE in EXPRESSION, same thing right?". But the semantics are completely different!

In the for loop it's "for PRODUCT in SOURCE": the expression is evaluated first, and the variable is assigned with each of its items in turn. In the lambda or whatever it is, it's "{ SOURCE in PRODUCT }": first the variable is assigned, then the expression is evaluated based on it. The data flow is the opposite!

This is just objectively bad language design.

[smitherfield]

I prefer Ruby's syntax too, but Swift also has a shorthand version which is, IMO, usually nicer.

  groceriesByDepartment.mapValues { $0.count }

[Groxx]

stuff like this always makes me miss Ruby's even-shorter-hand version though :)

  groceriesByDepartment.mapValues(&:count)  # not ruby, but meh

[jakobegger]

The shorthand version doesn‘t let you specify argumen types (only works when they can be inferred)

[mantas]

Which is vast majority of cases. Unless you work with a lot of legacy ObjC code.

[BillinghamJ]

Well, for starters, what does it mean? I haven’t seen that in any other language.

[pjmlp]

It is similar to let var=..... in exp from ML languages.

[sizeofchar]

Haskell have let-in expressions, I think it is the inspiration for swift in this case.

[amorde]

You can also shorten it to:

{ doSomething($0) }

[slavapestov]

Or just

doSomething

[reednj]

I wasn't aware of that syntax? It will just pass the arguments from the parent to the child in order?

[jayrhynas]

As long as the signature of the function matches you can pass it in directly

[slavapestov]

Functions are values in Swift. Closure literal syntax is just a shorthand where you don’t have to name the function first.