proposal: spec: add builtin func 'is[T any](any) bool'

[adonovan]

Go Programming Experience

Experienced

Other Languages Experience

many

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?

Not to my knowledge.

Does this affect error handling?

No.

Is this about generics?

Indirectly.

Proposal

I propose that we add an intrinsic is function, equivalent to this Go declaration:

// Is[T] reports whether the type assertion x.(T) would succeed.
func is[T any](x any) bool {
     _, ok := x.(T)
    return ok
}

This operator makes it possible to test the type of an interface without breaking out of expression mode, which is especially helpful when writing code that makes heavy use of sum types, such as syntax trees, types, XML documents, and so on.

if len(calleeDecl.Body.List) == 1 &&
                is[*ast.ReturnStmt](calleeDecl.Body.List[0]) &&
                len(calleeDecl.Body.List[0].(*ast.ReturnStmt).Results) > 0 { // not a bare return

Of course, one can write this function in Go or import it from a package, but like min and max it is ubiquitous and fundamental, and warrants a short name.

Language Spec Changes

The universe scope defines an is function, whose declaration is equivalent to the Go code shown above.

Informal Change

The is operator performs a test of an interface's dynamic type.

Is this change backward compatible?

Yes.

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

Very orthogonal.

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

No net change. Harder, because one more thing to learn; easier, because less frustrating breaking out of expression mode.

Cost Description

No response

Changes to Go ToolChain

local changes to cmd/compile, go/types, a few others

Performance Costs

none

Prototype

See above.

[jimmyfrasche]

A more general builtin, and one that could not be written in the language today, would take anything with a 1- or 2-value form and return the second value. For lack of a better name I'll call it snd for second. With that you could write snd(v.(T)) or snd(m[k]). I have felt the need for this far more for maps, personally. That would also suggest a both builtin that forces the 2-value return. I have wanted both of those before, though mostly snd.

[adonovan]

A more general builtin, and one that could not be written in the language today, would take anything with a 1- or 2-value form and return the second value. For lack of a better name I'll call it snd for second. With that you could write snd(v.(T)) or snd(m[k]). I have felt the need for this far more for maps, personally. That would also suggest a both builtin that forces the 2-value return. I have wanted both of those before, though mostly snd.

That is more general, but less clear:

• snd(m[k]) would ask whether k is present in a map. You can write this today as m[k] (if all elements are true), or m[k] != nil or m[k] != 0 if the map contains only nonzero values, which is the common case. In the rare case that you want to distinguish absence from zero, it would be clearer to declare contains(m, k) as a function or use the explicit ,ok form.
• snd(<-ch) would tell you whether you received a value from the channel, but would throw that value away. I can't think of a time I've needed that operation, but the fact is that concurrency operations are far less common than ordinary computation, and because of the side effects they essentially never appear in the middle of an expression context where using a statement would be onerous.

So it doesn't seem to me to be the right axis for generalization.

[jimmyfrasche]

I have written plenty of code that wants to know if a value is in a map that must distinguish between zero and absent. Far more often than it was okay to rely on zero and absent being the same. I've wanted is maybe 3 or 4 times. I've wanted return both(m[k]) much more often and that's pretty rare.

Agreed that snd(<-ch) is fairly useless.

[DeedleFake]

I would like it to be possible to expand the optional-second-value expressions in certain circumstances. For example,

func Example[T any](v T) T { return v }
func Example2[T any](v T, ok bool) bool { return ok }

Example(m[k]) // Currently legal.
Example2(m[k]) // Not currently legal.

With that available, it would be extremely easy to just write a snd() implementation in those cases where it's useful without it being pre-declared and thus encouraging things like snd(<-c).

[adonovan]

With that available, it would be extremely easy to just write a snd() implementation in those cases where it's useful without it being pre-declared and thus encouraging things like snd(<-c).

We're losing sight of the point. It's already possible to write an is implementation in those cases where it is useful, just like it is for max and min. The point of this issue is that there are so many such cases that it justifies being a buillt-in.

Evidence: grep for if _, ok := .*[.]\(.*\); ok on your favorite repo.

[gophun]

Evidence: grep for if _, ok := .[.](.); ok on your favorite repo.

However, this grep alone does not indicate whether these occurrences would noticeably benefit from being usable in an expression. The difference between using if is[T](x) { and if _, ok := x.(T); ok { by itself is so minor that it doesn't even save a line.

[timothy-king]

The difference between using if isT { and if _, ok := x.(T); ok { by itself is so minor that it doesn't even save a line.

is[T] composes a bit nicer if one needs to do multiple matches, e.g. x is a T and x.F is a U and x.G is a V if x, ok := x.(T); ok && is[U](x.F) && is[V](x.G) {}. This starts to save lines.

But the main question is whether the new builtin improves the readability of the code more than the cost of adding a new builtin into the language.

is[T] would help the readability for x/tools but YMMV.

[zephyrtronium]

A thing I frequently see, especially with people first coming to Go from dynamically typed languages, is overuse of []any and map[string]any especially when working with JSON. I worry that having this is builtin would encourage trudging through that approach rather than defining types.

And personally, I don't find that there are many cases calling for is. Running a grep for just _, ok on all code I have cloned for work finds zero uses for type assertions, only map lookups plus some channel receives in tests, out of about 168k lines of Go.