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

Closed adonovan closed 7 months ago

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?
[X] Is this about generics?
[X] 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.

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.

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.

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.

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).

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.

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.

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.

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.

As suggested in an earlier comment, I did a (very unscientific) survey of the codebase I spend my dayjob maintaining, for examples that might benefit from this proposal.

This codebase seems to have a pretty even split between _, ok being used with type assertions vs. being used for testing for the presence of map keys, along with a small number of functions specific to this codebase that follow the (result, bool) convention.

During this survey I found three main situations.

Most common: Detecting what type an interface isn't, rather than what it is:
```
    if _, ok := b.(*Example); !ok {
        return fmt.Errorf(...)
    }
```
I think this is most common because this sort of negative type assertion doesn't generate any new information about what dynamic type the interface does have; the first result is always useless.

It seems that most (possibly all) of these examples would slightly benefit in conciseness from this proposal:
```
    if !is[*Example](b) {
        return fmt.Errorf(...)
    }
```
...although I have mixed feelings about whether this is more or less readable to someone who isn't already familiar with this is function, since the is identifier seems to get lost in a swamp of punctuation.
A lot less common: Detecting what type an interface (most often an error) has, without any care about the value.
```
    if _, ok := err.(SpecialError); ok {
        // Different handling for this special error type
    }
```
For errors in particular it seems relatively common for the dynamic type to be the most important information, with the data inside that value being less important. This isn't true in all cases of course -- sometimes we're treating a particular error type as special specifically so that we can rely on some fields or methods unique to that error type -- but making the decision based on type alone seems somewhat common in our codebase.

These examples could also be trivially replaced by a call to is:
```
    if is[SpecialError](err) {
        // Different handling for this special error type
    }
```

Dishonorable mention: a series of tests that could have and should have been a type switch.

    if _, ok := k.(Example1); ok {
        return Example1Result
    }
    if _, ok := k.(Example2); ok {
        return Example2Result
    }
    return OtherResult

Thankfully I found few enough examples of this that I can count them on one hand. Of course I would rewrite these to be type switches instead of adopting the is builtin for them.

    switch k.(type) {
    case Example1:
        return Example1Result
    case Example2:
        return Example2Result
    default:
        return OtherResult
    }

This survey contradicted my initial (incorrect) hunch that there wouldn't be many examples of testing the type without then using the value. I expect we'd have plenty of opportunities to use is if it were accepted as a builtin.

However, I feel ambivalent because of the highly subjective concern I mentioned above: that the very short identifier is gets visually lost in a lot of punctuation that seems to make this harder to read and understand than I had initially hoped. The longer forms we're using today are less concise, but the meaning "feels" clearer to me.

I expect this concern would reduce if I were exposed to more examples of this in real code, but I'd worry about folks who are new to Go -- who might not have yet learned to read identifer[Something] as Go's generics syntax, due to it being different to most other languages -- being unsure how to mentally parse is[*Thingy](something) as "Is *Thingy the dynamic type of something?"

Perhaps choosing a longer name would allow being more specific about what exactly this function means and thus better prime someone to guess what the following characters mean. I don't want to bikeshed about it though; I'm curious to see if others share this concern or if it's just me.

Given all of the above, I'm cautiously in favor.

It occurs to me that predeclared builtins are allowed more flexibility in their signatures, including taking types directly as arguments within the parentheses as we see with e.g. make([]Foo, 0, 5).

Therefore this proposal could presumably be spelled is(v, Type) instead, which might be more readable both due to having less punctuation and also following the typical English term order for sentences: "Is v a Type?" "Is err a ParseError?"

That of course does come at the expense of orthogonality, and at the expense of a potential opportunity to introduce a newcomer to the syntax for qualifying a generic function when type inference isn't possible.

I'd like to note that this may conflict with the package https://github.com/matryer/is is is an extremely common identifier so making it built-in now will make it hard to use. Some different name may be needed.

I'd like to note that this may conflict with the package https://github.com/matryer/is is is an extremely common identifier so making it built-in now will make it hard to use. Some different name may be needed.

That shouldn't be a problem any more than adding min() and max() were. Existing code will continue to work with no difference and anyone who wants to use it can just change the name of the import.

I wrote an analyzer to detect functions equivalent to is[T] or some instantiation of it, and ran it across a sample (min imports = 10) of the corpus of the Go module mirror. Out of 21477 modules, 548 (2.5%) define at least one function equivalent to is for some T. The query found a total of 1504 such functions. I have included a random sample of 100 of them below.

