Predeclared types

February 16, 2023

Types

The language predeclares certain type names. Others are introduced with type declarations or type parameter lists. Composite types—array, struct, pointer, function, interface, slice, map, and channel types—may be constructed using type literals.

Type declarations, type parameter lists, and type aliases are coming up later, so today we’re focused on the predeclared types.

The list of predclared types would appear near the beginning of most intro to Go books (I would know, I just read and reviewed 11 of them!). In the Go spec, they appear about a third of the way through. So we’re jumping ahead to enumerate them. These are all of the predeclared, or “basic” types in Go.

Type Name Description
any Alias for interface{}, the empty interface
bool Boolean, possible values are true and false
byte Alias for uint8
comparable Denotes all non-interface types that are strictly comparable
complex64 A 64-bit complex number
complex128 A 128-bit complex number
error Interface type used to report errors
float32 32-bit floating point number
float64 64-bit floating point number
int A 32- or 64-bit signed integer*
int8 An 8-bit signed integer
int16 A 16-bit signed integer
int32 A 32-bit signed integer
int64 A 64-bit signed integer
rune Alias for int32, A Unicode codepoint
string A string of Unicode characters
uint A 32- or 64-bit unsigned integer*
uint8 An 8-bit unsigned integer
uint16 A 16-bit unsigned integer
uint32 A 32-bit unsigned integer
uint64 A 64-bit unsigned integer
uintptr An unsigned integer large enough for a pointer value*

* The size of these types is architecture-dependent.

Quotes from The Go Programming Language Specification, Version of January 19, 2023


Share this

Direct to your inbox, daily. I respect your privacy .

Unsure? Browse the archive .

Related Content


Context key type: Final recommendation

First, a correction! An astute reader pointed out that I made a small mistake in my post on June, 10, with regard to string context keys. My code example showed: type contextKey string const ( KeyUserID = "user_id" KeyTransactionID = "transaction_id" KeyMessageID = "message_id" ) But it should have been: type contextKey string const ( KeyUserID contextKey = "user_id" KeyTransactionID contextKey = "transaction_id" KeyMessageID contextKey = "message_id" ) This is a nasty kind of bug, because the code will continue to work as expected—just without any protection from key collisions!


Struct context keys

First off, an apology for being rather unreliable with my “daily” emails. I’m in the middle of some traveling (was in the UK and Netherlands last week, and will be on a US road trip starting tomorrow), so I’m writing when I have a spare moment, which isn’t that often. I’ve been talking about finding the ideal type for a context key. So far I’ve looked at empty structs (e.g. struct{}), integers, and strings.


String context keys

By now we’ve looked at empty structs (struct{}), and integers as possible context key types. Today, let’s consider string context keys. type contextKey string const ( KeyUserID contextKey = "user_id" KeyTransactionID contextKey = "transaction_id" KeyMessageID contextKey = "message_id" ) How does this stack up against our 5 criteria? Must be comparable. ✅ Check. Use minimal memory. ✅ Using a string will typically use a bit more memory than an integer (typically 32 bytes vs 16), but still quite minimal.

Get daily content like this in your inbox!

Subscribe