-
Notifications
You must be signed in to change notification settings - Fork 22
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
More in-depth checking? #1
Comments
lantw44
added a commit
to lantw44/go-sumtype
that referenced
this issue
Apr 17, 2019
Sometimes it is possible for a sum type interface to be implemented by another interface. For example, we have a sum type called T including 3 variants, A, B, C. We also have an U interface embedding T and thus implementing T. Assuming that B and C implement U, a type switch statement can be considered exhaustive if all of A, B, C are listed. It should also be considered exhaustive if only A and U are listed. However, go-sumtype does not distinguish between concrete and interface types. It fails in both cases, requiring all of A, B, C, U to be listed. It is unlikely to code to be written in this way. U already covers B and C, and it is unnecessary to list them in a type switch statement. This commit fixes the problem by handling interfaces specially. Closes: BurntSushi#1 Closes: BurntSushi#3
diogo464
pushed a commit
to diogo464/go-sumtype
that referenced
this issue
May 1, 2022
Split `go-ipfs/routing/kbucket` into `go-libp2p-kbucket`
diogo464
pushed a commit
to diogo464/go-sumtype
that referenced
this issue
May 1, 2022
Fix bootstrapping id generation logic
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
(as noted on reddit) - this is great, I've been hankering for something like this. i have a couple sum types (
Constraint
,Version
,PairedVersion
,UnpairedVersion
) in https://github.com/sdboyer/gps, and...well, I've got a number of false positives so far, ostensibly because there's a series of composed interfaces involved, and some of the switches operate on composed interfaces, rather than the underlying dynamic types.i don't really have time to dig further right now on exactly how this works, unfortunately, but I thought I'd present it as a case to see what your thoughts are about doing a bit more in-depth analysis of type relations - e.g.,
plainVersion
implementsUnpairedVersion
, so if a switch contains a case forUnpairedVersion
, thenplainVersion
should be considered covered in exhaustiveness checks.The text was updated successfully, but these errors were encountered: