[rbehrends]

A list comprehension is basically a cartesian product with a filter and map applied to it.

What we have here is an array constructor, which takes one or more ranges as its arguments. The named `where:` argument provides the filter closure and the final argument is the map, using standard trailing closure syntax.

In fact, other than the missing implementation of the constructor, this would be perfectly legal Swift code today.

I'm not sure what's there to be confused about. `x..<y` describes an open range (including x, excluding y). `{x, y in ... }` is normal Swift closure syntax, where `x` and `y` are the arguments; you can also use positional arguments as in `{ ($0, $1) }` instead.

If the final argument of a function is a closure, it can be (as in Ruby) be written after the closing parenthesis of the function call.

[dozzie]

> A list comprehension is basically a cartesian product with a filter and map applied to it.

Ah yes, explain me more the concept I've been using for a dozen years, surely I don't understand it. And with mix of terminology from as far topics as set theory and functional programming, to lessen the confusion.

> What we have here is an array constructor, which takes one or more ranges as its arguments.

I would never have guessed the arguments thing.

> `x..<y` describes an open range (including x, excluding y).

I would never have guessed it's open range.

> you can also use positional arguments as in `{ ($0, $1) }` instead.

I would never have guessed, and I was writing in Perl with its magic variables for more than a half of my professional career and most of my studies.

And that's the whole point: the syntax is so atrocious that it takes training to understand it. I can accept the semantics to need training to understand (as I did with Perl, Erlang, or now doing with Ada), but with this we haven't hit that level yet.

[rbehrends]

So, your problem is that Swift's syntax in general isn't to your tastes, not the list comprehension proposal as such? Fair enough, but that's not what you were saying.

[dozzie]

> Fair enough, but that's not what you were saying.

Then tell me, what was I saying?

>> I see very little connection, and I've seen list comprehensions in several different languages.

And then...

> So, your problem is [...] not the list comprehension proposal as such?

...you should get off your high horse. Your juggling with math terminology earlier is not impressive. I know you wanted to sound smart, but you overdid it and got smartass instead.

[rbehrends]

> Then tell me, what was I saying?

Let me rephrase then: what you seemed to be saying.

> ...you should get off your high horse. Your juggling with math terminology earlier is not impressive.

I'm not sure where you got that impression. I learned about Cartesian products in high school. Everything else I was talking about is at most first year computer science stuff.

I was simply trying to be precise, using the most basic terminology I could think of.

[coldtea]

>Ah yes, explain me more the concept I've been using for a dozen years, surely I don't understand it.

Apparently you don't, as you appeared confused. Whether it was just the syntax of Swift that confused you, or something more general, the parent was not a medium to know.

In any case, the parent gave a general answer. If you already know some parts of the answer, you can skip them (others might not, and can find it useful) -- no need to be rude about it.

>I would never have guessed the arguments thing.

So? Tons of things a programming language does are not guessable if you don't know its semantics, and even less so if you also don't know its syntax. That doesn't even make them bad or difficult, just not already familiar.

>I would never have guessed it's open range.

I would. .. and ... are very common ways to describe ranges, and < is a logical thing to use to say it's open given its math meaning.

>I would never have guessed, and I was writing in Perl with its magic variables for more than a half of my professional career and most of my studies.

Well, I would have guessed all 3 of them. $0, $1 and the like are quite common, and at that place they couldn't be anything else but positional arguments.

>And that's the whole point: the syntax is so atrocious that it takes training to understand it.

Or it's so good that it takes training to understand it, as opposed to catering to the lowest common denominator of what people can immediately "guess".