Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect pointer to interface #2

Closed
d-enk opened this issue May 6, 2024 · 9 comments · Fixed by #3
Closed

Incorrect pointer to interface #2

d-enk opened this issue May 6, 2024 · 9 comments · Fixed by #3

Comments

@d-enk
Copy link
Contributor

d-enk commented May 6, 2024

// Replace output when given type is `any` or `interface{}`, but not a custom interface.
func getInterfaceType(typeOfT reflect.Type) string {

Why?

package main

import (
	"fmt"

	typetostring "github.com/samber/go-type-to-string"
)

func main() {
	type I interface {}

	fmt.Println(typetostring.GetType[I]())   // *main.I
	fmt.Println(typetostring.GetType[*I]())  // *main.I
	fmt.Println(typetostring.GetType[**I]()) // **main.I
}
@samber
Copy link
Owner

samber commented May 7, 2024

Without the getInterfaceType hack, typetostring.GetType[interface{}]() would return *interface {}.

This is a know limitation.

If you have a better way to handle this case, I would be very happy to accept your contribution!!

@d-enk
Copy link
Contributor Author

d-enk commented May 7, 2024

Meant why only for any
What about trim * for all

return t[1:]

@samber
Copy link
Owner

samber commented May 8, 2024

We cannot disable all *, beucase we need to differentiate *string et string.

You can disable the getInterfaceType hack and iterate with existing unit test.

@d-enk
Copy link
Contributor Author

d-enk commented May 8, 2024

Not ALL*, only for interface. when reflect.TypeOf(t) == nil

@d-enk d-enk mentioned this issue May 8, 2024
@d-enk
Copy link
Contributor Author

d-enk commented May 9, 2024

This behavior wasn't planned, was it?

https://play.golang.com/p/RM9X82ZRprN

@samber samber closed this as completed in #3 May 9, 2024
@samber samber reopened this May 9, 2024
@samber
Copy link
Owner

samber commented May 9, 2024

@d-enk not planned indeed, and it seems that the previous commit changed the behavior

TBH, I have no opinion on this.

About samber/do, I don't think it makes any difference, since any type is unexpected.

@d-enk d-enk closed this as completed May 10, 2024
@d-enk
Copy link
Contributor Author

d-enk commented May 13, 2024

You are confused here

- `any("foobar")` reported as `string` instead of `any` (see #2)

After 1.3.0 there will be any
No try to unpack interface (not only any)

@d-enk d-enk reopened this May 13, 2024
@samber
Copy link
Owner

samber commented May 13, 2024

Yes, this is why I listed this in the "not supported yet" section.

I just updated the readme to make it clearer.

@d-enk
Copy link
Contributor Author

d-enk commented May 13, 2024

OK. I'll add an explanation of reason here too. Just

type I interface {
  // ...
}

The same type as any other (in the context of this package)
which has its own name.

@d-enk d-enk closed this as completed May 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants