The typeof keyword proposed in #34515 might be a bit clearer:

	var f typeof(Filter) = func(x int) bool {
		[…]
	}

or

	var f Filter.(type) = func(x int) bool {
		[…]
	}

At https://blog.golang.org/go2-here-we-come Robert laid out some guidelines for language changes, including that a change should "address an important issue for many people." It's not clear to me that this meets that bar. I'm not even sure when someone would want to use this feature.

You can already do this with the existing language features, like this example:

package main

import (
	"fmt"
)

type Filter func (int) bool

func (f Filter) Apply(in []int) []int {
	res := []int{}
	for _, v := range in {
		if f(v) {
			res = append(res, v)
		}
	}
	return res
}


func main() {
	arr := []int{7, 9, 3, 5}
	var filter Filter = func(i int) bool {
		return i > 6
	}
	
	res := filter.Apply(arr)	
	fmt.Printf("arr -> res: %v -> %v\n", arr, res)
}

https://play.golang.org/p/MmcSA6FwlbV

So yes, you need to write a function type definition and a function that matches it separately, but It would be confusing for a function definition to also be an implicit type definition.

I forgot to mention another benefit of this proposal.
This proposal partially compensates for the regret that lack of supporting final error values in Go.
For example, we can use foo.ErrXXX as a final error value:

package foo

func ErrXXX() {}

func (ErrXXX) Error() string {
	return "ErrXXX"
}

This proposal doesn't seem to have much support and doesn't seem to solve an important problem. The suggestion from @bcmills seems more like Go if we want to make any changes in this direction. The comment above suggests that ErrXXX can be a constant error value, but this seems like a roundabout way to implement that. For these reasons, this is a likely decline. Leaving open for four weeks for final comments.

There were no further comments.