3dfebdfc45
Previously our behavior for an unknown for_each was to produce a single block whose content was the result of evaluating content with the iterator set to cty.DynamicVal. That produced a reasonable idea of the content, but the number of blocks in the result was still not accurate, and that can present a problem for applications that use unknown values to predict the overall shape of a not-yet-complete structure. We can't return an unknown block via the HCL API, but to make that situation easier to recognize by callers we'll now go a little further and force _all_ of the leaf attributes in such a block to be unknown values, even if they are constants in the configuration. This allows a calling application that is making predictions to use a single object whose leaves are all unknown as a heuristic to recognize what is effectively an unknown set of blocks. This is still not a perfect heuristic, but is the best we can do here within the HCL API assumptions. A fundamental assumption of the HCL API is that it's possible to walk the block structure without evaluating any expressions and the dynamic block extension is intentionally subverting that assumption, so some oddities are to be expected. Calling applications that need a fully reliable sense of the final structure should not use the dynamic block extension. |
||
|---|---|---|
| .. | ||
| dynblock | ||
| include | ||
| transform | ||
| typeexpr | ||
| userfunc | ||
| README.md | ||
HCL Extensions
This directory contains some packages implementing some extensions to HCL
that add features by building on the core API in the main hcl package.
These serve as optional language extensions for use-cases that are limited only to specific callers. Generally these make the language more expressive at the expense of increased dynamic behavior that may be undesirable for applications that need to impose more rigid structure on configuration.