Users with that preconception will quickly realize the error in their mental model when they notice that Filter doesn't return anything at all.

There are libraries that use value-returning Filter methods. Why be different here? It doesn't gain anything useful except needlessly aggrieve users.

@Cyberax Because the in-place version does not allocate and is (presumably) often what we want. You can still write maps.Filter(maps.Clone(m), keep) to not operate in-place, but if we'd only have the non-in-place version, you couldn't make an in-place version out of it. Though there might be a case to add both, as calling Clone and removing all filtered elements is slightly less efficient than creating an empty map and adding all kept elements.

I'm not arguing with having an in-place operation. Just name it something like RemoveIf or KeepIf. And both names are actually more descriptive.

An explicit cloning Filter method can be added later if needed.

It looks like C++20 has this function but calls it erase_if. Since in Go we remove elements from a map using delete, that suggests that we name this function DeleteIf.

Changed to DeleteIf.

The builtin copy function seems key-based to me. It does

for i, v := range src { dst[i] = v }

which is exactly what this function would do.

I looked at what other languages call this operation.
I can't find it in Java at all.
Rust calls this operation extend (on all collections).
Swift has merge but it also takes a function to reduce duplicate values. In Go it would be

func merge(dst, src map[K]V, combine func(V,V)V) {
    for k, v := range src {
        if dv, ok := dst[k]; ok {
            dst[k] = combine(dv, v)
        } else {
            dst[k] = v
        }
    }
}

These are of course both methods, and x.extend(y) and x.merge(y) are clearer than extend(x, y) and merge(x, y).

In contrast, it really seems like Copy(x,y) is pretty clear given what programmers already know about slice copy and io.Copy.

The Java name is putAll https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#putAll-java.util.Map-

FWIW, JavaScript has Object.assign(a, b), which works like this. maps.Assign(m1, m2) is okay if not great.

OK, going with Copy.

Prune, maybe?

Actually, I think this thread substantially overlaps with #47330 (comment).

Fair, "drift in a functional direction" is what I meant and that is present in rust, kotlin, and haskell.

I meant other code that currently returns a slice that will be iterated over in the future, e.g. iter.From(fetchSlice()), but I see what you are saying: this would be an iterator that loops over the map without allocating. Still of a mind that we should plan for today and not worry too much about what iterators would look like, since there is not even a proposal,maps.KeyIter(m) is not too bad, and it is explicit about the iterator part.

What does an iterator provide over a for loop?

It's like the difference between a file handle and an io.Reader, except maybe a bit more so. Iterators are like generecized pieces of a loop that can be passed around and wrapped with other pieces in a middleware-esque fashion.

@pcman312 The ability to be implemented by a user of the language.

A normal map iterator will be over key/value pairs. I don't think that an iterator over just keys or just values will be the common case. While I can imagine adding them (if we ever have iterators), I don't think we need to reserve better names for them.

This comment didn't get threaded and I no longer remember what it referred to. Do you remember?

While I agree, and I think a compelling case can be made for only adding pair [recte two tuple], it is not special and the need for a n tuples will begin to develop with generics. I do not want to block anything, but this is probably a good time to reconsider #32941, since imo this reads better:

func Entries[K comparable, V any](m map[K]V) [](K, V)

func Of[K comparable, V any](v ...(K, V)) map[K]V

Though, if we do not; I think the following convention is fairly readable:

func Entries[K comparable, V any](m map[K]V) []struct{K; V}

func Of[K comparable, V any](v ...struct{K; V}) map[K]V

Generally speaking, we are trying to limit the initial API to "clearly should be in this package", not just "probably okay".
This API strikes me as more the latter than the former.

Because they will be used by essentially all Go programs. They are core to Go.

No. There is no way to write a generic function that works both on sync.Map and map[K]V.

I wish we could figure out a way to make interchanging user built hash maps and std maps smooth before adding these utils, else we’ll probably see the same code rewritten many times for these things. I think we will probably end up with a GenericMap if we’re not careful that wraps built in map awkwardly just to fit in with user defined code that wants to be impl agnostic

@hherman1 I think the way this will go at first is that if your package takes an interface for a map-like datastructure, you also provide a wrapper-type type Map[K comparable, V any] map[K]V which implements that interface using a builtin map. Users could then call your code as somepkg.F(somepkg.Map(m)). Not super ergonomic, but IMO okay. If we ever add an interface for a map-like datastructure in the stdlib, we can then also put such a wrapper-type alongside it.

