exported generic functions with generic type constraint interface = nil type

[rcoreilly]

The following program sample.go triggers an unexpected result

type DataTypes interface {
	string | bool | float32 | float64 | int | int32 | uint32 | byte
}

func MyFun[T DataTypes]() T { //yaegi::add
    v T
    return v
}

import above..

Expected result

Not crashing

Got

crashing

Yaegi Version

#1647 generics import

Additional Notes

This is specific to #1647 -- reporting here assuming that might eventually be merged?

In the above example Go code, it doesn't seem like there is a way to represent the type constraint interface DataTypes as a reflect object, and the current yaegi type system ends up returning a nil type in types.go:nodeType2 for it, with a nil error, which ends up crashing the funcType case in nodeType2, when it is processing the type parameters for MyFun per above.

I can add to the #1647 PR to return an error for a nil type, so this doesn't crash, and gives a hint to the user.

So, this is just documentation of this issue, and checking to see if anyone has any ideas about how to get around this limitation on using type constraint interfaces?

[kkoreilly]

The solution is likely to include the generic type constraint definition with //yaegi:add and then interpret it on the fly, assuming that generic type constraints work in interpreted code. This will require extending the #1647 logic to type constraints.

[cachesdev]

were can we find your fork? it seems the library is mostly unmaintained, with almost year gaps on commits/merges. no one has bothered in updating the readme either, which states that go 1.22 and 1.21 are the latest versions. I would like to contribute and get this back up to parity with Go, but it doesn't seem the maintaners are merging PRs either.

[kkoreilly]

@cachesdev We have a maintained fork at https://github.com/cogentcore/yaegi and will gladly except contributions. We did some work previously to get it mostly up-to-date with go1.23, and we would gladly accept PRs to support newer features.

We did get a series of PRs merged here a year ago, but two important ones are still not being merged, so it does seem like working on the fork may be better.

We depend on yaegicore for interactive code editing in our GUI framework, so we will continue maintaining our fork for the foreseeable future.