Mirror of forum.nim-lang.org

2573 :: strutils.toLower deprecation?

• mindyarn (orginal) [2016-10-11T15:35:58+02:00] view original

  I'm new to the forum and to Nim, so let me first say hi everyone, and thanks for developing this nice, interesting language!

  One of the things that attracts me to Nim (as a python2 holdout) is the support for byte strings as first class citizens (the lack of which make me hesitant to use python 3). But, I noticed that strutils.toLower (and friends) where recently deprecated, with preference given to the rather unweildly toLowerAscii, to avoid name clashes with the unicode module.

  What was the reasoning behind this deprecation? Will toLower eventually disappear? The name clashes can already be worked around with either name space qualification or blacklisting so why was this needed? I feel that it would be unfortunate if Nim would move in the direction of python3 on the unicode question.

---

• OderWat (orginal) [2016-10-11T16:07:20+02:00] view original

  I think that other string functions all are not working correct for UTF-8 as well and from this aspect still would have a bad name, too. I doubt that Nim will change "string" to something else ever. So yes. It makes it more clear but IMHO having an "toLowerUtf8()" or a distinct string utf8 would be more honest.

---

• Krux02 (orginal) [2016-10-11T23:34:13+02:00] view original

  I think that a string should be UTF8 by default. There is no reason functions shouldn't work with utf8, unless it really is performance critical. And string manipulation is rarely the performance critical part of the code. I can imagine that it could be hard to implement everything in Nim could be a lot of work, but I think the goal should be there.

---

• OderWat (orginal) [2016-10-12T01:21:08+02:00] view original

  So s[0] type would be a string with a size between 1 and 6 bytes. s[1].addr would depend on the byte length of the first codepoint. s.len would not be the length in bytes anymore. One would need a new "length" for that? Instead of strings + cstring the FFI would need to use seq[char]? But besides that and breaking everything. It would need to decode and encode (and check) utf8 everywhere. Reading and writing strings would not be anymore transparent and needed everywhere to specify it's encodings. Does not sound like something I want in a systems programming language as standard string type.

---

• Varriount (orginal) [2016-10-12T08:11:57+02:00] view original

  Eh, my biggest complaint about strings is (and probably always will be) their copy-on-assignment behavior. At least UTF8 handling can be implemented fairly transparently through subtyping.

  (Yes, I'm aware that changing current string assignment behavior would break things)

---

• RPG (orginal) [2016-10-17T03:33:07+02:00] view original

  Vote for toLowerUtf8 and so on. GLib2 uses similar approach.

---

• Araq (orginal) [2016-10-18T10:11:31+02:00] view original

  What was the reasoning behind this deprecation?

  It's crucial today to emphasize toUpper is not Unicode aware.

  Will toLower eventually disappear?

  The one in strutils, not the one in unicode.

  The name clashes can already be worked around with either name space qualification or blacklisting so why was this needed?

  You're right it wasn't needed, but we felt a little more explicitness wouldn't hurt here.

  I feel that it would be unfortunate if Nim would move in the direction of python3 on the unicode question.

  I totally agree. Unicode in C# and Python is really quite painful IME.

---