Delete `map(f, ::AbstractString)` special case

[LilithHafner]

Do we actually want this?

julia> map(x -> x+1, "abc")
"bcd"

julia> map((x,y) -> x+1, "abc", [1,2,3])
3-element Vector{Char}:
 'b': ASCII/Unicode U+0062 (category Ll: Letter, lowercase)
 'c': ASCII/Unicode U+0063 (category Ll: Letter, lowercase)
 'd': ASCII/Unicode U+0064 (category Ll: Letter, lowercase)

Is it worth the break from the typical semantics of map where the function always returns an AbstractArray?

Can we rename this method to stringmap?

[LilithHafner]

The tuple case is also a special case, though imo a much more reasonable special case.

[LilithHafner]

First step: add stringmap & deprecate that map method.

[jakobnissen]

map is also defined for Number.
I don't exactly understand what map is supposed to do. As far as I can tell, there are three useful behaviours, and it currently does neither of these:

1. A purely lazy map - which is the different Iterators.map
2. A function that always returns the same container, e.g. a Vector or whatever.
3. A function that preserves the container type which allows it to be generic over the container

Right now we're in this weird halfway point where it sometimes returns a Vector, sometimes returns a container of the same type (Number, String, tuple, some arrays), and sometimes errors (sets and dicts).

[jariji]

As I said in #51703, I think it's necessary to decide if map is required to return a certain concrete/abstract type, or if instead it has certain properties. Option 1:

• map returns AbstractArray: It's okay if we want to say map has to return AbstractArray.

But abstract types are somewhat restrictive. It would be more flexible if we adopted option 2:

• map has properties: There's a list of properties that a valid implementation of map must have: always returns an indexable collection preserving the indices and size of its argument when they exist.

If map(f, ::Tuple)::Tuple is okay, that can be made principled by a specification. If that specification would apply to Tuple, and would apply to String, then can be correctly implemented for both. (It probably wouldn't work on Set because that doesn't preserve length, so map(f, ::Set)::Set wouldn't be implemented.)

[vtjnash]

map on a String (currently) does not preserve indices, since it is indexed by byte offsets but iterates by characters, so it is a fairly specific special case to whatever definition we use

[MasonProtter]

Example of what Jameson is talking about:

julia> let str = "αγβ"
           str2 = map(_ -> 'c', str)
           collect(eachindex(str)), collect(eachindex(str2))
       end
([1, 3, 5], [1, 2, 3])

[jariji]

I'm sold on removal then.

[topolarity]

Should we document that map impls should preserve both the keys(...) and iteration order of its argument (ignoring the multi-dimensional case), and does not guarantee anything about the result type otherwise?