-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
doc: document idiomatic way to ensure that type satisfies a generic constraint #50813
Comments
Would this work? https://gotipplay.golang.org/p/EKwVbjuZYEK var _ any = TI[int](Concrete{}) |
No, that's for |
CC @ianlancetaylor maybe? |
The best I can come up with is func SatisfiesCI[_ CI[int]]() {}
var _ = SatisfiesCI[Concrete] Anybody have any other ideas? |
This? https://gotipplay.golang.org/p/lq3GDh15HpB type _ interface {
CI[int]
Concrete
} |
@ydnar I don't see how that ensures that |
This version does it in a single declaration, but you still have to give the declaration a real name: type SatisfiesCI[_ CI[int]] struct {
_ *SatisfiesCI[Concrete]
} |
One of my first tries at this tried to define a variable with an anonymous struct and assign it, but I quickly discovered you can't add a type parameter to an anonymous struct so that didn't work... and it's a lot of punctuation.
ianlancetaylor's single definition is better than the functional definition.. but it's not terribly obvious what it's doing (though maybe that's why it should be named?). Though, I guess is the standard idiom really all that obvious if you haven't seen it before either? One could add a general 'Satisfies' function to the
|
I've been using this one from Ian with a specific flavor. I create the
I found that the single-declaration version that Ian came up with is really difficult to write correctly, really difficult to read, and particularly if there are a few generic parameters you're doing a lot of duplication of text. |
Moving to Backlog. |
Just hit this issue. We're looking at implementing some container/collection classes, and I wanted to be able to enforce that a particular generic type implementation satisfies a specific generic interface. For example, I might want to be able to assert that both I can write something like |
Inspired by type alias syntax ( type T int
type T == fmt.Stringer
type T == error
func (v T) String() string {
return strconv.Itoa(v)
}
func (v T) Error() string {
return v.String()
} |
What version of Go are you using (
go version
)?What did you do?
https://gotipplay.golang.org/p/RX-7wE7yCzp
Description
The current FAQ describes the idiomatic way to ensure your type satisfies an interface. I find I use this idiom a lot to make sure I don't accidentally break concrete implementations of things that are only used by a few consumers of a library, but not necessarily in the library itself (... or maybe I'm too lazy to write a test for it
).
As I was migrating a project to see what it would look like under generics, I made some of the interfaces generic and that worked fine. Unfortunately, this sort of check doesn't work with constraints, and there doesn't seem to be a good way to ensure that your type satisfies the constraint other than creating a function to do so.
I get why you can't assign to a constraint interface -- you can't create variables that "are a constraint".
It would be good for someone more experienced with generics to decide on an idiomatic way to do this sort of 'constraint assertion', and make sure it ends up in the FAQ. It's possible there isn't a non-clunky way right now, and that this issue would need to be deferred until more experience is had with generics.
It's also possible I missed an earlier issue/discussion that asked for this, in which case I apologize (but I did look!).
The text was updated successfully, but these errors were encountered: