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

functions/stdlib/merge: return an empty object when all inputs are null #82

Merged
merged 2 commits into from
Dec 16, 2020

Conversation

mildwonkey
Copy link
Contributor

It seems intuitive for merge() to return an empty object when the inputs
are null (or omitted entirely) - returning an error would likely break
many terraform configurations, and returning an empty object rather than
null seems more consistent with the documented behavior (though it is
not explicit!).

I dug through the commit history and compared terraform's documentation,
post pre- and post-hcl2, and did not find any clues as to why it was
returning null rather than an empty object. I feel like this is an
acceptable breaking change, but am certainly open to other opinions.

It seems intuitive for merge() to return an empty object when the inputs
are null (or omitted entirely) - returning an error would likely break
many terraform configurations, and returning an empty object rather than
null seems more consistent with the documented behavior (though it is
not explicit!).

I dug through the commit history and compared terraform's documentation,
post pre- and post-hcl2, and did not find any clues as to why it was
returning null rather than an empty object. I feel like this is an
acceptable breaking change, but am certainly open to other opinions.
@mildwonkey mildwonkey changed the title stdlib/merge: return an empty object when all inputs are null functions/stdlib/merge: return an empty object when all inputs are null Dec 11, 2020
@codecov
Copy link

codecov bot commented Dec 11, 2020

Codecov Report

Merging #82 (a7d3a90) into main (4a53886) will decrease coverage by 0.05%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##             main      #82      +/-   ##
==========================================
- Coverage   70.36%   70.31%   -0.06%     
==========================================
  Files          79       79              
  Lines        6550     6545       -5     
==========================================
- Hits         4609     4602       -7     
- Misses       1497     1498       +1     
- Partials      444      445       +1     
Impacted Files Coverage Δ
cty/function/stdlib/collection.go 21.49% <ø> (-0.68%) ⬇️
cty/convert/mismatch_msg.go 69.38% <0.00%> (-2.05%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4a53886...82a8b7a. Read the comment docs.

@apparentlymart
Copy link
Collaborator

If I were reviewing this as a new function today I would've asked for it to return an error if any of the inputs are null, because that's typically how cty functions behave, but I agree that this seems like a reasonable compromise given the behavior as it currently exists, and so this is a pragmatic way to get a less surprising result.

Thanks!

@apparentlymart apparentlymart merged commit 36dc714 into zclconf:main Dec 16, 2020
@apparentlymart
Copy link
Collaborator

Hmm... this change was showing as having passed tests before I merged it but now I try it locally I'm seeing a test failure:

--- FAIL: TestMerge (0.00s)
    --- FAIL: TestMerge/merge([]cty.Value{cty.MapValEmpty(cty.String)}) (0.00s)
        collection_test.go:561: wrong result
            got:  cty.MapValEmpty(cty.String)
            want: cty.EmptyObjectVal

Unfortunately I spotted this only after including the change in the v1.7.1 release, so the "got" behavior is now contractual to avoid making a breaking change, so I think we must address this by changing the "want" to be an empty map too.

@mildwonkey would you mind sending in a new PR for that? The v1.7.1 release is out already but I'd like to make it green again in preparation for the next release. If you don't have time then please let me know and I can look into it myself.

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