Comparison and Boolean Operations

[apparentlymart]

This set of commits introduces new operators to support comparison and boolean operations. The new operators are as follows:

• Equality: == and !=
• Numeric comparison: <, >, <= and >=
• Boolean operations: &&, || and unary !
• Ternary conditional: ... ? ... : ...

This is a logical (:grimacing:) extension of work started in #26.

I went with "C-style" operator punctuation because I think this has been the syntax most prolifically emulated by other programming languages and so users are likely to be familiar with it from at least one of C's descendants. Additionally, HCL (in which HIL is most commonly embedded) is using "C-inspired" brace-delimited blocks. (perhaps it's more accurate to attribute this syntax to B, but hey...)

My primary motivation for working on this is to make a further step towards the use-cases discussed in hashicorp/terraform#1604.

A pattern has emerged for "faking" conditional resources in Terraform using variables mapping to counts, as follows:

variable "env_decider" {
  production = 1
  staging    = 0
}

resource "example" "foo" {
  # ...
  count = "${var.env_decider[var.environment]}"
}

Including this changeset in Terraform would immediately "pave the cowpath" here and introduce a more succinct way to express that idea:

resource "example" "foo" {
  # ...
  count = "${var.environment == "production" ? 1 : 0}"
}

In the discussion on hashicorp/terraform#1604 there is also some consensus around a more "intentional" mechanism for conditionally including resources, which Terraform could support via some additional features building on the boolean operations added in these commits:

# will not work without further changes to Terraform, but would build on these changes
resource "example" "foo" {
  # ...
  if = "${var.environment == "production"}"
  # (other suggestions for this attribute name have been "when", "onlyif", ...
}

---

Due to the same type system limitations that befell full implementation of #34, for this initial changeset the ... ? ... : ... operator is constrained to not work on array or map types. In principle it could support direct usage of variables of these types in a similar way to how indexing is supported, but since this seems to be a rather marginal case I decided to omit this complexity right now until either the type system gets improved to represent collection element types or until we find a specific motivating use-case.

[mitchellh]

MARTIN!

I've been wanting to do this for months, using effectively this exact syntax. The implementation looks awesome, the tests look great, looks Terraform 0.8 is going to get a surprise.

[mitchellh]

I'll leave this for the future (not this PR), but I think we can do something clever here somehow to make it so we don't have to fully evaluate both sides (lazy evaluate).

[apparentlymart]

Ahh yes, that's true. I touched on that briefly and then moved on considering it to just be a marginal performance thing, but now that you mention it I suppose some specific things like Terraform's file(...) function could benefit from being short-circuited both here and in the && and || operators as a future improvement, so people can do stuff like:

something = "${var.data_file != "" ? file(var.data_file) : "default_something"}"

[mitchellh]

I think strings could make sense here, just copying behavior of Go spec's string comparison.

[VladRassokhin]

Great feature!
Do you have plan to include that to Terraform 0.8?
And if yes when would be next rc/release?