#19778 and #20621 are a concrete proposal that I believe intends to address many of the same use-cases, although if I understand correctly, neither proposed to add something analogous to a looser type-switch.

The other interesting case for assignability vs. type is untyped constants, which receive a default concrete type whenever they are passed as variables.

At any rate: as you note, you can use reflect.ConvertibleTo to achieve similar results in many cases (https://play.golang.org/p/9zsFD2siUwr), without a change to the language. Can you give some concrete examples where that materially complicates the code?

(How often would a feature to address this help in practice, especially given the possibility of generics as an alternative way to spend the feature budget?)

That said, in general we expect proposals to come with a concrete proposal. (It's fine to solicit alternatives, but if we really have no idea how to address a problem then there's not much point keeping an issue open for it.)

So a concrete proposal would be really helpful here, even if it has known flaws.

I was sort of secretly hoping that the answer was "haha there's already a perfectly good solution, why don't you..." and I just missed it.

Hmm. Okay, though, here's at least an easy way to express the thing:

Assignable/Convertable Type Switches and Assertions

A type assertion may take the additional forms value.(~T) or value.(~~T). In the former case, the assertion is considered true if value's type is assignable to T; in the latter, the assertion is considered true if the value's type is convertible to T (and the resulting value is converted).

Similarly, the types used in the cases of a type switch may be prefixed with one or two ~ characters, indicating approximation. Thus:

type X int

...
var x X
var i interface{} = x
if _, ok := i.(int); ok { fmt.Println("no") }
if _, ok := i.(~int); ok { fmt.Println("no") }
if _, ok := i.(~float); ok { fmt.Println("no") }
if _, ok := i.(~~float); ok { fmt.Println("yes") }

This would also work the other way. Thus, if you had a plugin.Lookup value of type func(int) error, and type XFunc func(int) error, a type assertion on (~XFunc) would match.

I think ~ is currently impossible here lexically so it doesn't break existing code, assignability and convertability tests are an established thing...

Looking at this... I'm not sure whether this is enough clearer or more expressive than the reflect operations to justify a language change. The comparison is basically:

if f, ok := fn.(~DesiredType); ok {
// CODE
}

vs

var f DesiredType
fp := &f
if reflect.TypeOf(fn).AssignableTo(reflect.TypeOf(f)) {
	reflect.ValueOf(fp).Elem().Set(reflect.ValueOf(fn))
//CODE
}

If there's a way to get rid of the need for the separate fp, it has thus far escaped me. This isn't necessarily a huge problem for the rest of the code, but I'm not at all confident that a casual reader can parse this cleanly.

Generally the pattern I've seen is to pull the reflect.TypeOf call up to a package-level variable:

var desiredType = reflect.TypeOf(*new(DesiredType))

[…]

	if reflect.TypeOf(fn).AssignableTo(desiredType) {
		[…]
	}

Hmm. Yeah, that seems a bit nicer. I think it's still necessary to have the pointer object around to use Set, though. I dunno. It's certainly a lot more to read, but it's not insane, and it's reasonably isolatable.

The idea of loosened type asertions and switches with ~ prefixes seems nice and is backwards compatible. But for your use case, couldn't you use an alias in stead of a type definition for your function types and use that?

Something like this:

package main

import (
	"fmt"
)

type X int

type FuncPtrX = func() *X

func A() *X {
	return nil
}

func isItFuncPtrX(in interface{}) {
	if _, ok := in.(FuncPtrX); !ok {
		fmt.Printf("not a FuncPtrX: %T\n", in)
	} else {
		fmt.Printf("isItFuncPtrX OK\n")
	}
}

func isItFuncX(in interface{}) {
	if _, ok := in.(func() *X); !ok {
		fmt.Printf("not a func() *X: %T\n", in)
	} else {
		fmt.Printf("isItFuncX OK\n")
	}
}

func main() {
	isItFuncPtrX(A)
	isItFuncPtrX(func() *X { return nil })
	isItFuncX(A)
	isItFuncX(func() *X { return nil })
}

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

Ooh, that hadn't occurred to me. Yes, I probably could. It's slightly less useful in the non-function case, where I want to distinguish things actually of the type from merely-same-underlying-type, but it seems like it'd work.

I think this is a combination of two minor warts; one is that you can't give a function a defined type, the other is that it's occasionally desireable to have a way to do assignability/conversion tests for things other than interfaces. And this particular use case just happens to overlap them. If functions could have defined types, I'd probably never have noticed the assignability-test question, and if the assignability-test existed, I probably wouldn't have really thought about the defined types.

This overlaps a bit with #30931, which is a proposal for allowing defined/named types for functions.

Thanks. I think you're right that the most annoying case arises when converting to function types, and it seems that using an alias addresses that case. Other than for function types I think it's rare to want to ask whether an interface type is assignable or convertible to some other type, and the reflect package is available for cases where that is important. So this doesn't seem to justify adding a new language feature.