Problem

Often code is very similar for similar datatypes eg. converting an integer type (int, int8, int16, ...) to a string which we can do with strconv.FormatInt. However that example illustrates in my eye's the biggest shortcoming of Go (definitely given the reflective capabilities of the language): the fact that there is no way for parameters to accept similar types.

Eg. strconv.FormatInt has as signature func(int64, int) string this means that when we want to convert an int16 to a string we first have to convert it to an int64, this is a trivial step but it creates some clutter which quickly starts to make code noisy.

My suggestion

What we could do about this, without (entirely) breaking the type system, is to give a list of types that are accepted and then the type that we are going to use in the function.

Then the definition of strconv.FormatInt could become something similar to this:

func FormatInt(i (int, int8, int16, int32, int64) -> int64, base int) string {
    ...
}

(note: if the 'being used' type should be included in the list or not is something that should be specified.)

The compiler should then check if int, int8, int16, int32 and int64 are in fact convertible to int64, then insert the conversion and continue as if i were an int64.

When we come to a function that calls strconv.FormatInt we check if the type is in the list.

Backward compatibility and standard library

Since it's an addition to the type syntax and type system, it doesn't break already existing code.

When using this in the standard library, no already existing behaviour changes or breaks.

Final note

For me this system would solve a lot of verbosity and remove the need for a ton of boilerplate (I tend to write an util function per int-like type to convert it to a string).