Complete(?) the multiple trailing closure saga by allowing a label on the first

[CTMacUser (Daryle Walker)]

Continuing the discussion from SE-0286: Forward Scan for Trailing Closures:

@xwu

(If we had the option of labeling the first trailing closure, then the warning could then be silenced by explicitly labeling, but we don't have that option at least currently.) For now, the warning can be silenced by not using trailing closure notation.

Is anyone working on this? Hopefully to be reviewed and added by the time 5.3 comes out of beta, where no regular user knows that the multiple trailing closure feature came in multiple steps (SE-0279, SE-0286, and this idea). It has to work when there is only one trailing closure too, of course.

[Jon_Shier]

I don't think so. It was pitched but it doesn't seem like there's any support (ATM) from the core team. SE-0279 explicitly wanted to match the single and multiple closure syntax in having the first closure be unlabeled, and they're sticking to it. SE-0286 is a fix for the worst of the backward scan rule 0279 had, but it seems they're going to far enough to prevent usability issues discussed in various threads.

[xwu (Xiaodi Wu)]

@CTMacUser

Is anyone working on this? Hopefully to be reviewed and added by the time 5.3 comes out of beta, where no regular user knows that the multiple trailing closure feature came in multiple steps (SE-0279, SE-0286, and this idea). It has to work when there is only one trailing closure too, of course.

There is nothing to work on. The proposal PR is ready for merging and review at any point that the core team so chooses. The companion implementation was fully working at the time the PR was put up, but now would need a minor rebasing given recent developments in this area. Of course, I'm not going to do any rebasing as it would only go stale again unless there is movement to put the proposal up for review.

[CTMacUser (Daryle Walker)]

For reference, where is the proposal PR and sample implementation? (And did you do said implementation, but not the proposal?)

[xwu (Xiaodi Wu)]

I did the whole shebang.

Support use of an optional label for the first trailing closure

The core team has asked that discussion be spawned in a separate thread regarding support for use of an optional label for the first trailing closure. Therefore, later today, I'll be sharing a draft proposal here which addresses that topic. While it has been brought to mind by discussions on multiple trailing closures, the issue is entirely a separable one. Shortcomings related to our unlabeled trailing closure syntax have been known for years. Readers will note that the draft proposal is ampl…

[Proposal] Support use of an optional label for the first trailing closure

[Proof of concept] Support the use of optional labels for the first trailing closure

[filip-sakel]

As I see it the proposed feature is very useful to API authors and would complete the complicated story of trailing closures. This simple feature would make trailing closures easier for beginners to grasp and overall more intuitive - IMHO. The Core Team seems to consider trailing closures an important feature as they rushed to push Forward Scanning which also improves intuitiveness.

So is the @core-team willing to propose a counter-proposal? @xwu’ proposal has been well-received by the community, however the Core team seems to prefer attributes to the above. To be fair, in the Principles for Trailing Closure Evolution Proposals, the Core Team outlined some possible solutions to address the issue at hand. There has, though, not been a pitch from the Core Team to outright support one of the aforementioned solutions. All in all, I think some discussion with the Core Team - and especially @Ben_Cohen - who was quite active in the “Principles ...” discussion - is integral to complete the feature-set of Trailing Closures in 5.3 as opposed to waiting and causing further confusion in future language versions.

[Douglas_Gregor]

@filip-sakel

So is the @core-team willing to propose a counter-proposal? @xwu’ proposal has been well-received by the community, however the Core team seems to prefer attributes to the above. To be fair, in the Principles for Trailing Closure Evolution Proposals, the Core Team outlined some possible solutions to address the issue at hand. There has, though, not been a pitch from the Core Team to outright support one of the aforementioned solutions. All in all, I think some discussion with the Core Team - and especially @Ben_Cohen - who was quite active in the “Principles ...” discussion - is integral to complete the feature-set of Trailing Closures in 5.3 as opposed to waiting and causing further confusion in future language versions.

I don’t know why you’re seeking a counter-proposal here. SE-0286 is there to fix outright problems with SE-0279. It has no attributes, and gives no opinion on labeling the first trailing closure argument. It makes it easier to do any of those things in the future, post-5.3. There is no rush; we can live with SE-0286 for a while.

Doug

[filip-sakel]

I see your point; you’re right, the SE-286-style trailing closures will be a big issue improvement to the current TC design while allowing room to grow in the future. Still, though, I think it would be great to see a discussion focused just on how the Core Team views future TC design - in regard to the first argument label feature. I propose that, as in the Principles discussion, the Core Team seemed to support an attribute-based system, contrary to the community-preferred label-based one, however this wasn’t the main issue of the discussion. As you said “there is no rush”, but a discussion with the Core Team would be really insightful as any language change is ultimately approved by them.

[Douglas_Gregor]

@filip-sakel

the Core Team seemed to support an attribute-based system, contrary to the community-preferred label-based one

This framing is neither helpful nor accurate. The discussions of multiple trailing closures were exhausting for the community, with many hundreds of messages in the review and pitch threads. You cannot get an accurate read on support for a counter-proposal from that much signal. I am concerned that the relatively low volume of feedback on SE-0286 is a symptom of, effectively, collective burnout on this topic.

The Core Team has said they are not going to bring the optional-first-trailing-closure proposal up for a review now. It is time to go and use Swift 5.3, with SE-0279 and maybe also SE-0286, to learn where the remaining problems lie. The base state is no longer pre-SE-0279 Swift, but SE-0279 + (maybe) SE-0286, and that is not something that is fully understood as yet.

Doug