This measure undercounts situations in which is[T] would be useful. For example, it does not attempt to tally cases in which two statements:

    cond := false
    if _, ok := x.(X); ok {
        if _, ok := y.(Y); ok {
            cond = true
        }
    }
    f(cond)

could be replaced by one expression:

    f(is[X](x) && is[Y](y))

As @seankhliao points out, approximately half are concerned with errors, and I have divided the list below into two halves, non-error-related and error-related.

NON-ERROR RELATED:

ERROR-RELATED:

it looks like over half of those deal with errors, which could be errors.As(err, &T{})

@adonovan, if this was a function in the standard library instead of a builtin, would you view that as acceptable, and any brief thoughts on how you would spell it if so? (Sorry if you already mentioned this).

it looks like over half of those deal with errors, which could be errors.As(err, &T{})

A quick side note is I think @Merovius has observed that if errors.As had been designed after generics were available, it might have been errors.As[T error](err error) (T, bool) instead, which is arguably more ergonomic.

A quick side note is I think @Merovius has observed that if errors.As had been designed after generics were available, it might have been errors.As[T error](err error) (T, bool) instead, which is arguably more ergonomic.

No, generics were considered at that time and deemed less ergonomic: https://github.com/golang/go/issues/29934#issuecomment-490091428

Now, none builtin functions use the custom generic syntax. So maybe it is not a bad idea to support this function in std instead in my opinion.

BTW, @rsc's reply on the generic form of Is and As: https://github.com/golang/go/issues/29934#issuecomment-490091428 (Ah, someone posted this ahead of me. :))

Update: Thanks for all the comments. I fixed a couple bugs in the analyzer (https://go.dev/cl/570315) and re-ran it, and updated the list, now partitioned into error and non-error-related cases (roughly 50% each).

I agree that a generic errors.As would have been nice, but perhaps that ship has sailed.

if this was a function in the standard library .. how you would spell it if so?

No package springs to mind; it's essentially an operator in the language. The closest analogue is min and max, but they obviously belong in the "math" package; there's no obvious counterpart here.

Change https://go.dev/cl/570315 mentions this issue: go/analysis/passes/is: find is[T] functions

I am curious how those numbers compare to _, ok := m[k]. Are there docs somewhere about how to run these kinds of analyses and how to get a snapshot of the module proxy or is this something that requires special access?

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.

This feels like a kind of disingenuous answer. "Less frustrating breaking out of expression mode" is not a learnability benefit, it's a convenience. I think this is a pretty clear net negative (albeit not a huge one) when it comes to learnability.

Personally, I feel rather strongly that this proposal represents an inflationary attitude towards predeclared functions. For most of Go's life, we had a very limited number of predeclared identifiers and that was always advertised as a big benefit. And we only used predeclared functions for things that we could not implement in the language.

That changed with min/max, which where only made predeclared to avid the import. Now their existence is taken as evidence that we might as well add more.

Not to go all old-man-yelling-at-cloud, but I don't like it. I disliked adding min/max, I dislike is and I will probably dislike the next proposed predeclared function that creates a minor convenience.

For me it is more the problem that there are already several different kinds of is, for equality, error handling or unit testing, declared in different packages, so adding one more seem not particularly helpful, at least not with that name.

The min and max are somewhat different as they were likely used only for minimum and maximum.

For this proposal something like typeIs seems better to me.

If min and max are not builtin, then

their performance would be not good enough, because a slice is needed to be created at run time.
people are not willing to use them because a package needs to be imported but provided functionality is so tiny.

Adding to the ordinary proposal minutes, but I don't think this holds its weight. The vast majority of the time you care about the underlying type of something, you care because you want to use it. The x, ok := v.(T) form gives you the value to use. I can see how having is would be useful in complex conditionals, inside which you would re-type-assert to get the value. That may come up often in the kinds of AST code you write, but for me it almost never comes up. It's necessarily a feature of localized value.

To me at least, this doesn't seem worthwhile enough. The language already provides two forms - type assertions and type switches - so the bar for adding a third equivalent form seems quite high to me, and I don't think we have evidence here of meeting that bar.

This proposal has been added to the active column of the proposals project and will now be reviewed at the weekly proposal review meetings. — rsc for the proposal review group

func is (t any, aType ... any) (any,bool) { // if t.(type) in aType , return first aType and true // else return nil ,false }

Based on the discussion above, this proposal seems like a likely decline. — rsc for the proposal review group

No change in consensus, so declined. — rsc for the proposal review group

golang / go