fix: detect conflict when generic is not of the same base type #941
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I initially thought that automatically generating wrapper types would be nice (#937), and I still think that it would, but I also now realize that it's much harder than I anticipated, at least for me with my limited knowledge of the repo/codegen flow. Using this I was able to know when I would need to wrap types with new names, but I wasn't able to figure out how to wire them up correctly to the operations so that they got generated out. And that's not even mentioning that we'd probably want to deduplicate them at some later point
This alone seems like a good start though, as it at least notifies us that there is a conflict. My specific issue was with a custom Date type that was not required, so it became OptDate just like another date field that was a string with format date and also not required. So I wound up with conflicting OptDates and no error because they both were generic.
I'm pretty sure this check could be better, but it does solve my case by alerting me to the problematic type conflicts.