What is your evaluation of the proposal?
Positive yet the proposal lacks ambition.
This is a "nudging" proposal, which aims at teaching users that some apis should not be used from async context, hoping:
- Users are lucky enough to call those apis right from the body of an async function, see the compiler error, and learn.
- Users remember to not use those apis in sync functions as well (but this time without compiler guidance)
- Users look for calls of those apis in their code base in order to spot misuses that compiler could not catch.
- Users infer from a compiler error on, say,
pthread_mutex_lockthat there exits other such apis, search for their list somewhere on the Internet, and apply steps 2 and 3 to those apis as well. - Sometimes those apis are hidden in third-party code, and it is impossible to locate the wrong uses. Instead, the third-party has to consider that their public apis may be used from async contexts, apply step 4 on their whole code base, tag their public apis accordingly, and update their own documentation so that step 4 can be run on it.
That's a lot of hopes.
And step 4 implies the need for a place somewhere in the Swift documentation(s) for the list of those apis.
Do we favor Documentation or Luck?. This is the crux of the issue.
For example, I'm amazed by how lucky I am I could stumble on the list of apis that create priority inversion problems, after so many opportunities for reading "don't do that this creates priority inversion", without any further guidance. "Don't do that" is not helpful. The problem to solve is still there even after I'm told that I don't solve it well.
Is the problem being addressed significant enough to warrant a change to Swift?
IMHO, the problem exists, but requires documentation improvements, more than compiler guidance. Compiler guidance can surely help, though.
Does this proposal fit well with the feel and direction of Swift?
Weak guards are uncommon in the language.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I'm in favor for slight touches of nudging, but in this case, the proposal relies much too much on luck, and does not mention the documentation updates it requires for achieving any efficiency at solving the problem it claims to address. I'm afraid we'll "call it a day" after this proposal is implemented, when, in practice, the situation would not be much better at all.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Just enough experience with nudging apis to recognize one when I see it, and understand some consequences.