Unable to count specific implementations of the Golang generic interface

[benz9527]

Tooltitude Version: v0.66.3 OS Version: Win11

VS Code Version:

Go Version: Go1.22.0

Code Repository (if open source): https://github.com/benz9527/xboot

What did you try to do? Count the generic interface implementations correctly.

[tooltitude-support]

@benz9527 Thank you for your feedback. We will see what we could do.

[tooltitude-support]

I implemented partial fix (ignoring type constraints). It will be available in the next 0.67.0 release likely this Fri. I will see what I could do with the constraints:

[tooltitude-support]

@benz9527 I have taken look, and type constraints seem to be implementable, and I see no big problems with them. We won't implement impls for interfaces without methods though. We might need to traverse the whole project to find them, which isn't a good solution.

[benz9527]

@benz9527 I have taken look, and type constraints seem to be implementable, and I see no big problems with them. We won't implement impls for interfaces without methods though. We might need to traverse the whole project to find them, which isn't a good solution.

Traversing the whole project may waste too much time. Like the goland implementation, it always builds caches, which makes goland use too much CPU and the UI run sluggishly. So I turn to use the vscode.

[tooltitude-support]

Traversing the whole project may waste too much time.

It's not only this. For example, interface {} is overly broad, and cover all types. The same goes with interface { comparable }. There's very little use in such a usage counts.

[tooltitude-support]

@benz9527 BTW, may be you miss some other features? If you miss them, feel free to share them in a comment or a separate issue. We also have a Discord chat: https://discord.gg/f9MHBXsVwr where you could discuss your ideas and problems in a more free form way.

[tooltitude-support]

@benz9527 After some research, handling type variable constraints seems to be quite complicated:

See for example:

type I[T comparable] interface {
  a(t T);
}

type S[T Reader] struct { ... }

func (s *S[T]) a(t T) { ... }

In this case some Ts implement interface, and some don't. (currently these constraints are ignored). It could even get more complicated, if S is something like this:

type S[T Reader] struct {
   readers []T
}

[benz9527]

@benz9527 After some research, handling type variable constraints seems to be quite complicated:

See for example:

type I[T comparable] interface {
  a(t T);
}

type S[T Reader] struct { ... }

func (s *S[T]) a(t T) { ... }

In this case some Ts implement interface, and some don't. (currently these constraints are ignored). It could even get more complicated, if S is something like this:

type S[T Reader] struct {
   readers []T
}

Agree

[tooltitude-support]

0.67.0 is out. Closing this issue.

Please, check that your case works there.

[tooltitude-support]

And again, thanks a lot for reporting bugs. Don't hesitate to report bug and ask for features in the future! We are really eager to fix bugs and implement new features (where it's reasonable).

I see your project is quite a generic heavy. It's quite hard to find such a project (there're some though, for example https://github.com/emirpasic/gods). Feel free to report issues with generics or type constraints you have.

[benz9527]

It works!

[benz9527]

And again, thanks a lot for reporting bugs. Don't hesitate to report bug and ask for features in the future! We are really eager to fix bugs and implement new features (where it's reasonable).

I see your project is quite a generic heavy. It's quite hard to find such a project (there're some though, for example https://github.com/emirpasic/gods). Feel free to report issues with generics or type constraints you have.

Yep, I am the Javaer to Gopher. So I kept the habit of coding with generics.