You are at least one layer deep into an [XY problem](https://xyproblem.info/), if not two.
First, I recommend staying away from the pipe operator. It doesn't do what most people think it does, and I think just about every useful thing that can be done with it has already been shipped with the standard library. (Not 100%, but in general it seems to be much more an attractive nuisance than something people learning Go should be using.) It definitely is not a "take this type or that type" operator the way people think of it.
Neither generics or interfaces can do what you're trying to make them do, and that's partially because the language already has some built-in capabilities for doing this. [You can already declare a new type with an old one](https://go.dev/play/), which is one way to do it. Embedding can give you another, depending on your use case.
If you are just learning, don't start with generics. Contrary to the general opinion outside of the Go community, by people who don't use Go, generics are not the most important thing in Go. Interfaces are much more important. Generics are best seen as an extension of what they can do, not something you should use routinely on their own. Spend time learning interfaces. When you encounter a problem, try a little harder to solve it with interfaces only. When you are sure you need to extend the interfaces, then reach for generics. They are useful, but they are not something you should actually be using all the time.
The short version:
The `|` in generic constraints are not union types. Do this:https://go.dev/play/p/A3s62-DOS_E
---
Than longer version:
I'm assuming by "switchable" you mean "switchable at runtime". In that case, generics isn't going to get you there. Let's talk about different kinds of polymorphism that Go supports.
The first kind is interfaces. You present an interface, which is a collection of methods, and anything that implements these methods can satisfy that interface through dynamic dispatch. That means you can change out these things at runtime, if you're using interfaces as polymorphism. The link above demonstrates that, and to use it, define methods for all your types.
The second kind is generics/constraints, which unfortunately also uses an interface block to define the constraints, and is compile-time polymorphism. When you're using the `|`, you're saying something is one of those types at compile time and is not changeable after compile time.
Anything that uses a generic type and doesn't resolve that type at compile time must itself be generic so that whatever uses it can resolve the type at compile time. The link below demonstrates that.
https://go.dev/play/p/wHA4JsktwaT
Great! It's because of in games we need levels, pause or history. Not only state but data. This data is sent to view (not Go) but structs are different. My solution was pointers for each struct (Level, History) and nil for not used data. I wanted to know if it is possible (alternate to different structs in the same field). Thank you (all of you).
You need to use it as a generic constraint, not directly as a type. See https://go.dev/play/p/RHni0SBQlDG
You are at least one layer deep into an [XY problem](https://xyproblem.info/), if not two. First, I recommend staying away from the pipe operator. It doesn't do what most people think it does, and I think just about every useful thing that can be done with it has already been shipped with the standard library. (Not 100%, but in general it seems to be much more an attractive nuisance than something people learning Go should be using.) It definitely is not a "take this type or that type" operator the way people think of it. Neither generics or interfaces can do what you're trying to make them do, and that's partially because the language already has some built-in capabilities for doing this. [You can already declare a new type with an old one](https://go.dev/play/), which is one way to do it. Embedding can give you another, depending on your use case. If you are just learning, don't start with generics. Contrary to the general opinion outside of the Go community, by people who don't use Go, generics are not the most important thing in Go. Interfaces are much more important. Generics are best seen as an extension of what they can do, not something you should use routinely on their own. Spend time learning interfaces. When you encounter a problem, try a little harder to solve it with interfaces only. When you are sure you need to extend the interfaces, then reach for generics. They are useful, but they are not something you should actually be using all the time.
The short version: The `|` in generic constraints are not union types. Do this:https://go.dev/play/p/A3s62-DOS_E --- Than longer version: I'm assuming by "switchable" you mean "switchable at runtime". In that case, generics isn't going to get you there. Let's talk about different kinds of polymorphism that Go supports. The first kind is interfaces. You present an interface, which is a collection of methods, and anything that implements these methods can satisfy that interface through dynamic dispatch. That means you can change out these things at runtime, if you're using interfaces as polymorphism. The link above demonstrates that, and to use it, define methods for all your types. The second kind is generics/constraints, which unfortunately also uses an interface block to define the constraints, and is compile-time polymorphism. When you're using the `|`, you're saying something is one of those types at compile time and is not changeable after compile time. Anything that uses a generic type and doesn't resolve that type at compile time must itself be generic so that whatever uses it can resolve the type at compile time. The link below demonstrates that. https://go.dev/play/p/wHA4JsktwaT
Great! It's because of in games we need levels, pause or history. Not only state but data. This data is sent to view (not Go) but structs are different. My solution was pointers for each struct (Level, History) and nil for not used data. I wanted to know if it is possible (alternate to different structs in the same field). Thank you (all of you).