Тип rune в Go определяется как "псевдоним для int32 и эквивалентен int32 всеми способами. Он используется, по соглашению, для различения значений символов из целых значений."
Если намерение использовать этот тип для представления значений символов, почему авторы языка Go не использовали uint32 вместо int32? Как они ожидают, что значение руны будет обрабатываться в программе, когда оно будет отрицательным? Другой подобный тип byte является псевдонимом для uint (а не int), что разумно.
"Golang, Go: что это за руна?:
В последнем Unicode 6.3 определено более 110 000 символов. Для этого требуется, по меньшей мере, 21-битное представление каждой кодовой точки, поэтому руна похожа на int32 и имеет множество бит.
Но в отношении проблем с переполнением или отрицательным значением обратите внимание, что реализация некоторых из функций unicode, таких как unicode.IsGraphic, включает:
Преобразуем в
uint32, чтобы избежать дополнительного теста для отрицательного
код:
const MaxLatin1 = '\u00FF' // maximum Latin-1 value.
// IsGraphic reports whether the rune is defined as a Graphic by Unicode.
// Such characters include letters, marks, numbers, punctuation, symbols, and
// spaces, from categories L, M, N, P, S, Zs.
func IsGraphic(r rune) bool {
// We convert to uint32 to avoid the extra test for negative,
// and in the index we convert to uint8 to avoid the range check.
if uint32(r) <= MaxLatin1 {
return properties[uint8(r)]&pg != 0
}
return In(r, GraphicRanges...)
}
Возможно, из-за того, что руна должна быть constant (как упоминалось в "Перейти к описанию типа руны", где руна может находиться в int32 или uint32 или даже float32 или...: его постоянное значение разрешает ее хранить в любом из этих числовые типы).
Я googled и нашел это: https://groups.google.com/forum/#!topic/golang-nuts/d3_GPK8bwBg
Это задавали несколько раз. rune занимает 4 байта, а не только один, поскольку предполагается хранить кодовые страницы unicode, а не только символы ASCII. Как и индексы массива, тип данных подписывается так, что вы можете легко обнаруживать переполнения или другие ошибки при выполнении арифметики с этими типами.
Он не становится отрицательным. В Unicode имеется 1111112 кодовых точек, что далека от 2 147 483 647 (0x7fffffff) - даже учитывая все зарезервированные блоки.