[nicoburns]

The limitation around implementing methods on built-in types seems unfortunate. If I understand how Go interfaces work correctly, that would mean that you also can't implement your own interfaces on built-in types. Which would seem like quite a severe restriction in being generic over them. Perhaps I'm missing something?

[sacado2]

You can only add methods on types that were defined in the current package. As a consequence, you can't add methods to built-in types. But that's rarely something you want to do anyway (I can't think of a real-world situation where it would be useful), what would make sense is creating a new string type, and add methods to it:

    type myInt int

    func (mi myInt) f() myInt { ... }

[mdlayher]

The alternative is to do something like:

type Int int

func (i Int) Hash() uintptr { /* do the hash */ }

But I didn't want to deal with it in this code. I agree that it isn't optimal and would be curious to see if the situation can be improved.

[lspears]

If you assume that the std lib creates a collections package, there could be helper types will for primitives. No Java style auto boxing, but more in the Go style. These could also be used in a refactored math package.

[skybrian]

For example, the caller could cast `int` to `myInt` which implements the appropriate interface. This is probably more idiomatic than using a bare `int` type anyway.

[benhoyt]

What would be a real-world example of what you're referring to ("implement your own interfaces on built-in types")?

[uluyol]

Perhaps like overloading in C++? Hash functions are sometimes defined this way (https://abseil.io/docs/cpp/guides/hash#making-hashable-types)

[renewiltord]

You can do cool things like Ruby's `2.days.ago` in languages that allow you to implement traits on any type.

[dnr]

`2.days.ago` is not "cool," it's an example of the some of the worst things about Ruby. Suppose I came across a cutesy expression like that in a program I was reading. How in the world am I supposed to figure out what code is invoked by that expression and where that code lives?

It's emphasizing writeability over understandability, which is totally backwards from the point of view of engineering robust systems.

Except it's barely even writeability, it's some bizarre notion that code should read like English where possible. And of course, since it's not actually English, it's only possible in limited ways and trying to generalize past those limits will break. So you have to learn exactly where the limits are anyway, which is as much effort as learning to use a proper library, except harder because a proper library will have the decency to stay in its own namespace.