Go doesn’t support pointers to map keys or values. It does support pointers to array slots, but for-range copies each slot rather than giving you a pointer to it.

I suppose that makes sense when I think about it for a bit. My recent expectations come from work in Rust. There the language prevents you from mutating a map while holding a reference into it. Go doesn't have a mechanism to prevent that (except the one you said, simply not supporting those references at all). If you had a reference into a map that was resized because of a subsequent mutation, your reference would have to keep the whole previous map alive and point to different memory than a reference acquired since then. Both seem undesirable.

With array slots, the same issue is present but is a bit more explicit because those resizes happen with `mySlice = append(mySlice, ...)`.

I think the slice append semantics are very error-prone, and it would have been better if a slice was a shareable reference to a single mutable thing, like a map (or a list from Python or Java or …)

>If you had a reference into a map

Maps in golang are of reference type, just to be clear.

https://go.dev/blog/maps

implementation: https://go.dev/src/runtime/map.go

Indeed, removing values from a map while iterating over it in Go is safe and guaranteed to have the expected behavior.

If you have a map of string to int, then v is of type int. It's a value. It's not pointer to int.

Is the expectation that you simply won't create a `map[...]expensivetocopyvalue`, but instead always do `map[...]*expensivetocopyvalue`?

No expectations whatsoever. You can use pointer or a values. It's up to you.

That's silly. Language constructs and APIs are always made with expectations for how they're used, stated or not. You can write code that compiles without understanding and matching those expectations but it probably won't be good code.

I'm asking because I think if it were expected that folks used large/expensive-to-copy map values, this construct would return a reference instead of copying. In Rust for example, the std library's "normal" [1] iterators return references.

[1] not those returned by into_* or drain.

Returning references to storage within the map would be a substantial footgun without borrowing.

Thanks, useful reply. I just realized that myself: https://news.ycombinator.com/item?id=37576558

The peer comments along the lines of "the expecation is it does what it does" are not so helpful from a perspective of learning to write code that is in harmony with the language philosophy.

Here an example: https://go.dev/play/p/He0lBEYZJ03

Value is always a copy. Either a copy of a struct (in case of map[T]struct{}) or a copy of a pointer (in case of map[T]*struct{})

The expectation is the compiler does what you tell it? If you want pointers in your map, you can do that too.

They're asking that, if the programmer wants the map to store expensivetocopyvalue semantically but also doesn't want to have iteration generate expensive copies, does the programmer have to change the map to store *expensivetocopyvalue instead?

Anyway I believe the answer is that expensivetocopyvalue is not a type that exists in golang, because golang's "copy" operation is always a simple bitwise copy ala C struct copy / Rust's Copy trait, not like C++ copy ctor / Rust's Clone trait that can be arbitrarily expensive.

In Go, `expensivetocopyvalue` can still be achieved via an enormous (e.g. multi-KB/MB) structure (which is most literally expensive to copy) or something containing a lot of pointers (which is not really expensive to copy but will start to pressure the GC).

I managed to track down these code snippets. Feel free to check out these links if you're curious:

https://github.com/adobe/kratos/blob/93246f92d53feba73743dbf...

https://github.com/StalkR/goircbot/blob/6081ed5d1d74f01767d7...

Basically the compiler is translating

    go a.Monitor(b)

into

    (&a).Monitor(b)

due to automatic dereferencing