utils/misc.mli defines a Stdlib module, that might be the issue. I got bitten by this as well recently

@diml is spot on ! Added a patch that remove the open Misc at the top of the file.

I'm a bit uncomfortable with the rash of deprecations that are about to hit the stdlib (already the Pervasives one). Deprecating current practices that are harmful seems reasonable, but I'm not convinced that using string_of_int instead of Int.to_string is harmful, there deprecation seems used more as a "hint towards a modern code writing style".

It's not about this specific issue, I'm not sure what's the best place to discuss the general deprecation practices, and I don't have a clearly better solution to offer to the problem of gradual style evolution. Just airing out a bit, sorry.

I'm a bit uncomfortable with the rash of deprecations that are about to hit the stdlib (already the Pervasives one).

From an end-user point of view it's actually much better and less time consuming if there's a single rash of deprecations rather than each OCaml version introducing a new one.

Deprecating current practices that are harmful seems reasonable, but I'm not convinced that using string_of_int instead of Int.to_string is harmful, there deprecation seems used more as a "hint towards a modern code writing style".

I find that to be a quite restricted view of deprecation. As far as I'm concerned deprecating some names in favor of others is as important as deprecating harmful practices and I thought people mostly agreed on the idea that these functions were better placed in the module that handles the type rather than in "the initially opened module".

Besides, note that in the particular case of Bool the result is actually a deprecation from a harmful practice (using exceptions for non exceptional errors) and design error (a function raising Invalid_argument in contradiction with the expected semantics of that exception). In that case I would find it a bit odd to deprecate bool_of_string for the corrected functionality in the Bool module but not deprecate string_of_bool because it's not "harmful". And then if you agree with the latter deprecations, then why not do the same with the support for int aswell ?

I'm a bit uncomfortable with the rash of deprecations that are about to hit the stdlib (already the Pervasives one).

Aside. From a stdlib evolution perspective I think it would actually give a better overall message to end users if the names that are nowadays perceived as being out of place in the "initially opened module" are deprecated at the same time as the historical Pervasives module.

Even if we don't deprecate the function and assuming #2011 will be merged. Are people interested in these patches which simply uses Int.to_string instead of string_of_int in the code base or should I close this ?

Are people interested in these patches which simply uses Int.to_string instead of string_of_int in the code base or should I close this ?

No, let's keep it. It's a good goal to use modern style in the code base. (I would not encourage people to spend time on such PR, but this work is already done in this case.)

It is my intent to rebase this PR and solve the conflicts but it will have to wait next week.

This has been rebased. The CI failure is due to the lack of changes entry (I don't think one is needed). I tried to find the information in CONTRIBUTING.md on how to disable the test but couldn't find it, the CI tells you:

Some very minor changes (typo fixes for example) may not need
a Changes entry. In this case, you may explicitly disable this test by
adding the code word "No change entry needed" (on a single line) to
a commit message of the PR, or using the "no-change-entry-needed" label
on the github pull request.

would be good to have that in the CONTRIBUTING.md document.

Ping.

Had to solve conflicts again. Not sure I'll do it once more. Can someone please merge this.

I'll merge this as soon as the CI passes. Thanks!