Sorry I might've been to terse in my previous email. On Mon, 25 Mar 2024 at 15:19, Tamás Gulácsi <tgulacs...@gmail.com> wrote:
> 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. >> > What I meant is that the single RPC (or lock) call is not a valid justification for the non-exclusive return values of io.Reader. Let's consider io.Read specification that must return err != nil iff n == 0, then it is possible to implement it without extra RPC calls by caching the error value. -Diego -- 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/CAGjxhKkegNNjL4-79bS%2B7sq3pWJGZsQAhX5Z1y_C%3DU372vAoig%40mail.gmail.com.
