Feature request: support for 'default' in output

[ProbablyRusty]

I am thinking it would be helpful to support default values for outputs in TF, in the same way they are supported for variables.

So, for example, something like this would be possible:

output "foo" {
  value   = "${bar.baz.id}"
  default = "none"
}

Like variables, the default value would only apply if the explicit value wasn't supplied. (In the example above, perhaps if count on bar.baz was 0 or something.)

One problem that this would alleviate is when using modules, in cases where the root might refer to outputs from the module, and then error in certain cases (such as in if-statements) if the output from the module isn't available.

Obviously, lazy evaluation of if-statements which appears to be on the roadmap (see #11210) would greatly mitigate the need for this, but even then, I still think there are cases in which default values for outputs could be useful.

Since the implementation would be consistent with that already in place for variables, I think it would be clear enough enhancement to make from a user standpoint.

[apparentlymart]

Hi @consultantRR! Thanks for this proposal.

This feels a little strange because currently there isn't really a case where an output is unset... it might be set to something that is "empty", or its expression might refer to something that doesn't exist. In the latter case, we would ideally have an error message for that case but currently this is hidden (as is captured in another issue that I wasn't able to find quickly).

As you mentioned, making the conditional operator work properly such that "invalid" things can be allowed on the path not taken is something we intend to fix eventually, at which point I think you'd write your example using something like the following:

output "foo" {
  value = "${bar.baz.count > 0 ? bar.baz.id : "none"}"
}

This could be expressed today using this rather-more-awkward construction:

output "foo" {
  value = "${element(concat(bar.baz.*.id, list("none")), 0)}"
}

We generally err on the side of being explicit and on the side of having only one way to express a given thing. While we are definitely willing to be pragmatic and add convenient alternatives for common cases, in this case a properly-working conditional operator would have the same expressiveness and not require any output-specific knowledge, so I'm leaning towards that as the more user-friendly solution.

So I'm going to close this, and assume that we will eventually get to #11210. Thanks for proposing this, though: it's always helpful to hear about real use-cases, and we do take them into consideration in future designs even if the ultimate design doesn't follow exactly what was proposed.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.