Radar · Go · Archive · Week 16 · Apr 13 – 19, 2026

spec: type inferred composite literals

Worth knowinglanguage

What changed: Composite literals may omit the type; the grammar now allows an optional type before the literal value, and assignability rules are extended to support this.
Production impact: The source does not say.
Try it: x := []int{1, 2, 3} can now be written as {1, 2, 3} in a context where the type is inferred.
Source: github.com/golang/go/issues/12854

Understand it, then run it

Composite literals are the way Go builds values for structs, arrays, slices and maps. Before the change a literal always started with a type, like []int{1,2,3}. The new rule lets you drop that type when the compiler can infer it, so you can write {1,2,3}. The compiler now treats such an untyped literal as assignable to any matching composite type.

Run it now

Todaygo

// This program demonstrates that untyped composite literals are not yet
// supported in Go 1.27.1. It uses a typed composite literal instead,
// which is the current way to create a slice of strings.
package main

import "fmt"

func main() {
	// Typed composite literal: the type []string is explicitly specified.
	x := []string{"a", "b", "c"}
	fmt.Println(x)
}

What it printed when we ran it on Go 1.27.1

[a b c]

Run sends this program (for Solidity, the contract and its tests) to our own sandbox, where it is compiled and run once, with no network, and what it printed or the test report comes back here. Nothing is kept. Runs are counted per visitor for the day so everyone gets a turn; the details are on the legal page.

Written by gpt-oss-20b from the linked source · claims checked against the sources · archive, not individually reviewed