[Accepted] SE-0343: Concurrency in Top-level Code

[compnerd (Saleem Abdulrasool)]

The review of SE-0343 has concluded.

The feedback was positive, and a small point was raised about how to enable the functionality in a particular condition. The author and core team agreed that there was a better suited command line argument, which is included in the proposal (and implementation).

SE-0343 is accepted.

Thank you to everyone who participated in the review!

Saleem Abdulrasool
Review Manager

[xwu (Xiaodi Wu)]

@compnerd

The feedback was positive, and a small point was raised about how to enable the functionality in a particular condition. The author and core team agreed that there was a better suited command line argument, which is included in the proposal (and implementation)

This information is not glanceable from the accepted proposal text. What is the small point raised, the particular condition, and the better suited command line argument?

[compnerd (Saleem Abdulrasool)]

The small point was the use of -warn-concurrency to implicitly protect variables with the main actor even if no await is explicitly in the top-level code even though it is not an async context.

[etcwilde (Evan Wilde)]

Just extending what @compnerd said, the PR with the change is here.

The short and dirty; with -warn-concurrency, top-level variables are implicitly protected by the main actor, but the top-level is not an asynchronous context. This will alert you to the presence of data races without changing the overload resolution behaviour or implicitly running a runloop.