Comment author: jpdeplaix

And same thing for String.unsafe_blit of course.

Comment author: @gasche

String.set is deprecated because there is no string that is being set with its new -safe-string type:
bytes -> int -> char -> unit
so having this function in the String module doesn't make much sense anymore.

On the contrary,
String.blit : string -> int -> bytes -> int -> int -> unit
still makes sense: there is indeed a string being blitted in the arguments -- and if you think of it in terms of the bytes into which we blit, it is also called Bytes.blit_string.

I don't think this function need to be deprecated.

Comment author: jpdeplaix

Why is String.fill deprecated then ?
It doesn't seems different from String.fill and deprecating it allows to switch more easily in -safe-string mode by marking this as possibly wrong considering the new use of strings.

Comment author: @gasche

The argument of fill is a bytes, not a string, so it doesn't make much sense anymore in the String module. On the contrary, String.blit has a string argument. There is nothing wrong about using String.blit with -safe-string if you want.

Comment author: jpdeplaix

But String.fill has also a bytes argument. The point is: it should be deprecated as it was before used to modify strings.

Comment author: @damiendoligez

The point is that String.blit (unlike String.fill) does have a string argument, so it arguably belongs in the String module.

The idea of the warnings is not to catch strings that should be bytes (the typechecker does that perfectly), it's more to gently remind the programmers that they should be converting to Bytes. So it's not a big deal if some functions are not marked deprecated even though their type has changed.