Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager via the forum messaging feature. When contacting the review manager directly, please keep the proposal link at the top of the message.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
+1. Swift Testing would very much like to see these changes.
Have you considered ManagedBuffer supporting move-only values? I realize this proposal is primarily focused on ~Escapable, but since it does cover changes that affect move-only types, that seems to be in scope.
Have you considered ManagedBuffer supporting move-only values?
Yes. SE-0437 has already added support for noncopyable elements to ManagedBuffer. The proposal has left a copyability requirement on Header to avoid bincompat trouble; please let me know if that's blocking you.
(As for nonescapable elements: that too would be very much desirable, but unfortunately we generally aren't ready to propose containers of nonescapable types yet. The expectation is that the lifetime dependencies of the elements contained therein would be tracked separately from the container itself. Sadly, we have no way to express that at this time.)
We postpone generalizing most of the higher-order functions that make Result convenient to use, as we currently lack the means to reason about lifetime dependencies for such functions. But we are already able to generalize the two functions that do not have complicated lifetime semantics: mapError and flatMapError.
The transform closure of the flatMapError method can return a new Success value:
let f: Result<Int, any Error> = .failure(CancellationError())
let s: Result<Int, any Error> = f.flatMapError { _ in .success(42) }
Therefore flatMapError might have the same issue as flatMap and map.
Well spotted! @_lifetime(copying self) works for the overall result, but the function argument's result value needs to match that, and we have no way to describe that.
I think we'll need to put off the flatMapError generalization, too. The lack of a diagnosed error is an additional problem.
Sorry to distract from the PR—I look forward to it landing!