Update context to have a generic method for getting request data.

[cheikhshift]

Add a generic method GetAs to get request data.

• With pull requests:
  • Open your pull request against master
  • Your pull request should have no more than two commits, if not you should squash them.
  • It should pass all tests in the available continuous integration systems such as GitHub Actions.
  • You should add/modify tests to cover your proposed code changes.
  • If your pull request contains a new feature, please document it on the README.

[appleboy]

We also need support go1.16 up version.

[cheikhshift]

This will be problematic, as Generics were introduced in Go 1.19. Any suggestions?

[johannes-riecken]

What's the benefit of this method over the non-generic version? The biggest issue with Get is that a failed type assertion causes a run-time panic, which seems to be the same here?

[cheikhshift]

No need to assert the variable to a certain type. The assertion is also checked and returns true/false depending on the case.

[laggu]

@appleboy gin requires go 1.21 or above now. Would you consider this feature again??

[appleboy]

@laggu Yes, we should reconsider the changes.

[Ozoniuss]

I would find adding this method to be very useful, if support for an older Go version (perhaps in a new Gin release) would no longer be required. If passing custom types in the request context, it helps avoiding some of the code duplication incurred by using the ctx.Get() method followed by a type assertion.

To give a concrete example, in this project I am working on it would've helped to avoid having to define a custom function when retrieving context parameters that are of custom type. I could've used this GetAs in the same way I used GetInt. (code for reference)

id := ctx.GetInt("id")
req, ok := common.CtxGetTyped[casheerapi.UpdateEntryRequest](ctx, "req")
if !ok {
	return
}

With that method, I wouldn't have had to define my custom method CtxGetType which does the same as the new GetAs (actually it does more things for the sake of safety, but I could've omitted them because a middleware is validating the type beforehand).

What's the benefit of this method over the non-generic version? The biggest issue with Get is that a failed type assertion causes a run-time panic, which seems to be the same here?

Avoiding the code duplication by doing the type assertions yourself is a good enough benefit IMO. Functions like GetInt, GetBool, GetTime etc. that are already defined for the library do pretty much the same, except they convert the value to an existing type. If we have those, I would argue that this new function would be just as useful.

[appleboy]

I think we don't need the changes from #3633 anymore.