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

More in-depth checking? #1

Open
sdboyer opened this issue Mar 20, 2017 · 0 comments · May be fixed by #12
Open

More in-depth checking? #1

sdboyer opened this issue Mar 20, 2017 · 0 comments · May be fixed by #12

Comments

@sdboyer
Copy link

sdboyer commented Mar 20, 2017

(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 implements UnpairedVersion, so if a switch contains a case for UnpairedVersion, then plainVersion should be considered covered in exhaustiveness checks.

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
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant