Go defines two different notations for similar concerns : type checking and changing

• Explicit conversions v = T(x) for static types (at compile-time)
• Type assertions v, ok = x.(T) and Type switches x.(type) for dynamic types (at run-time)

Motivation

I think type assertions and type switches notations are surprising, especially for Go newcomers, not standard, and almost redundant with Conversions notation :

• x.(T) notation isn't common in popular programming languages, evokes methods with return parameters or selector notation for interface and struct embedding. Citing Ian Lance Taylor : The "." operator is heavily overloaded in Go. […] There is no special reason for this [use in type assertion] except that it is unambiguous and looks good on the page.
• Type assertions and Conversions are often presented together in Go tutorials and rise questions from Go newcomers. Yet both notations are almost disjoint : Type assertion is used for an expression of interface type and Explicit conversion for other types (except for asserting or converting an expression of interface type into another interface, see below)
• two-forms notation (v, ok = x.(T) and v = x.(T)) is said to be similar to maps but is actually different : when retrieving an element from a map, both notations elem, ok = m[key] and elem = m[key] return zero value if key isn't found, while for type assertion, v = x.(T) triggers a run-time panic if the assertion is false.

Proposal

Merge these notations into one unique notation T(x) modeled on Conversion notation :

• Conversion remains v = T(x) and is used when dynamic type assertion isn't needed : x isn't of interface type, or if type of x and T are both interfaces and T is a subset of x's interface type (to satisfy Assignability rule in conversions)
• Type assertion v, ok = x.(T) becomes v, ok = T(x) and is used otherwise. Boolean return parameter is not optional anymore.
• Type switches switch x.(type) {} becomes : switch type(x) {}
• Keep current Type assertions/switch notation for Go1 backward compatibility, but mark them obsolete in go vet

Benefits

• simplicity and memorability : more familiar and same notation for similar concepts. "Differences from more familiar programming languages" is one of the top three major challenges identified in Go 2018 Survey
• safer : no more run-time panic on type assertion
• with distinct return parameters, keep a visible difference between dynamic type assertion (at compile-time) and static type conversion (at run-time) to help Go developers to understand this difference

Drawbacks

• form of type assertion with only one return parameter v = x.(T) won't be possible anymore. Reasons :
  • to resolve ambiguity when both operands are of Interface type and for backward compatibility
  • to let developers know whether (static) type conversion or (dynamic) type assertion is performed.

Exemple

type i1 interface {
	M() int
	N() int
}
type i2 interface {
	M() int
}
func f(v1 i1) {
	var v2, ok = i2(v1) // check dynamic type of v1 is i2
	var v3 = i2(v1)     // check i1 implements i2
	fmt.Println(v2, ok)
	fmt.Println(v3)
}