I don't remember any discussion on that, but I guess the previous behavior is a reminder that something is fishy with this code and deserve further discussion. E.g. some people suggested to switch to ASCII versions of the function. This changes the behavior of functions, so this cannot be done lightly, but at least the (non-fatal) warnings are a reminder for that.

That's the problem with the current process, i.e. having long discussions on Github,

You mean like in http://caml.inria.fr/mantis/view.php?id=6694 ?

I opened a similar PR #581 and recently updated so that it is similar to the other functions relying on uppercase/lowercase functions by adding ascii versions and adding a deprecation warning on the original ones.

The reason I haven't changed this part of Str yet is that I'm torn between doing the right thing and being consistent with the choices already made in Char and String. The right thing, in my opinion, is to switch all the library functions that deal with character case from Latin-1 to ASCII, keeping the function names and documenting the change. I was overruled there, so we now have Char.lowercase_ascii and the like, plus deprecation warnings. To be consistent, Str should also have _ascii variants and warning dance. But I still feel we're not doing the right thing. So, I'm still dragging my feet.

The right thing, in my opinion, is to switch all the library functions that deal with character case from Latin-1 to ASCII, keeping the function names and documenting the change. I was overruled there, so we now have Char.lowercase_ascii and the like, plus deprecation warnings.

Given that I'm now spending my time silencing these warnings in various projects (to be able to support pre 4.03 compiler), I think that this would have been a better approach; but then I personally have never been using this on latin1 encoded strings. Maybe we should actually have tried to understand of how widely this was being used with latin1 encoded strings.

I have the same opinion as Xavier, and I don't think so many people rely on the current behavior on Latin-1, or they should be able to adapt quite easily (the default functions should become ASCII, while we should have provided helping functions _latin1 for people relying on the former semantics to adapt their code easily instead of the contrary with _ascii functions).

So, is this discussion going to be settled before the release, or should we keep the warnings for the release, or should we hide them in the release branch ?

If we change(d) the behavior of String.lowercase/uppercase, could we imagine ways to let people know when they were likely to depend on the previous behavior? One could for instance report a runtime warning (with the same OCAMLRUNPARAM flag as for non-closed file-descriptors for instance) when String.lowercase/uppercase would return a different result with the old and new semantics and the string is not a well-formed UTF-8 string. (The probability that a piece of non-ASCII Latin-1 text is valid UTF-8 is very small.)

I think at the moment there is no way around the _ascii version since some of them are already there and removing them would require deprecating them and so on and so forth.
Maybe one could just remove the old functions from the 4.04 release and then in a later release one could change the names to the non sufficed ones?

A solution would be to keep the _ascii functions after changing the behavior of the standard functions (both functions would have the same semantics), while adding _latin1 functions. This way, most applications would not suffer any problem (no need to deprecate _ascii functions immediately...).

Since there are other PRs on the same subject, and it is more a reminder than anything else, closing.