Skip to content

Type Constraints for Output Blocks#36411

Merged
dbanck merged 7 commits intomainfrom
f-output-type
Mar 17, 2026
Merged

Type Constraints for Output Blocks#36411
dbanck merged 7 commits intomainfrom
f-output-type

Conversation

@dbanck
Copy link
Copy Markdown
Member

@dbanck dbanck commented Feb 3, 2025

This PR introduces support for declaring explicit type constraints in output blocks. It picks up the work that Martin did some time ago in #31728.

We could also introduce this as an experiment, available only in alpha releases, if we want to learn if a new argument inside the output block is the most ideal design for it.

UX

output "string" {
  type  = string
  value = var.some_string
}

Constraint mismatches are raised as an error

CleanShot 2025-02-03 at 17 52 56@2x

Fixes #

Target Release

1.15.x

CHANGELOG entry

  • This change is user-facing and I added a changelog entry.
  • This change is not user-facing.

@dbanck dbanck changed the title F output type Type Constraints for Output Blocks Feb 3, 2025
@hashicorp hashicorp deleted a comment from github-actions bot Feb 5, 2025
@dbanck dbanck marked this pull request as ready for review February 19, 2025 15:22
@dbanck dbanck requested a review from a team as a code owner February 19, 2025 15:22
dsa0x
dsa0x previously requested changes Feb 20, 2025
Copy link
Copy Markdown
Member

@dsa0x dsa0x left a comment

Choose a reason for hiding this comment

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

Did not mean to approve 😅

@dsa0x dsa0x requested review from a team and dsa0x February 20, 2025 09:29
@dbanck dbanck force-pushed the f-output-type branch 3 times, most recently from 11edf7b to 5df379b Compare March 6, 2026 17:05
dbanck and others added 7 commits March 16, 2026 10:48
Allow for more precise types to be used when evaluating unknown output
values. If we know all the types of outputs, and there are no dynamic
types involved, we can use lists and maps for the modules, which allows
module values to better match between validation and plan/apply.

We also fix an old problem of modules evaluating to lists and maps
during validation but not plan/apply, and causing expressions to
evaluate differently in different phases. We use the existence of a type
declaration to opt-in to this very subtly different behavior. It's not
expected that any config would notice the difference since we are only
removing possible type mismatches.
@dsa0x dsa0x dismissed their stale review March 16, 2026 14:08

Dismissing outdated review

@dbanck dbanck merged commit 2767639 into main Mar 17, 2026
11 checks passed
@dbanck dbanck deleted the f-output-type branch March 17, 2026 10:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants