[Accepted with Modifications] ST-0008: Exit Tests

Evolution Announcements
1

Hello Swift Community,

We recently concluded the second review of ST-0008: Exit Tests that ran from April 10 through April 21, 2025. The second review focused on the naming of the label in the #expect macro. Although the community was unable to come to a consensus about what the label should be called, it did provide valuable insights and feedback.

With that in mind, the Testing Workgroup has decided to accept this proposal with modifications. Notably, we will retain processExitsWith: for the parameter label of the new #expect and #require macros as stated at the start of the review as the preferred option from the workgroup.

Feedback on naming of the label
The alternative labels that were suggested from the community tended to prefer either a noun (exit: , result:, status:) or a verb (terminates:, reports:, exits:). Variants of both tended to get likes and support as well as counter suggestions. Within the workgroup we noticed that we liked many different suggestions and could see the pros and cons of all. This for us showed that there are multiple strong alternatives.

Why #expect(processExitsWith:)?
The workgroup unanimously feels that this name best describes what the test expects/asserts while still reading fluently and being 'code completion friendly'. In particular:

  • It includes the word "process" which helps users understand its closure runs in a separate process;
  • It reads fluently to the workgroup members in all anticipated usage scenarios;
  • It is in line with the precedent set by #expect(throws:)

Other changes/suggestions that have been incorporated in the modified proposal
The second review round led to the following modifications:

  • Rename StatusAtExit to ExitStatus;
  • Update the Alternatives considered section to discuss crashes: as a label. We don't think this is a good idea as the trailing closure label can always be omitted and providing a way of mandating it is outside of the scope of this proposal;
  • Update the Alternatives considered section to discuss ExpressibleAsIntegerLiteral conformance for ExitStatus. We don't think this is a good idea as it defeats strong typing support and will lead to confusion when you can't use a variable/constant to describe an exit code or signal.

And the following modifications based on the first review round:

  • Support for more platforms won't require additional review;
  • Update the Alternatives considered section to discuss test-skipping instead of availability annotations.

Proposal author participation in review topics
Finally, within the workgroup we discussed how we can foster a generative discussion about proposals. Especially when it is written by a workgroup participant, as is the case for ST-0008. After discussion we came to two measures that are in effect immediately:

  • @grynspan volunteered to abstain from voting on his own proposal. We decided to all adopt this policy going forward;
  • When a review topic is underway, workgroup members whose proposals are under review will hold back in immediately responding to feedback, but take some time for the community to discuss first. That way more insights become available. The author can then still provide feedback on the broader discussion and/or indicate how they will (or will not) incorporate feedback into their proposal.

Over the next reviews we'll see how these measures play out. And we are always open to feedback.

Thank you to everyone who contributed to this review, helping us enhance Swift as a programming language!

Maarten Engels
Review Manager

16 Likes