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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The guard made sure nothing was forgotten in the transform. Instead of a guard it could be an assert. But then we could not fill in the missing case (where a
derived
is not empty) intransformMoreCases
.So I think overall it's best to leave it in. Maybe add a comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did test it locally with an assert and then removed it. I could add back the assert with a meaningful message. It might be clearer this way that the
Template
was not supposed to have aderived
set.Are we only supposed to have non-empty
derived
for untyped templates? Or are there cases where the typed template is expected to have something inderived
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't know. As you tested, there are no occurrences where derived is empty when we transform. But that is not necessarily true for the future. With the original scheme we fall through into
transformMoreCases
when we see such a tree where we would fail unlesstransformMoreCases
explicitly provides for it. I think that's what we want. Anassert
is worse since it prevents the handling of the case. The chance is high that if such a case arises in the future, and we hit theassert
, we just remove it, since we have now found a legitimate case where it mis-fires. But that would be bad since then other maps would have a hole where they silently drop the derived field. So I really think the original code is the best possible design.