Support Passing and Evaluating Deferred Expressions (Functions) via Variables at Point of Use

[emoshaya]

Terraform Version

Terraform v1.14.3

Use Cases

Terraform variables are values, not expressions. If a user passes a string that looks like an expression (e.g., ${upper("test")}), Terraform treats it as a literal string (or it is rejected depending on context). There is currently no supported mechanism to:

1. Pass an expression via a variable (including Terraform functions), and
2. Have Terraform evaluate that expression when the variable is used as an argument to a resource or module.

This prevents certain “configuration-driven indirection” patterns, such as:

• Passing a naming rule or formatting rule as configuration
• Having a module accept a “value expression” to compute a final name/path/ID
• Avoiding repeated boilerplate expressions across multiple call sites/resources
• Driving transformations from environment configuration without duplicating expression logic

variable "function_name_rule" {
  type = string
}

# Caller wants:
# function_name_rule = "$${upper(var.base_name)}"

resource "aws_lambda_function" "example" {
  function_name = var.function_name_rule   # would be ideal if evaluated here
}

Attempted Solutions

Using interpolation-like syntax inside a string, such as:

function_name_rule = "$${upper("test")}"

Terraform currently treats this as a literal string; there is no supported evaluation step to interpret it as an expression.

• Workarounds like locals or duplicating the expression at each use site defeat the goal of configuration-driven reuse.

Proposal

Introduce an opt-in, explicit way to represent deferred expressions as a distinct type/value that can be passed through variables and evaluated at the point of use in resource/module arguments.

Option A: New Expression Value Constructor + Explicit Evaluation

Call site:

variable "name_expr" {
  type = expr(string) # or a dedicated expression type
}

module "x" {
  source    = "./x"
  name_expr = expr(upper("test"))
}

Inside module or resource usage:

resource "aws_lambda_function" "example" {
  function_name = eval(var.name_expr)
}

Properties:

• expr(...) produces an expression value (not a string)
• eval(...) explicitly evaluates it in the current scope at the point of use
• Terraform can validate types (expr(string)), and prevent arbitrary evaluation where not permitted
• Keeps evaluation explicit (no “magic string interpolation”)

Option B: String-Based Deferred Interpolation

Allow a string convention like $${ ... } anywhere variables are used, and evaluate it at use sites. Example:

function_name = "$${upper("test")}"

This is more ergonomic, but is also more ambiguous, harder to statically analyze, and risks confusing “data” vs “code”.

Why This Is Useful

• Enables reusable “rules” for naming/formatting without repeating expressions
• Allows modules to accept transformation logic from callers in a controlled way
• Improves ergonomics for environments with strong naming conventions
• Keeps dependency graph correctness if expression evaluation still flows through Terraform’s standard expression model

References

No response

[jbardin]

Hi @emoshaya,

Is this intended to be a revision of your previous submission? This reads to me like a slightly more refined attempt at what was being expressed in #38109. If that is a distinct feature request we can sort it out in the other issue, otherwise I can close it out.

If I understand correctly, I think what you are getting at is that you want to be able to pass expressions as values themselves. That's not possible in the language without essentially creating a new language, but your examples look very similar to what was attempted in #28700.

That is something we may be able to revive research into, provided we can come up with sufficient use cases to warrant the feature. There were also concerns about overall usability, since it lends itself to templated "string programming", where logic is hidden away in opaque strings being passed around configuration.

Thanks!

[crw]

And, to add the standard instructions: thanks for this feature request! If you are viewing this issue and would like to indicate your interest, please use the 👍 reaction on the issue description to upvote this issue. We also welcome additional use case descriptions. Thanks again!

[jbardin]

Linking to #27696, which may over lap if the concept of a declarative function is something like partial application of expressions.

[apparentlymart]

FWIW I also had a variant of #28700 that was more like this proposal in that it worked with arbitrary expressions rather than only with template expressions.

This proposal differs from what I had attempted there in that the proposed eval function doesn't take a set of "template arguments" to evaluate the expression with, and so there's no ability to combine values from the expressions's scope and values from the caller's scope into the expression result. Extending with that capability would effectively turn this into general-purpose lexical closures, albeit with very strange syntax.

If I recall correctly, we'd closed #28700 because everyone who seemed interested in it had originally requested what became the templatestring function, and so at the time it seemed like there wasn't much demand for the more complicated form that supported templates as a new type of value, rather than just as strings containing HCL's template syntax.

If I were still working on Terraform today then I'd ask for examples of specific, real-world problems that can't be solved by templatestring but could be solved by something like this. The more complex idea didn't go anywhere mainly because we didn't know of any real use-cases that needed that extra complexity for us to evaluate whether the design was suitable beyond my contrived examples, and templatestring ended up being sufficient for all of the use-cases we knew about at the time and was considerably easier to implement. Of course, since I'm not still working on Terraform I can't say whether such examples would actually be helpful now or not... I'm just sharing this historical context in case it's useful to the current maintainers. 😀