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

splat expression upgrading an unknown value should be unknown #493

Merged
merged 1 commit into from
Nov 18, 2021

Conversation

jbardin
Copy link
Member

@jbardin jbardin commented Nov 18, 2021

When a splat expression is used to upgrade an unknown value to a list with a single value, the result must be entirely unknown.

Using a splat expression to expand a single non-list value will result in a list with a single value, unless that value is null, in which case it will result in an empty list. This means that if ukstr is an unknown string value, then unkstr[*] could either result in a list of 1 string value, or an empty list, hence the result of unkstr[*] must be entirely unknown.

When a splat expression is used to upgrade an unknown value to a list
with a single value, the result must be entirely unknown. For example,
if `ukstr` is an unknown string value, then `unkstr.*` could either
result in a list of 1 string value, or an empty list, depending on
whether the result is a string or null.
Copy link
Contributor

@apparentlymart apparentlymart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for looking into this, @jbardin!

It does feel like we've been gradually stepping towards a broad rule "if the given value is unknown then the result is just immediately cty.DynamicVal" by gradually finding weird ways that our more-specific type inference rules weren't correct, but what you did here does seem correct to me and I'd rather keep the precise type information if we can, so mainly this paragraph is just me telling myself that if we find yet another of these weird exceptions then next time the answer is probably just a blanket rule and accept that the behavior of this operator is complex enough that it's justified to discard type information and just figure things out at "runtime". (that is, once all of the values are known)

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 this pull request may close these issues.

2 participants