cc @Sajmani

This seems reasonable, though I'd leave the error text unchanged to avoid breaking anything that tests for it. We can still arrange for the returned error to wrap context.DeadlineExceeded so that the errors.Is test works.

Change https://go.dev/cl/433136 mentions this issue: rate: make errors.Is(err, context.DeadlineExceeded) work for lim.Wait errors

Retitled, but one problem with this proposal (or at least the implementation) is that sometimes Wait returns an error because it knows that waiting would exceed the deadline, but the deadline has not been exceeded yet. So if we make the change in the CL, Wait(ctx) might return something that Is(DeadlineExceeded) even if ctx.Err() == nil (!= DeadlineExceeded). That might be confusing.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

@GODCALLMEGOD why do you want this error to change? What is the use case?

There is a subtle difference between the current "would exceed context deadline" and the suggested change to DeadlineExceeded, which means "did exceed context deadline". It's not clear to me that we should return the latter for the former case.

In the absence of a compelling reason for the change, this seems like a no. It seems like a mistake to say the deadline is exceeded when it has not yet been exceeded. It would be wrong for code to see DeadlineExceeded and then abort other parts of the work, for example.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group