Stop detecting longform Optional expression types. #135
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.
In #77, I added code to find
Optional<Generic>.self
and treat the reference asGeneric?.self
. This detection was added so that we could throw an error whenfulfillingAdditionalTypes
was written as a longform optional (Optional<Generic>
) rather than a shortform optional (Generic?
).However, this detection can be wrong. If someone were to define a nested
Optional
type and then refer to it infulfillingAdditionalTypes
without qualification, we'd parse it incorrectly. Fixing this issue would require having locally defined type context at thevar typeDescription: TypeDescription
scope, which isn't feasible.While this particular issue is likely quite rare, it's not worth introducing this kind of trap door in order to protect consumers from trying to
fulfillingAdditionalTypes
with a longform optional: there are all kinds of potentialfulfillingAdditionalTypes
failures—like fulfilling non-subclassable concrete types—that we do not error on because we do not have enough information to detect it.I also updated placement of
return
while I was here.