Julia: Unexpected behaviour of `replace(::String...)`

[KlausC]

julia> replace("abc")
ERROR: MethodError: no method matching copy(::String)

Stacktrace:
 [1] #replace#247(::Int64, ::Function, ::String) at ./set.jl:667
 [2] replace(::String) at ./set.jl:667
 [3] top-level scope

1. I would expect here a no-op, return the input string as output.
2. Why don't we have copy(a::AbstractString) = a ?

julia> replace("abc", 'a'=>'b')
"bbc"

julia> replace("abc", 'a'=>'A', 'c'=>'C')
ERROR: MethodError: no method matching replace(::String, ::Pair{Char,Char}, ::Pair{Char,Char})
Closest candidates are:
  replace(::AbstractString, ::Pair, ::Pair) at set.jl:731
Stacktrace:
 [1] replace(::String, ::Pair{Char,Char}, ::Pair{Char,Char}) at ./set.jl:731
 [2] top-level scope

1. That is confusing. At one hand "no method", but in the stacktrace exactly the required signature.
2. It would be logical to implement replace(::AbstractString, ::Pair...) consistently - that would be in line with replace(::Set, ::Pair...)`

julia> replace("abc", 'a'=>'A', 'c'=>'C', 'b'=>'B')
ERROR: MethodError: no method matching copy(::String)
Closest candidates are:
  copy(::Expr) at expr.jl:35
  copy(::ObjectIdDict) at abstractdict.jl:614
  copy(::BitSet) at bitset.jl:38
  ...
Stacktrace:
 [1] #replace#247(::Int64, ::Function, ::String, ::Pair{Char,Char}, ::Vararg{Pair{Char,Char},N} where N) at ./set.jl:667
 [2] replace(::String, ::Pair{Char,Char}, ::Pair{Char,Char}, ::Pair{Char,Char}) at ./set.jl:667

[rfourquet]

Thanks for reporting.

I would expect here a no-op, return the input string as output.

That makes some sense. The replace(::AbstractString, ::Pair) was added recently to match the new replace(::Union{Set,...}...) API, but only what was already implemented for strings has been replaced, i.e. replacing multiple pairs is a not-yet-implemented but of course would-be-nice-to-have.

That is confusing. At one hand "no method", but in the stacktrace exactly the required signature.

This is a bit tricky, as those "implemented" methods which throw MethodError are somehow necessary to resolve ambiguitites with other methods. Maybe throwing another type of error would reduce the confusion, but it's also true that those method don't really exist in a way that can be used.

[KlausC]

@rfourquet replacing multiple pairs is a not-yet-implemented but of course would-be-nice-to-have.

it would be a honour to me to make such a PR.