Proposal to use map!(f,A) for in place modification of collections

[ndinsmore]

I have been working through some of the JuliaCollection packages working to make sure that map!(f,values(dict)) has non-naive implementations. As the semantic was introduced in #31223.

Which got me thinking that potentially map! should be implemented on more of the non AbstractDict collection\container types as it could be useful.

For those types that just store values without keys, it would make sense that map!(f, collection) is the syntax. But apparently, that exact syntax was depreciated in #19721. There is an open PR to add it back in for AbstractArray, #3007.

There are some related open issues like:
#12277

It seems to me that map!(f, A) should clearly be equivalent to map!(f,A,A) so can the ecosystem use that?
Finally, if ecosystem packages implement map!(f,A) for in place value modification, is there a way to make sure that when map!(f,A,A) is used it can get a fall back to map!(f,A)?

[Jutho]

I think that #12277 exactly argued why map!(f,A) behaving as map!(f,A,A) is confusing, given that broadcast!(f,A) does something else (namely call f without arguments). As such, #12277 was the discussion that lead to #19721, which I don't think stands any chance of being reverted.

[StefanKarpinski]

FWIW, I think we should get rid of all the "nullary" methods of map et al., so that map(f) means (args...) -> map(f, args...) and make map!(f, x) mean map!(f, x, x). I really doubt that anyone is actually depending on the nullary behavior.

[MasonProtter]

It's also pretty easy to get the "nullary" behaviour if you want it like this: map(_ -> f(), x) or map!(_ -> f(), x) for inplace.

[tkf]

FYI #35293 is an RFC for gettring rid of map(f) and foreach(f).

[StefanKarpinski]

I think we should do both that and this. We could try it and if it breaks any package, reconsider, but I bet it won't.

[LilithHafner]

Triage says we should do this; there's really no other sensible interpretation of map!(f, x).