Okay. Konrad has asked to make some revisions to his proposal before the second review goes on for much longer. The Core Team has decided that the best thing to do is to accept those revisions and extend the review by a week, until May 11th.
The basic thrust of the revisions is to adopt a more natural use of property wrappers. This means that you can declare a task-local with something like @TaskLocal var foo: Int? and read it with foo. To do a write you will have to use API on the projected value of the wrapper, as in $foo.withValue(newValue) { ... }. You can find the exact revisions here.
This is an unusual review process which I think the Core Team will try to learn from and not repeat. We were too hasty to put the proposal back in review after the first major revision; in retrospect, it should have gone back to pitch until the design felt a little more "baked". The Core Team has a responsibility to make good use of reviewers' time, and that starts with ensuring that proposals stake out a reasonably defensible position in the design space — a position that the proposal won't be immediately chased out of. That's not to say that proposals have to be flawless; after all, we're asking for feedback on them for a reason. But to gather good feedback, proposals need to be good enough presentations of their central ideas that reviewers can focus on the quality of those ideas and the details of the design. Otherwise, feedback turns into confusion, and it becomes hard to determine whether people are unhappy with the fundamental ideas or just unhappy with how they look right now in the proposal.
So I'd like to apologize for putting SE-0311 back in review too quickly, and I'd like to thank reviewers for their patience in helping us see our mistake. The proposal now seems to me to be in good enough shape for the review to continue.
John McCall
Review Manager