Remove the places where warning 3 was raised in str.#581
Remove the places where warning 3 was raised in str.#581bschommer wants to merge 2 commits intoocaml:trunkfrom bschommer:str-warning-clean
Conversation
|
This changes the semantics of Str. There could be people relying on its current Latin-1 oriented semantics... |
|
That is right. Maybe one wants to duplicate the function with the ascii and latin-1 version? |
|
cc @xavierleroy |
|
OCaml really needs UTF-8 versions (which are what people almost always need). However, Unicode breaks so many assumptions that this would not be backwards-compatible – in general, the only way to correctly handle Unicode (unless you are doing something simple like escaping ASCII metacharacters) is with a library designed for the purpose. |
Similar to the String, Char and Bytes module the latin1 version of the function is now marked as depricated and version for the ascii character set are added.
|
I updated this PR to include ascii version of the case insensitive regexp matching. There are also some test for the new versions. |
|
I'm still unsure what to do about this one. My inner voice says that we should just silently remove Latin-1 support from the existing functions, not create new "_ascii" functions. But that's not the direction that was taken in the standard library. Should I tow the party line? or join the dissidents? Still undecided. |
|
The problem with just changing the implementation is that it will probably break existing code. However since it was never documented what uppercase/lowercase functions were used it would not be that problematic. Alternatively one could just expose the internal function and allow users to pass a |
|
Sorry if it's been previously discussed, but does a change like this make a case for cutting Str out of the standard distribution? That way conforming to the behaviour becomes tied to the version of the library, rather than OCaml? |
|
@dra27: yes, sending dissidents abroad is one way to preserve the party line... |
|
😄 I was thinking it could be made compliant and sent abroad! |
|
FWIW: as far as I know this is the only place where there are still
warnings while compiling OCaml.
In my opinion, reaching a situation where the compiler compiles without
any warning looks very suitable, because once this point is reached,
every new warning that is introduced becomes even more visible.
So, although I don't have any opinion about how this particular problem
should be solved, I wish it gets solved ASAP.
|
|
If your problem is just to see no warning, just put the correct [@ocaml.warning] attributes to silence the warning at the points where |
|
Removing the warnings with the correct [@ocaml.warning] would be okay. But additionally one maybe wants to document that these functions use the latin-1 versions to avoid confusion. |
|
Xavier Leroy (2016/12/05 00:37 -0800):
If your problem is just to see no warning, just put the correct
***@***.*** attributes to silence the warning at the points where
`Char.lowercase` and `Char.uppercase` are used. We know they are
used, purposefully, and don't need constant reminder.
OK if this is an acceptable solution, will submit a PR soon. Thanks.
|
Move our usage of inline to Caml_inline (to align with upstream ocaml)
…heir sub-pages (ocaml#581) * factoring out shared elements between 'Learn' page and 'Exercises' page: `Learn_layout` now exports functions that render the links and link groups, as well as the icon link group of the sidebar * refactoring Learn_layout.eml into a layout component * "Documentation" in sidebar is now "Learn OCaml" * minor style improvements Co-authored-by: Sabine Schmaltz <sabine@tarides.com>
There were a few places where the lowercase/uppercase functions where used.