The reason for deprecating Temporary is that the set of "temporary" errors was extremely ill-defined. The initial issue for https://go.dev/issue/45729 discusses the de facto definition of Temporary and the confusion resulting from it.
Perhaps there's a useful definition of temporary or retriable errors, perhaps limited in scope to syscall errors such as EINTR and EMFILE. I don't know what that definition is, but perhaps we should come up with one and add an os.ErrTemporary or some such. I don't think leaving net.Error.Temporary undeprecated was the right choice, however; the need for a good way to identify transient system errors such as EMFILE doesn't mean that it was a good way to do so or could ever be made into one. On Wednesday, April 20, 2022 at 6:02:34 PM UTC-7 ces...@gmail.com wrote: > In Go 1.18 net.Error.Temporary was deprecated (see > https://go.dev/issue/45729). However, in trying to remove it from my > code, I found one way in which Temporary is used for which there is no > obvious replacement: in a TCP server's Accept loop, when deciding > whether to wait and retry an Accept error. > > You can see an example of this in net/http.Server today: > > https://github.com/golang/go/blob/ab9d31da9e088a271e656120a3d99cd3b1103ab6/src/net/http/server.go#L3047-L3059 > > In this case, Temporary seems useful, and enumerating the OS-specific > errors myself doesn't seem like a good idea. > > Does anyone have a good solution here? It doesn't seem like this was > adequately considered when making this deprecation decision. > > Caleb > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1024e668-795f-454f-a659-ab5a4bf9517cn%40googlegroups.com.