The name Char is misleading because it implies a character, but in reality it’s just a codepoint
Char can’t represent graphemes. Maybe Char should have been Grapheme instead.
Comparison between Char and String always gives false
Matching a Char against a regex always gives nil
That said, I’m a bit reluctant about the part “Most modern languages don’t have a Char type”:
Rust has one, which is the same as Crystal
Golang has a rune type, which is equivalent to Crystal’s Char
Nim’s char is a byte
Swift has a Character type and it’s like a grapheme
So what are all these modern programming languages that don’t have a Char type?
If Crystal 1.0 didn’t release yet, I would consider renaming Char to Codepoint, and making all String operations return String or Grapheme, but I think now it’s a bit too late because of backwards compatibility.
So some questions:
Should we let matching a Char against a Regex?
Should we add upcase and downcase to Grapheme? I noticed they don’t exit yet
I forgot to mention: Elixir works very well regarding strings, and there’s ko Char type. But so far the only languages without a Char or with one that has a default Grapheme type are Elixir and Swift. Maybe those are the only modern languages, so “most modern languages” would be accurate, I guess :-)
I’ve personally not had any issues using Chars and think they are important for performance.
If I do "example,usage".split(',') I don’t need a string class being allocated to the heap for the ',' param.
From my reading of the article the main complaint really boils down to String#[] returning a Char type and not a string of length 1. Which seems like a reasonable change to me.
We could remove Char#upcase or have it return a String as I feel like accuracy here is more important than maintaining the type (make it a shortcut for converting the char to a string and then calling upcase on a string)
I don’t mind if "a" == 'a' is true, but current behaviour doesn’t bother me.
From my reading of the article the main complaint really boils down to String#[] returning a Char type and not a string of length 1. Which seems like a reasonable change to me.
Access to the old variant will still be needed though, there are many situations where the performance impact of creating a bazillion one character strings would be unwanted.
Should we let matching a Char against a Regex?
Well, what are the implications? Does the char have to be converted (and thus allocated) to a string to do it or is it possible to do without further overhead?
I guess part of the problem also is how to handle regexps defined with the case insensitive modifier. Does the answer to the former impact that?
I don’t really have any opinion on == status for Char vs String
Just a note that when you write a string literal like “,” there’s never memory allocation. The string data is put into the read-only-memory of the program.
That said, if you called "hello".chars and we’d have to allocate one String per char, that would incur a lot of memory allocations (unless we also have a way to represent small strings in an efficient way, but that makes things more complex)
Yes, there are some valid points for criticism. Although I think the blog post might at times be a bit dramatic about it.
In fact, I’ve wondered about the purpose and place of Char while working on the Grapheme API. There is certainly some overlap, and potentially cause for confusion.
I agree that a name such as Codepoint would’ve been a better choice. It would clearly differentiate it from the broader scoped grapheme cluster (sequence of codepoints) as well as the tighter scoped C-style char (single byte).
At this point, a rename would be quite an effort. Hypothetically, we could slowly phase it in as a type alias and automatically transform code to use the updated name. Not sure that’s worth it. Might be best to just embrace the name as it is. It’s not a hard problem, you just need to be conscious about the semantics. Char is at least shorter
I would strongly refute the argument that Char is useless and shouldn’t have been part of the stdlib API in the first place. It’s very efficient due to the lack of heap allocations. So it provides performance for text processing based on single codepoints (which is often the case in computer languages, for example).
And it’s clearly defined what a codepoint is. Grapheme clusters for example are more fuzzy, because the definition can change with Unicode releases (probably not much and mostly exotic edge cases, but still).
Char might be a bit too prominently represented in the string API, though. That’s not just the Char type itself, but also the default index of String (e.g. for String#[]) is a codepoint index, not a byte or grapheme index. This might not be ideal as it guides the user to use that representation, while others (especially grapheme cluster) might be more appropriate in general use cases.
Grapheme is probably a better default model because it more accurately represents what you would normally expect in most text processing contexts. Using only codepoints or bytes is a performance optimization and you need to be aware of the implications it has for your application.
Perhaps we can try to adjust the string API a little bit more towards prefering grapheme in the future. At least conceptually / in the documentation. For that we also need to expand grapheme support which is still pretty basic for now. Adding upcase and downcase would help that.
I suppose that should be okay. But I’m actually not sure how useful it is to have regular expressions for matching only a single character. You’ll most likely have that be some kind of character class, which you can much more efficiently match with Char’s predicate methods, direct codepoint comparisons or range expressions.
The article uses the example /[0-9]/ to match for a digit. You can just use Char#ascii_number? for that. If a dedicated method didn’t exist, you could use '0' <= c <= '9' or c.in?('0'..'9') as well. All these options are much more efficient than spinning up a regular exception engine.
I fear that adding regex support to Char would do more harm than good, as I don’t see many valid use cases and it would guide users away from better alternatives.
If you actually want to do that, you can just convert the character to a string and use that with a regular expression.
I wouldn’t mind to enable equality check between Char and String.
Perhaps that would be something for the case equality operator (===)? There is already Char#===(Int) which works with a codepoint number and thus is “type insensitive”.
Char is a codepoint, thus a number. It can be represented as the character itself, or as the number of the codepoint. That’s similar to how there are different representations of numbers in different bases. 'a' is just the number 97, just like 0x61 as well. They all mean the same thing when interpreted as a character.
Yes, Char is codepoint, but Char really has nothing to do with Integer, i consider Chat#===(Int) is not so useful, even, i consider it harmful, following code is more clear.
case 97.chr
when 'a'
puts 'a'
when 'b'
puts 'b'
end
or
case 'a'.ord
when 97
puts "97"
when 98
puts "98"
end
From the angle of Crystal user(not from ‘A’ internal store for), ‘A’ same as “A”, in fact, it save as binary form, when present as a codepoint, it use hexadecimal.
