proposal: spec: permit using var.(type) when instantiating a generic function

[boobusy]

type Demo struct{}
func UseFunc[T any]() {}

var value = new(Demo)
UseFunc[value.(type)]()

build error: invalid AST: use of .(type) outside type switch.

Hope to support value.(type) in generics code.

[DeedleFake]

This seems like an extension of #34515 to add support for explicit generic instantiations, too.

[ianlancetaylor]

CC @griesemer

Can you give an example where this would be useful? Thanks.

[zigo101]

Sometimes this feature provides a convenience that we don't need to import the package in which the value type is declared.

[zigo101]

Another benefit is that this feature will generalize the vaue.(type) syntax so that it will be not a bizarre existence any more.

[DeedleFake]

It would help with the irregularity some, but a type switch with a variable would still be irregular. A regular switch with a variable looks like

switch v := f(); v {
  // ...
}

while a type switch with a variable looks like

switch v := i.(type) {
  // ...
}

[zigo101]

switch v := i.(type) {
  // ...
}

may be viewed as a short-from of

switch v, T := i.(type); T {
  // ...
}

[aarzilli]

Would this only be allowed if value has a non-interface type?

func g[T any]() {
...
}

func f(x any) {
    g[x.(type)]()
}

[adonovan]

I can imagine this is theoretically useful when you want to instantiate f[T] with a type T that you are not allowed to spell out because it involves the name of an unexported type from another package. But that seems pretty rare: usually f has parameters or results that are sufficient for type inference to do its thing, so UseFunc, which has neither, is quite unusual.

Can you provide a realistic example?

[apparentlymart]

My experience with type switches and type assertions lead me to assume that the value.(type) here would be inspecting the dynamic type of value, but I can see from the example that this isn't true because value is of a struct type, not of an interface type.

I'd worry about making it ambiguous whether .(type) refers to the static type or the dynamic type of a value depending on context. Aside from being potentially confusing, it seems like an ambiguity hazard for future evolution of the language where in some contexts it might be important to distinguish dynamic type vs. static type.

I'd prefer to see a different syntax for writing "the static type of this value", so that it's clear how future language features might support both static and dynamic types in the same position, and so that a reader can clearly see which of the two a particular expression is referring to without having detailed knowledge of the language specification. However, I must admit I don't have a specific proposal for that; so far I can't think of any other situation where it's been necessary to express "the static type of this value", so I can't find precedent to copy.