You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I opened an issue on fiber when I thought something was missing, and eventually found out there was no bug or missing feature but rather very surprising behavior - I passed an io.Reader to c.SendStream (in fiber) and fasthttp actually type-asserts to io.ReadCloser and closes it for me.
This isn't idiomatic right? My understanding was whoever opens a resource is responsible for closing it, which is why we pass io.Reader instead of io.ReadCloser. While it's difficult for me to think of a practical example, in theory someone might not want fasthttp to close the stream.
I'm not pushing for any fix or change, as changing this would introduce regressions at a wide scale; maybe something to consider for a v3 release but mostly I'd really like to know if there is (or can be) a hard rule for this sort of thing.
The text was updated successfully, but these errors were encountered:
Agreed that this is not idiomatic and wouldn't happen if the library was designed right now. But as you also said it's not possible to change now without breaking backwards compatibility.
I opened an issue on fiber when I thought something was missing, and eventually found out there was no bug or missing feature but rather very surprising behavior - I passed an
io.Reader
to c.SendStream (in fiber) and fasthttp actually type-asserts toio.ReadCloser
and closes it for me.This isn't idiomatic right? My understanding was whoever opens a resource is responsible for closing it, which is why we pass
io.Reader
instead ofio.ReadCloser
. While it's difficult for me to think of a practical example, in theory someone might not want fasthttp to close the stream.I'm not pushing for any fix or change, as changing this would introduce regressions at a wide scale; maybe something to consider for a
v3
release but mostly I'd really like to know if there is (or can be) a hard rule for this sort of thing.The text was updated successfully, but these errors were encountered: