Go FAQ 101

In Go, we can't break a code line at an arbitrary position. Please read line break rules in Go for details. By the rules, generally, it is not okay to break code lines just before the open brackets.

if true
{
}

for i := 0; i < 10; i++
{
}

var _ = []int
{
	1, 2, 3
}

if true;
{
}

for i := 0; i < 10; i++;
{
}

var _ = []int;
{
	1, 2, 3;
}

if true {
}

for i := 0; i < 10; i++ {
}

var _ = []int {
	1, 2, 3,
}

For the standard Go compiler, each variable declared in local code blocks must be used as a r-value (right-hand-side value) for at least once.

func f(x bool) {
	var y = 1 // y declared but not used (as r-values)
	if x {
		y = 2 // here y is used as a left-hand-side value
	}
}

In the current standard Go runtime implementation, as long as a memory block is referenced by at least one active pointer, that memory block will not be viewed as garbage and will not be collected.

All the fields of an addressable struct value can be taken addresses. If the size of the final field in a non-zero-sized struct value is zero, then taking the address of the final field in the struct value will return an address which is beyond the allocated memory block for the struct value. The returned address may point to another allocated memory block which closely follows the one allocated for the non-zero-sized struct value. As long as the returned address is stored in an active pointer value, the other allocated memory block will not get garbage collected, which may cause memory leaking.

To avoid these kinds of memory leak problems, the standard Go compiler will ensure that taking the address of the final field in a non-zero-sized struct will never return an address which is beyond the allocated memory block for the struct. The standard Go compiler implements this by padding some bytes after the final zero-sized field when needed.

If the types of all fields in a struct type are zero-sized (so the struct is also a zero-sized type), then there is no need to pad bytes in the struct, for the standard Go compiler treats zero-sized memory blocks specially.

package main

import (
	"unsafe"
	"fmt"
)

func main() {
	type T1 struct {
		a struct{}
		x int64
	}
	fmt.Println(unsafe.Sizeof(T1{})) // 8

	type T2 struct {
		x int64
		a struct{}
	}
	fmt.Println(unsafe.Sizeof(T2{})) // 16
}

For most types, this is true. In fact, this is compiler dependent. For example, for the standard Go compiler, the statement is wrong for some zero values of string types.

package main

import (
	"unsafe"
	"fmt"
)

func main() {
	var s1 string
	fmt.Println(s1 == "") // true
	fmt.Println(*(*uintptr)(unsafe.Pointer(&s1))) // 0
	var s2 = "abc"[0:0]
	fmt.Println(s2 == "") // true
	fmt.Println(*(*uintptr)(unsafe.Pointer(&s2))) // 4869856
	fmt.Println(s1 == s2) // true
}

• There are no explicit ways to specify which functions should be inlined in user programs.
• The -gcflags "-l" build option disables inlining globally, which will prevent all functions from being inline expanded.
• In user programs, there are not formal ways to prevent inlining of particular functions. You can add a line //go:noinline directive before a function declaration to prevent the function from being inlined, but this way is not guaranteed to work in the future.

days := time.Date(year, month+1, 0, 0, 0, 0, 0, time.UTC).Day()

The arguments passed to time.Date can be outside their usual ranges and will be normalized during the conversion. For example, January 32 will be converted to February 1.

package main

import (
	"time"
	"fmt"
)

func main() {
	// 2017-02-01 00:00:00 +0000 UTC
	fmt.Println(time.Date(2017, 1, 32, 0, 0, 0, 0, time.UTC))

	// 2017-01-31 23:59:59.999999999 +0000 UTC
	fmt.Println(time.Date(2017, 1, 32, 0, 0, 0, -1, time.UTC))

	// 2017-01-31 00:00:00 +0000 UTC
	fmt.Println(time.Date(2017, 2, 0, 0, 0, 0, 0, time.UTC))

	// 2016-12-31 00:00:00 +0000 UTC
	fmt.Println(time.Date(2016, 13, 0, 0, 0, 0, 0, time.UTC))

	// 2017-02-01 00:00:00 +0000 UTC
	fmt.Println(time.Date(2016, 13, 32, 0, 0, 0, 0, time.UTC))
}

1. Trim, TrimLeft, TrimRight, TrimSpace, TrimFunc, TrimLeftFunc, TrimRightFunc. These functions will trim all leading or trailing UTF-8-encoded Unicode code points (a.k.a. runes) which satisfy the specified or implied conditions (TrimSpace implies to trim all kinds of white spaces). Each of the leading or trailing runes will be checked until one doesn't satisfy the specified or implied conditions.
2. TrimPrefix, TrimSuffix. The two functions will trim the specified prefix or suffix substrings (or subslices) as a whole.

Some programmers misused the TrimLeft and TrimRight functions as TrimPrefix and TrimSuffix functions when they use the trim functions the first time. Certainly, the return results are very possible not as expected.

package main

import (
	"fmt"
	"strings"
)

func main() {
	var s = "abaay森z众xbbab"
	o := fmt.Println
	o(strings.TrimPrefix(s, "ab")) // aay森z众xbbab
	o(strings.TrimSuffix(s, "ab")) // abaay森z众xbb
	o(strings.TrimLeft(s, "ab"))   // y森z众xbbab
	o(strings.TrimRight(s, "ab"))  // abaay森z众x
	o(strings.Trim(s, "ab"))       // y森z众x
	o(strings.TrimFunc(s, func(r rune) bool {
		return r < 128 // trim all ascii chars
	})) // 森z众
}

1. The built-in print/println functions will write to standard error. The print functions in the fmt standard package will write to standard output. The print functions in the log standard package will write to standard error by default, though this can be changed using the log.SetOutput function.
2. Calls to the built-in print/println functions can't take array and struct arguments.
3. For an argument of a composite type, the built-in print/println functions write the addresses of the underlying value parts of the argument, whereas the print functions in the fmt and log standard packages try to write the value literal of the dynamic values of the interface arguments.
4. Calls to the built-in print/println functions will not make the values referenced by the arguments of the calls escape to heap, whereas the print functions in the fmt and log standard packages will.
5. If an argument has a String() string or Error() string method, the print functions in the fmt and log standard packages will try to call that method when writing the argument, whereas the built-in print/println functions will ignore methods of arguments.
6. The built-in print/println functions are not guaranteed to exist in future Go versions.

• map
• slice
• function
• struct types containing incomparable fields
• array types with incomparable element types

Types which don't support comparisons can't be used as the key type of map types.

• although map, slice and function types don't support comparisons, their values can be compared to the bare nil identifier.
• comparing two interface values with == will panic at run time if the two dynamic types of the two interface values are identical and incomparable.

On why slice, map and function types don't support comparison, please read this answer in the official Go FAQ.

An interface value can be viewed as a box which is used to encapsulate non-interface values. Only values whose types implement the type of the interface value can be boxed (encapsulated) into the interface value. In Go, there are several kinds of types whose zero values are represented as the predeclared identifier nil. An interface value boxing nothing is a zero interface value, a.k.a, a nil interface value. However an interface value boxing a nil non-interface value doesn't box nothing, so it is not, and doesn't equal to, a nil interface value.

When comparing a nil interface value and a nil non-interface value (assume they can be compared), the nil non-interface value will be converted to the type of the nil interface value before doing the comparison. The conversion result is an interface value boxing a copy of the non-interface value. The result interface value doesn't box nothing, so it is not, or doesn't equal to, the nil interface value.

Please read interfaces in Go and nils in Go for detailed explanations.

package main

import "fmt"

func main() {
	var pi *int = nil
	var pb *bool = nil
	var x interface{} = pi
	var y interface{} = pb
	var z interface{} = nil

	fmt.Println(x == y)   // false
	fmt.Println(x == nil) // false
	fmt.Println(y == nil) // false
	fmt.Println(x == z)   // false
	fmt.Println(y == z)   // false
}

In Go, values of a slice type can be converted to another slice type without using the unsafe mechanisms only if the two slice types share the same underlying type. (This article lists the full list of value conversion rules.)

The underlying type of an unnamed composite type is the composite type itself. So even if two different types T1 and T2 share the same underlying type, type []T1 and []T2 are still different types, so their underlying types are also different, which means values of one of them can't be converted to the other.

• the request of converting values of []T1 and []T2 to each other is not strong in practice.
• to make the underlying type tracing rules simpler.

