[Pitch] [Stage 2] [Additional] Remove leading dot after closures

Evolution Pitches
1

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

2

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 < swift-evolution@swift.org> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

I’m sorry, but Stage 2 proposals are out of scope for right now, and syntactic sugar changes like this are the lowest priority to consider.

-Chris

···

On Aug 28, 2016, at 11:15 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

This is a small pitch for stage 2 (or even another Swift release, if the community likes this change)

4

While I kind of like the idea of effectively rolling my own keywords, my personal preference is to remain explicit about the fact that this is a method of something.
I don't know if I'm against the idea, I just don't think I'd use it.

···

On 28 Aug 2016, at 19:15, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> 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
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

5

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 (xiaodi.wu@gmail.com) 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 <swift-evolution@swift.org> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

6

This would be fairly inconsistent. I’ve never seen swift syntax with semantics that are dependent on the formatting.
David.

···

On 29 Aug 2016, at 10:10, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

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 (xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>) 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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution