コードらしいコードは書いてない...
概略
-
論理型
- bool
-
文字列型
- string
-
整数型
- 符号付き整数型
- int
- int8
- int16
- int32 ( = rune)
- int64
- 符号なし整数型
- uint
- uint8 ( = byte)
- uint16
- uint32
- uint64
- uintptr
- 符号付き整数型
-
浮動小数点型
- float32
- float64
-
複素数型
- complex64
- complex128
-
エラー型
- Error
論理型
bool
true
またはfalse
しか取りうる値が存在しない最も単純なデータ型
文字列型
string
- 8bit/byteの文字列型
- UTF-8 encodedではない場合もある
- 空文字でも
nil
でもよい - immutableである
整数型
符号付き整数型
int
最低32bit以上の符号付き整数型だが、int32
型のエイリアスではない。
int8
8bitの符号付き整数型で、-128~127の範囲の整数を表現できる。
int16
16bitの符号付き整数型で、-32768~32767の範囲の整数を表現できる。
int32 ( = rune)
32bitの符号付き整数型で、-2147483648~2147483647の範囲の整数を表現できる。
rune
はint32
型のエイリアスで、これについてはThe Go Blogに記述がある。
To summarize, here are the salient points:
- Go source code is always UTF-8.
- A string holds arbitrary bytes.
- A string literal, absent byte-level escapes, always holds valid UTF-8 sequences.
- Those sequences represent Unicode code points, called runes.
- No guarantee is made in Go that characters in strings are normalized.
和訳した。
要約すると、以下のようになります。
- Goのソースコードは常にUTF-8です。
- 文字列は任意のバイトを保持します。
- 文字列リテラルは、バイトレベルのエスケープを除いて、常に有効な UTF-8 シーケンスを保持します。
- これらのシーケンスは、runeと呼ばれる Unicode コードポイントを表しています。
- Goでは、文字列内の文字が正規化されていることを保証するものではありません。
まだちょっとわからないので調べると、こんな記述を見つけた。(出典:String と Rune — プログラミング言語 Go | text.Baldanders.infoにて)
この記事も見ると良さそう。
int64
64bitの符号付き整数型で、-9223372036854775808~9223372036854775807の範囲の整数を表現できる。
符号なし整数型
uint
最低32bit以上の符号なし整数型だが、uint32
型のエイリアスではない。
uint8 ( = byte)
8bitの符号なし整数型で、0~255の範囲の整数を表現できる。
byte
はuint8
のエイリアスで、公式Docでは以下のように説明されている。
byte is an alias for uint8 and is equivalent to uint8 in all ways. It is used, by convention, to distinguish byte values from 8-bit unsigned integer values.
byte は uint8 の別名であり、すべての点で uint8 と同等です。慣習的に、バイト値を8ビットの符号なし整数値と区別するために使用されます。
uint16
16bitの符号なし整数型で、0~65535の範囲の整数を表現できる。
uint32
32bitの符号なし整数型で、0~4294967295の範囲の整数を表現できる。
uint64
64bitの符号なし整数型で、0~18446744073709551615の範囲の整数を表現できる。
uintptr
ドキュメントを直訳すると「uintptr は、任意のポインタのビットパターンを保持するのに十分な大きさの整数型です。」となる(DeepL様様)。
どんな場面で使うんだ...と思ってたが、StackOverflowで触れられていた。
The short answer is "never use
uintptr
". 😀The long answer is that
uintptr
is there to bypass the type system and allow the Go implementors to write Go runtime libraries, including the garbage collection system, in Go, and to call C-callable code including system calls using C pointers that are not handled by Go at all.If you're acting as an implementor—e.g., providing access to system calls on a new OS—you'll need
uintptr
. You will also need to know all the special magic required to use it, such as locking your goroutine to an OS-level thread if the OS is going to do stack-ish things to OS-level threads, for instance. (If you're using it with Go pointers, you may also need to tell the compiler not to move your goroutine stack, which is done with special compile-time directives.)
どうやら低レイヤーの処理を実装しない限りはめったに使うことがないらしい。
当面は気にしないことにした。
浮動小数点型
IEEE-754式については 以下を参照。
float32
IEEE-754式の32bit浮動小数点型
float64
IEEE-754式の64bit浮動小数点型
ちなみに数学計算するためのmath
パッケージで定義された関数のほとんどは引数も返り値もfloat64
型でしか定義されていないで、注意が必要。まあGoにはオーバーロードがないので当然っちゃぁ当然。
複素数型
複素数型の扱いを確認するならこの辺の記事を見ると良さそう。
complex64
実部と虚部をfloat32型で表現する複素数型
complex128
実部と虚部をfloat64型で表現する複素数型
エラー型
error
Goにはtry-catch-finallyといったエラーハンドリング表現が存在しないので、このerror型のinterfaceに対してエラー処理を実装する。
type error interface {
Error() string
}