It’s a very good point I haven’t seen at first glance. Therefore, how about
making the . optional in scenarios where the compiler can safely infer the
chain:
someArray.map {
…
} filter {
…
} flatMap {
…
}
// and
someArray.map { … } filter { … } flatMap { … }
And still keep the . otherwise:
someArray
.map { … }
.filter { … }
.flatMap { … }
Besides, I’m only talking about the chained closures. Removing the dot in other
scenarios is not part of this talk.
Plus I know such additional sugar changes are on the bottom of the list. I
didn’t want to forget the idea until it’s time to discuss things like that.
--
Adrian Zubarev
Sent with Airmail
Am 29. August 2016 um 05:17:49, Xiaodi Wu ([email protected]) schrieb:
What problem are you trying to solve by proposing this change? It seems like it
would get very confusing to read, so without a compelling use case I don't
think this would be a good idea.
Further, more often than not, chained closures like this are on separate lines
(at least how I use them, which I don't think is rare), and this change could
not possibly work in that coding style. This means that if your proposal were
adopted, the resulting code would be more brittle because a newline would break
the code where previously it didn't. So I'd be -1 for this change.
In any case, sugar is really low on the list of priorities, even for the next
stage of Swift evolution. Let's focus our attention on the priorities already
identified for this release, which would be a *huge* advancement if they get
accomplished.
On Sun, Aug 28, 2016 at 1:15 PM, Adrian Zubarev via swift-evolution
<[email protected]> wrote:
This is a small pitch for stage 2 (or even another Swift release, if the
community likes this change).
We all love the trailing closure plus the ability to execute the next method
with another trailing closure.
someArray.map { … }.filter { … }.flatMap { … }
Wouldn’t be great if we could remove the leading . after the trailing closure
to get similar syntax to if bool { … } else { … }?
someArray.map { … } filter { … } flatMap { … }
--
Adrian Zubarev
Sent with Airmail
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
