I don't really get it. The current documentation says that bespite err!=nil, some data may be read (n!=0). If one obeys this rule, then it will consume the data, then handle the error.
If we change then io.Reader's documentation (and all std lib implementations)... Ok, now I may be understand: If an io.Reader implementation obeys this stricter rule, then it would become wrong with the new (lax) rule... What about some documentation and an "func io.Read(io.Reader, p) (int, error)" wrapper function that caches the error and only returns err!=nil iff n!=0 ? But this maybe just complicate things? Diego Joss a következőt írta (2024. március 25., hétfő, 10:16:43 UTC+1): > Hi > > On Thu, 21 Mar 2024 at 19:23, 'Christian Stewart' via golang-nuts < > golan...@googlegroups.com> wrote: > >> When sending Read() via an RPC call or traversing locks, it is >> significantly faster to return EOF in the same call as returning the rest >> of the available data, than to call Read a second time to get the EOF. >> > > Just for sake of discussion/argumentation, it's still possible for the > callee implementation to cache the error status which is returned in the > next Read call. Thus a single RPC (or lock) call is performed. > > -- > Diego Joss > -- 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/8a139eee-f727-4b2a-bf54-0389848d5df1n%40googlegroups.com.
