RFC: Rename `char` to make it clearer that it is a unicode codepoint/scalar value

[huonw]

Our char type is a Unicode scalar value (codepoint excluding the surrogate range), which can lead to confusion because (a) it differs to other languages and (b) it doesn't directly encourage good unicode hygiene ("Oh, a character? that's what the user sees").

Possible names include codepoint, ucs4, or rune like Go.

Other languages names for a unicode scalar value/what char means:

• Haskell: Char is a codepoint (although surrogates are allowed)
• D: dchar (char is a "UTF-8 code unit" and wchar is a "UTF-16 code-unit" (i.e. aliases for u8 and u16?): http://dlang.org/type.html)
• Go: rune
• C#/Java/Scala etc.: char is a 16-bit integer (i.e. UTF-16 code unit)
• C/C++: char is (normally) a byte, i.e. a UTF-8 code unit.

(Other languages like Python don't have a type for a single character and don't have a type called char, and so aren't meaningful for this comparison.)

(This issue brought to you by reddit.)

[huonw]

(I'm personally against calling it "rune" since that word feels like a glyph/grapheme rather than a codepoint to me... but there's precedent in Go and in BSD for that name.)

[lifthrasiir]

Also note that UCS-4 was historically not same to UTF-32. Wikipedia says they are now identical, but Unicode FAQ seems to suggest another. ucs (possibly re-acronymed as "Unicode Code, Scalar") might work if the correctness is important.

[Kimundi]

One argument against renaming char would be the precedent that other languages already assign different meanings to it. So the name char would be consistent in the sense that it has no real meaning already. ;)

[lucab]

@Kimundi OTOH it looks like nobody (from the above list) is using char to describe a Unicode scalar value, so we would be adding one more meaning to the list.

[thestinger]

I really don't like rune because it strongly implies a 1:1 relation with a grapheme/glyph.

[liigo]

char is a good name already, and you can't provide a better one. I'd like
to keep it as is.
2014年3月6日 下午6:44于 "Huon Wilson" notifications@github.com写道：

Our char type is a Unicode scalar valuehttp://www.unicode.org/glossary/#unicode_scalar_value(codepoint excluding the surrogate range), which can lead to confusion
because (a) it differs to other languages and (b) it doesn't directly
encourage good unicode hygiene ("Oh, a character? that's what the user
sees").

Possible names include codepoint, ucs4, or rune like Go.

Other languages names for a unicode scalar value/what char means:

• Haskell: Char is a codepoint (although surrogates are allowed)
• D: dchar (char is a "UTF-8 code unit" and wchar is a "UTF-16
  code-unit" (i.e. aliases for u8 and u16?): http://dlang.org/type.html)
• Go: rune
• C#/Java/Scala etc.: char is a 16-bit integer (i.e. UTF-16 code unit)
• C/C++: char is (normally) a byte, i.e. a UTF-8 code unit.

(Other languages like Python don't have a type for a single character and
don't have a type called char, and so aren't meaningful for this
comparison.)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12730
.

[liigo]

Don't like rune, hate usv for its meaningless. +1 for char.
2014年3月6日 下午11:21于 "Luca Bruno" notifications@github.com写道：

@Kimundi https://github.com/Kimundi OTOH it looks like nobody (from the
above list) is using char to describe a Unicode scalar value, so we would
be adding one more meaning to the list.

I'm in favor of re-using rune as:

1. developers already know it
2. describes exactly our case
3. avoids NIH.

Otherwise some acronym like usv or usv32, which are short and hygienic to
the standard but pose barriers to new-comers.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12730#issuecomment-36898077
.

[brson]

This is a minor wart that I'm not inclined to change.

Why does char not allow surrogate code points?

[thestinger]

@brson: Surrogate code points aren't Unicode scalar values. They're just an implementation detail of UTF-16. The UTF-8 standard explicitly forbids encoding them too.

[SimonSapin]

I think that various names on the table here are inadequate for different reasons:

• char means different things in different contexts, and what users think of as "characters" is closer to grapheme clustuers, which can be made of multiple code points
• codepoint is not quite adequate as we exclude surrogate code points
• ucs4 I think should refer to [char] strings/vectors rather than a single char unit

That leaves rune (from Go), which I think is the best by elimination.

In Go it is exactly an alias for int32, and only represents a code point or Unicode scalar value by convention. This differs from Rust where we restrict char values to the range of Unicode scalar values, but that difference is consistent with the difference between Rust’s str that is strictly UTF-8 (unless you mess it up with unsafe code, which we would consider a bug) and Go’s string type that’s a sequence of bytes, and only by convention often contains UTF-8.

So, proposal:

• Rename char to rune (rune being a shorter name for Unicode scalar value)
• Rename accordingly functions and methods that have "char" in their name.
• Possibly have type ucs4 = [rune] (assuming DST)

[liigo]

Several people include core team ones don't like rune. I don't like it too.
Char is a good name.
2014年3月20日 下午12:14于 "Simon Sapin" notifications@github.com写道：

I think that various names on the table here are inadequate for different
reasons:

• char means different things in different contexts, and what users
  think of as "characters" is closer to grapheme clustuershttp://www.unicode.org/glossary/#grapheme_cluster,
  which can be made of multiple code points
• codepoint is not quite adequate as we exclude surrogate code points
• ucs4 I think should refer to [char] strings/vectors rather than a
  single char unit

That leaves rune (from Go), which I think is the best by elimination.

In Go it is exactly an alias for int32http://golang.org/pkg/builtin/#rune,
and only represents a code point or Unicode scalar value by convention.
This differs from Rust where we restrict char values to the range of
Unicode scalar values, but that difference is consistent with the
difference between Rust’s str that is strictly UTF-8 (unless you mess it
up with unsafe code, which we would consider a bug) and Go’s string typehttp://golang.org/pkg/builtin/#stringthat’s a sequence of bytes, and only by convention often contains UTF-8.

So, proposal:

• Rename char to rune (rune being a shorter name for Unicode scalar
  value)
• Possibly have type ucs4 = [rune](assuming DST)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12730#issuecomment-38133887
.