Closed xr closed 1 week ago
As much as I want to upvote Strict compliance, but this is Break change. Unrealistic :p
some case:
@xr I think it would be better to keep this issue in open state as an improvement reminder for the next major version of the gin
it's extremely disorienting that I must not use the gin.Context and need to use (*gin.Context).Request.Context() instead
PS:\ I faced the similar situation with otel like @pepea23 in https://github.com/gin-gonic/gin/issues/3993, and when I found that my otel.Span just disappeared from the context I was very surprised
PPS:\ Another funny thing that there is no one sample in the gin's documentation with the context usage in a case when we should pass it deeper to other components. I think it should the very first line in the README, for real
Hey guys,
We're having some discussions regarding whether or not Gin
Context
violates the Go context style guide. I'd like to hear your thoughts on this.According to the Go style guide (reference: Go Style Guide on Custom Contexts), it clearly states:
However, in the case of Gin's
HandlerFunc
, it passes a custom*Context
type.Even though the Gin
Context
implements all the methods of thecontext.Context
interface,as shown here
We still need to interpret the Go style guide. There seem to be two possible views on this:
Gin's
Context
is acceptable: Since it implements thecontext.Context
interface, it can be considered valid, and thus doesn't violate the style guide. Similarly, we could create other types like this:Strict compliance: To adhere to the Go style guide strictly, we should always pass
context.Context
directly in function signatures. In this case, the design would need to change to separate theContext
from custom APIs. For example, the function signature could be:What do you guys think?