FWIW for sync.Map specifically, I don't think the functions that are proposed here even make a lot of sense. Generally, sync.Map can be modified concurrently, so using operations that consider "the entire map" don't make a lot of sense for it.

@komuw Maybe. See above about the interconnectedness of decisions, though. IMO the maps package seems the right place to put it, so that proposal would still be tied to the fate of this proposal. And then, the motivating factor of suggesting this (a better iteration API and more freedom about the type-definition for container/set) would depend both on this proposal and that new one.

So, I deliberately put the suggestion here, for better or for worse.

@deanveloper I haven't read all the discussion of #43557 - but from the proposal text, it seems that can't be implemented for a map. That's what I mean when I say "one of the hardest parts about designing generic iterators is making it work both for maps and for user-defined types".

Again, there are many issues surrounding iterators that we are not likely to solve in Go 1.18 and should definitely not try to solve in this specific discussion. Let's focus on the other functions.

I think it makes more sense to try out this pattern in just set, see if it's good or bad, and then if it's good, implement it in maps, redo range, etc. Putting in maps first strikes me as rushing it a little too much. If the set API turns out to be wrong, it's only weird package with old-style iterators, instead of two.

With the retraction of exposing the underlying map of container/set, the most immanent reason for this has disappeared, so I'll retract this for now.

I still think this function is a good idea either way (I wished for it a couple of times in the past), I do still believe it to be my favorite way to solve the iterator-conundrum and I do still believe that it makes sense to start container/set of with a better iteration API.
But for now, I can yield a lost argument :)

@carlmjohnson

I think it makes more sense to try out this pattern in just set

Ironically, I don't particularly like the idea of only having in container/set. It would feel like "magic", without a "blessed" way to get type-safe iterators on maps. Maybe that's irrational though. Either way, if the discussion is about adding it to set, it doesn't belong here (as much as these discussions seem interrelated to me).

This would essentially just be a Transform function which may be more akin to a stream/iter API.

This proposal is aimed to only cover widely used functionality. This one isn't common enough.

There's been some discussion of this elsewhere, including in this discussion as well as in #43557. Unfortunately, creating an iterator over a map in Go without language changes is surprisingly difficult, as the only way to iterate through one is with range, and that's incompatible with a Next() method based iterator without a background thread.

Yeah it would require access to the functions in runtime/map.go

@DeedleFake FWIW it doesn't need a language-change - after all, reflect.MapIter exists. But it does require cooperation from the runtime, which is why the stdlib is the only place where it could feasibly be done.

That being said, the idea of adding an iterator interface, as well as the idea to expose a concrete iterator over maps, have been rejected decisively, for go 1.18. It is not going to happen.

Iterators are worth discussing in general, but please not on this proposal, which is about a proposed maps package. Thanks.

I’m largely in support of this, but I think my only opposition to this is that the “XyzFunc” pattern typically just means “the exact same as Xyz but uses a function”. However, DeleteFunc isn’t the exact same as delete, since it may be (and will likely be used for) deleting more than one element.

@deanveloper, you could file a proposal to make the delete built-in variadic. 😁

Could be as simple as returning an Iterator or returning a map with const set of keys.

No offense (FTR, I'm not happy about it either) but I think the time for changes like this is past. Generics are clearly slated for release in go 1.18 - re-opening the syntax discussion doesn't work under that timeline.

I don‘t see a reason to release something that doesn‘t feel right. That the proposals have been approved should not mean that they should be rushed to any particular release.

We've spent at least two years discussing the syntax. I don't think we are rushing into anything.

That said I hope that #48424 will help here.

We've spent at least two years discussing the syntax. I don't think we are rushing into anything.

That said I hope that #48424 will help here.

Came here from that discussion. I didn‘t want to imply that things are rushed, just that an announced release should not force a functionality. Go is famous for doing things right or not at all and generics is a complex topic.

I always think the minimum requirement for a generic design is builtin generics should be able to be defined by using the custom generic rules. For example, we could use a custom map type as TreeMap{Key]Value. It looks this is never a goal for the current design.

@go101 That is true: that was not a goal. And this discussion, which is about the maps package, is not the place to discuss that. golang-nuts would be fine. Thanks.

See #51338 for some discussion about this problem. In particular, it would be helpful to provide use-cases of where you use interfaces as key types.

Note that the constraint has to be comparable to be able to even write map[K]V, even if you don't do any comparisons. So, at least for Go 1.18, this is where we're at - it's simply not possible to use generic maps with interface key types.

I did not know a constraint had to be comparable to be able to write map[K]V. In that case I rest my case here, as this was a specific comment for those methods. Thanks for clearing that up!