Ooh, that's a weird one. Are we using the Self context to choose overloads even when not calling a method on a Self value? cc @moiseev, @xedin

Comment by David Plunkett (JIRA)

I did some more digging and realized it's because I'm not annotating the transform parameter as @escaping. Since lazily applied closures would naturally outlive the initial call, the non-escaping argument means that it's forced to choose the non-lazy version of `map`. I assume lazy sequences provide a non-lazy map because it was desired to provide a rethrowing `map`, which means it must be non-lazy. But one might assume there's no such thing as a non-lazy `map` on a lazy sequence, as I did.

Comment by David Plunkett (JIRA)

Since this seems like an API design detail, and not a bug, I'll close this.

Comment by David Plunkett (JIRA)

Actually, my guess about a rethrowing map being necessarily non-lazy seems wrong. I don't know why there's a non-lazy map, or why there appears to be no non-lazy version of `map` that rethrows. But I guess this is still API design territory, and not a bug?

dbplunkett (JIRA User) consider the lazy map, accepting a throwing closure. Where will you actually put a `try` in this case? In case of an eager `map` that returns an array from a sequence, the answer is straightforward: you `try` right there where you call `map`. For a lazy – not so much. It is one of those unfortunate instances where behavior is different depending on `throw`-ingness of a closure.

Comment by David Plunkett (JIRA)

Ah, of course. Thanks for the explanation. I do wonder if lazy sequences should define eager operations at all then - forcing the user to turn it into a regular sequence before performing an eager operation.

That is an interesting design question. But first and foremost, can you define what you mean by "lazy sequence"? Oh, and BTW, for the benefit of the community, how do you feel about moving this discussion over to the forums? Maybe into "Using Swift" category.