feat: gin.Context GetXxx added support for more go native types

[CC11001100]

Thanks for such a nice open-source web framework, when I was using gin middleware today I found that the support for go native types when getting the data from gin. I put in a uint8 type, for example I put in a uint8 type, which when I get it doesn't provide a quick method but requires me to type it myself. I added some get methods of go native type, please review and merge to help more people, thank you very much

gin.Context new add methods:

• GetInt8
• GetInt16
• GetInt32
• GetUint8
• GetUint16
• GetUint32
• GetFloat32
• GetIntSlice
• GetInt8Slice
• GetInt16Slice
• GetInt32Slice
• GetInt64Slice
• GetUintSlice
• GetUint8Slice
• GetUint16Slice
• GetUint32Slice
• GetUint64Slice
• GetFloat32Slice
• GetFloat64Slice

[YuukanOO]

Maybe we should keep the same logic as the original .Get and returns a (int8, bool) to avoid panicking in case the value if not of the asked type. This comment applies to other methods as well. What do you think?

[CC11001100]

Yes, you are right, I just noticed this problem too, but there is a small compatibility problem that seems strange, the methods I added this time are styled by the functions that already existed before:

func (c *Context) GetInt(key string) (i int)

and

func (c *Context) GetInt64(key string) (i64 int64)

The style is kept uniform, and these two functions seem to start from this PR:

https://github.com/gin-gonic/gin/pull/2425

Then other GetXxx functions such as:

func (c *Context) GetString(key string) (s string)
func (c *Context) GetBool(key string) (b bool)

It seems that they all follow the rule of only one return value.

All in all, there seem to be two styles for the Get method on the Context. The first one is:

func (c *Context) Get(key string) (value any, exists bool)

Represented by two return values, the other is based on

func (c *Context) GetInt(key string) (i int)

represented by one return value

[YuukanOO]

You're right, I didn't see that, so what you've done makes sense.

But for the record, I guess we could leverage Go generic with something like this:

func Get[T any](c *gin.Context, key string) (r T) {
	if val, ok := c.Get(key); ok && val != nil {
		r, _ = val.(T)
	}
	return
}

Sure we can't add this on the Context type because Go doesn't currently support method level generic types yet.

[CC11001100]

Yes, you have a point, the best way is to add a generic method to Context, although I don't think Golang will support this feature any time soon, but I believe it will be supported in the future, it is a mature language should have a feature. some proposal about it:
golang/go#49085

However, in the absence of generics, enumeration method can only be used. Although there is a lot of repetitive work, using a separate method can solve this problem, but it will be a problem to promote the use of this function. Most people use the method in Context and then view it with dot. So I think it is necessary to add these methods to Context for now, as a transition that will remove in the future when Golang supports Struct generic methods.

[CC11001100]

Hello, is there anyone with merge permissions to merge this PR?

[appleboy]

@CC11001100 see the PR #3329