https://issues.dlang.org/show_bug.cgi?id=14925
--- Comment #2 from Steven Schveighoffer <schvei...@yahoo.com> --- Hm... I was wrong I guess (sort of). The *second* overload is the one that should be chosen. This means that even though the replace could be done directly, it will reallocate. This is because other pieces of the first overload cannot compile with narrow strings (namely, remove). So I just added a constraint to the first to prevent it from being called on narrow strings, and updated the second to work for all cases that don't match the first. I also found a bug where the first constraint would match 2 arrays where the second array wasn't identical, but the elements could be implicitly cast to the elements of the first. For example: auto a = [1L, 2, 3]; a.replaceInPlace(1, 2, [4,5,6]); Which fails to compile on 2.068 --
