proposal: Allow omitting types in callbacks if they can be inferred from the parameters

[wasserholz]

Go Programming Experience

Intermediate

Other Languages Experience

JS, Java, Python, Delphi, C

Related Idea

• Has this idea, or one like it, been proposed before?
• Does this affect error handling?
• Is this about generics?
• Is this change backward compatible? Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit

Has this idea, or one like it, been proposed before?

#21498
This issue is more general in how anonymous functions should behave, but it is not clearly defined in that proposal what should be done.

Does this affect error handling?

No

Is this about generics?

No, this is about inferring types from context in anonymous functions.

Proposal

It is possible to omit types for parameters in anonymous functions when the types can be inferred from the context.

Return type can be omitted because it can be inferred from the returned value in the anonymous function.
Parameter types are omitted as they can be inferred from the outer function declaration.

Language Spec Changes

Anonymous functions used as parameters in other functions can be written without re-declaring the parameter and return types, making anonymous functions more concise.

Informal Change

While using anonymous functions as parameters for other functions, the type definitions for the parameters and return values can be omitted, because the can be inferred from the context.

Is this change backward compatible?

Yes.

Given these functions:

func Map[T, V any](slice []T, accessor func(value T, index int) V) []V {
	output := make([]V, len(slice))
	for i, v := range slice {
		output[i] = accessor(v, i)
	}
	return output
}

func MapIntToString(slice []int, accessor func(value int, index int) string) []string {
	output := make([]string, len(slice))
	for i, v := range slice {
		output[i] = accessor(v, i)
	}
	return output
}

Their usage would currently looks like this:

func main() {
	nums := []int{1, 2, 3, 4}
	strings1 := Map(nums, func(v int, i int) string { return fmt.Sprintf("number: %v", v) })
	log.Print(strings1)

	strings2 := MapIntToString(nums, func(v int, i int) string { return fmt.Sprintf("number: %v", v) })
	log.Print(strings2)
}

Expected usage with this proposal:

func main() {
	nums := []int{1, 2, 3, 4}
	strings1 := Map(nums, func(v, i) { return fmt.Sprintf("number: %v", v) })
	log.Print(strings1)

	strings2 := MapIntToString(nums, func(v, i) { return fmt.Sprintf("number: %v", v) })
	log.Print(strings2)
}

Orthogonality: How does this change interact or overlap with existing features?

No response

Would this change make Go easier or harder to learn, and why?

No response

Cost Description

No response

Changes to Go ToolChain

No response

Performance Costs

No response

Prototype

No response

[zephyrtronium]

This seems to be the same as @earthboundkid's recent suggestion in #21498. As described there, the proposed syntax already has a meaning, so this would break code that is valid today.

[earthboundkid]

Yes, unfortunately, I don't think this is possible without changing the meaning of existing code.

[ianlancetaylor]

Closing as dup of #21498, which covers the same idea.