[Second Review] SE-0371: Isolated synchronous deinit

[ktoso (Konrad 'ktoso' Malawski 🐟🏴‍☠️)]

@jrose

Is it possible to block task locals, if they won’t be copied? As if it were always a fresh task?

In a previous review we had pushed for "clear always", which can be done, and was implemented at some point by the author here. A "clear" i.e. isolated deinits NEVER see any task local values has the benefit that at least it's consistent... but it also has the weird implication that normal deinits actually DO see task locals sometimes -- in the same way as the current proposal's isolated deinits, just depending on if they luckily deinitialized in "some" specific task.

There is a long discussion before this second review round about the task locals behavior here: [Sub-Pitch] Task-local values in isolated synchronous deinit and async deinit - #28 by johannesweiss

Though let me just call out the language steering group's request from that thread, as that's what informed the current proposal / implementation (link):

@Jumhyn

The LSG discussed this proposal today in order to determine what we would consider bringing to review, mostly focused on what seems to be the primary remaining point of consternation: the default behavior of task locals. The LSG decided that in order for this proposal to come back for a second round of review, the proposal should remove any guarantees around the availability of task locals within an isolated deinit, regardless of how the call is scheduled. This is the option that 'does the least' both from a performance standpoint as well as from the standpoint of what promises the language makes.

The LSG acknowledged that it is of course possible to construct setups which would potentially exhibit meaningful behavior changes upon adopting isolated deinit, but believes that actual real-world use cases for reliable task local values in isolated deinit would be exceedingly rare and felt that the potential performance impact of messing with the task locals was the weightier concern. And moreover, because isolated deinit requires explicit adoption (as requested after the previous review), users who are concerned about having reliable access to task local values within their deinit will not have behavior change on them unexpectedly.

The LSG also noted that beginning with the behavior that makes fewer guarantees is the more conservative option: if the proposal is accepted, and if usage isolated deinit bears out that there is a strong demand for reliable task local behavior, it would potentially be an option to apply different behavior by default since that would be a 'strengthening' of the contract.

The thread also continues to basically acknowledge that deinits are not good for resource cleanup that isn't just memory anyway, with some good examples listed. As such... I think the "guarantee nothing specific" which is the same that normal deinit does is the least painting ourselfes into some corner approach from all of them.

It's up for discussion, that's what a review is for after all, but I wanted to share that this was discussed a lot already

// That's with my summary of the situation with task locals as "someone trying to shepard this proposal to completion" hat on, who has been following all the discussions.