[spraak]

> Right now, such a signature would be accepted, but if you tried to use any of map’s methods, you’d get an error that K needs to be Hash and Eq, and have to go back and add those bounds. That’s an example of the compiler being pedantic in a way that can interrupt your flow, and doesn’t really add anything; the fact that we’re using K as a hashmap key essentially forces some additional assumptions about the type. But the compiler is making us spell out those assumptions explicitly in the signature.

I feel this exact same way with Go. E.g.

    x := map[string]map[string]int{
        "key": map[string]int{
            "another": 10,
        },
    }

Given that the outer type signature says that the `value` of the map should be a `map[string]int` it's sometimes quite annoying to specify that inner type over again

[zeeboo]

You can leave the inner type out...

https://play.golang.org/p/m3bLmneArB

[spraak]

Ah, maybe it's when they're alias types that that wouldn't work?

[HeyImAlex]

Actually I just tried that and it worked also. But I think you're right that this hasn't always been the case because I remember being annoyed about it. Or maybe we're both crazy.

You definitely need to specify the type for an interface, but that makes sense.

[unscaled]

You're not crazy. I also have vague memories of maps being more obnoxious in Go. :)

The facts are that map literals did change a bit in Go 1.5 (i.e. fairly recently), full literal specification for values could already be elided back then - it was KEYS that required full specification: https://golang.org/doc/go1.5#map_literals

If you go way more back, Go 1 also saved some typing on values, in case they were pointers: https://golang.org/doc/go1#literals

[tibbe]

Type inference should solve that if Go ever gets that.

[camus2]

This has already been requested quite often, the Go team refused pretending it wasn't "readable". "readability" is their number one excuse to get away with not discussing a feature at first place.