The same reasons are also valid for other composite types. For example, type map[T]T1 and map[T]T2 also don't share the same underlying type even if T1 and T2 share the same underlying type.

package main

import (
	"fmt"
	"unsafe"
)

func main() {
	type MyInt int

	var a = []int{7, 8, 9}
	var b = *(*[]MyInt)(unsafe.Pointer(&a))
	b[0]= 123
	fmt.Println(a) // [123 8 9]
	fmt.Println(b) // [123 8 9]
	fmt.Printf("%T \n", a) // []int
	fmt.Printf("%T \n", b) // []main.MyInt
}

• bytes in strings
• map elements
• dynamic values of interface values (exposed by type assertions)
• constant values (including named constants and literals)
• package level functions
• methods (used as function values)
• intermediate values
  • function calls
  • explicit value conversions
  • all sorts of operations, excluding pointer dereference operations, but including:
    • channel receive operations
    • sub-string operations
    • sub-slice operations
    • addition, subtraction, multiplication, and division, etc.

• variables
• fields of addressable structs
• elements of addressable arrays
• elements of any slices (whether the slices are addressable or not)
• pointer dereference operations

struct {
	// elements references an element sequence.
	elements unsafe.Pointer
	length   int
	capacity int
}

Each slice indirectly references an underlying element sequence internally. Although a non-nil slice is not addressable, its internal element sequence is always allocated somewhere and must be addressable. Taking addresses of elements of a slice is taking the addresses of elements of the internal element sequence actually. This is why elements of unaddressable non-nil slices are always addressable.

• A value of type T can call methods of type *T, but only if the value of T is addressable. Compilers will take the address of the T value automatically before calling the pointer receiver methods. Because type T can have values that are not addressable, not all values of type T are capable of calling methods of type *T.

  This convenience is just a sugar, not an intrinsic rule.

• A value of type *T can always call methods of type T. This is because it is always legal to dereference a pointer value.

  This convenience is not only a sugar, but also an intrinsic rule.

So, it makes sense that the method set of *T is always a super set of the method set of T, but not vice versa.

func (t T) MethodX(v0 ParamType0, ...) (ResultType0, ...) {
	...
}

// An implicit method of *T is automatically defined as
func (pt *T) MethodX(v0 ParamType0, ...) (ResultType0, ...) {
	return (*pt).MethodX(v0, ...)
}

1. the values which have no addresses (so they are not addressable).
2. the values which have addresses but are not addressable (their addresses are not allowed to be taken in syntax).
3. the values which are addressable but their values are not allowed to be modified in syntax.

In Go, up to now (Go 1.20), there are no values satisfy the third definition. In other words, the third definition is not supported.

Name constant values satisfy the first definition.

Methods and package-level functions can also viewed as declared immutable values. They satisfy the second definition. String elements (bytes) also satisfy the second definition.

There are no ways to declare other custom immutable named values in Go.

package main

import "fmt"

func main() {
	var s0 = "Go"

	var bs = []byte(s0)
	var s1 = string(bs)

	var rs = []rune(s0)
	var s2 = string(rs)

	fmt.Println(s0 == s1) // true
	fmt.Println(s0 == s2) // true
}

About more on strings, please read strings in Go.

import (
	"unsafe"
	"sync/atomic"
)

type T int // just a demo

var p *T

func demo(newP *T) {
	// load
	var _ = (*T)(atomic.LoadPointer(
		(*unsafe.Pointer)(unsafe.Pointer(&p)),
		))

	// store
	atomic.StorePointer(
		(*unsafe.Pointer)(unsafe.Pointer(&p)),
		unsafe.Pointer(newP),
		)


	// swap
	var oldP = (*T)(atomic.SwapPointer(
		(*unsafe.Pointer)(unsafe.Pointer(&p)),
		unsafe.Pointer(newP),
		))

	// compare and swap
	var swapped = atomic.CompareAndSwapPointer(
		(*unsafe.Pointer)(unsafe.Pointer(&p)),
		unsafe.Pointer(oldP),
		unsafe.Pointer(newP),
		)

	_ = swapped
}

Yes, now it is very verbose to use the pointer atomic functions.