type = lower("string")
}
```
Specifying primitive types can be valuable to show intent (especially when a default is not provided),
but bake will generally behave as expected without explicit typing.

Complex types are expressed with "type constructors"; they are:
* `tuple([<type>,...])`
* `list(<type>)`
* `set(<type>)`
* `map(<type>)`
* `object({<attr>=<type>},...})`

The following are examples of each of those, as well as how the (optional) default value would be expressed:
```hcl
# structured way to express "1.2.3-alpha"
variable "MY_VERSION" {
  type = tuple([number, number, number, string])
  default = [1, 2, 3, "alpha"]
}

# JDK versions used in a matrix build
variable "JDK_VERSIONS" {
  type = list(number)
  default = [11, 17, 21]
}

# better way to express the previous example; this will also
# enforce set semantics and allow use of set-based functions
variable "JDK_VERSIONS" {
  type = set(number)
  default = [11, 17, 21]
}

# with the help of lookup(), translate a 'feature' to a tag
variable "FEATURE_TO_NAME" {
  type = map(string)
  default = {featureA = "slim", featureB = "tiny"}
}

# map a branch name to a registry location
variable "PUSH_DESTINATION" {
  type = object({branch = string, registry = string})
  default = {branch = "main", registry = "prod-registry.invalid.com"}
}

# make the previous example more useful with composition
variable "PUSH_DESTINATIONS" {
  type = list(object({branch = string, registry = string}))
  default = [
    {branch = "develop", registry = "test-registry.invalid.com"},
    {branch = "main", registry = "prod-registry.invalid.com"},
  ]
}
```
Note that in each example, the default value would be valid even if typing was not present.
If typing was omitted, the first three would all be considered `tuple`;
you would be restricted to functions that operate on `tuple` and, for example, not be able to add elements.
Similarly, the third and fourth would both be considered `object`, with the limits and semantics of that type.
In short, in the absence of a type, any value delimited with `[]` is a `tuple`
and value delimited with `{}` is an `object`.
Explicit typing for complex types not only opens up the ability to use functions applicable to that specialized type,
but is also a precondition for providing overrides.

> [!NOTE]
> See [HCL Type Expressions][typeexpr] page for more details.

### Overriding variables

As mentioned in the [intro to variables](#variable), primitive types (`string`, `number`, and `bool`)
can be overridden without typing and will generally behave as expected.
(When explicit typing is not provided, a variable is assumed to be primitive when the default value lacks `{}` or `[]` delimiters;
a variable with neither typing nor a default value is treated as `string`.)
Naturally, these same overrides can be used alongside explicit typing too;
they may help in edge cases where you want `VAR=true` to be a `string`, where without typing,
it may be a `string` or a `bool` depending on how/where it's used.
Overriding a variable with a complex type can only be done when the type is provided.
This is still done via environment variables, but the values can be provided via CSV or JSON.

#### CSV overrides

This is considered the canonical method and is well suited to interactive usage.
It is assumed that `list` and `set` will be the most common complex type,
as well as the most common complex type designed to be overridden.
Thus, there is full CSV support for `list` and `set`
(and `tuple`; despite being considered a structural type, it is more like a collection type in this regard).


There is limited support for `map` and `object` and no support for composite types;
for these advanced cases, an alternative mechanism [using JSON](#json-overrides) is available.

#### JSON overrides

Overrides can also be provided via JSON.
This is the only method available for providing some complex types and may be convenient if overrides are already JSON
(for example, if they come from a JSON API).