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 > <[email protected]> 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 ([email protected] > <mailto:[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] <mailto:[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] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
