I’d like to re-open the question on use of count as a hack for an enabled metadata on resources, data and outputs. Basically this relates to my post Semantic enable/disable resource · Issue #27936 · hashicorp/terraform · GitHub.
I would like to understand why this is such a difficult thing to do. I understand that it is not trivial, since the syntax or language needs an extension to handle null references. But since null references will always be leaf nodes in the dependency graph, they do not seem like a major disruptor.
So eg let’s say that when enabled=false, the dependency graph generator does not need to follow it; and any resource that uses it does not need to have it as ancestor. Moreover, that null has all properties, themselves null; this allows you to write type.null_obj.attribute_with_null_value.other_attribute_with_null_value, the net value would be null. Or perhaps use something like in python: if null is like false, this would allow us to write some_int = null_ref.some_attrib or 123 indicating, if the LHS of the or is falsy, use the RHS of the or.
Would this not be sufficient to get clean semantics on enabled/disabled resource specs? And I don’t think this would break backwards compatibility.
Hi @schollii,
Along with the question of how exactly it would work there is also the question of whether it’s actually necessary to do so, given that Terraform already has a feature explicitly designed for deciding how many of something to create, and various other language features for using boolean conditions to decide between two numbers in order to make that decision dynamically.
Any new language feature has a significant cost just by existing at all, and so far this proposed feature seems to both have a pretty marginal impact and only seems to be viable when combined with other broad language changes, such as your proposal here of an entirely new operator or.
At this point I think this discussion has been open long enough without either a clear indication of objective value or a clear design that is orthogonal to other language features, and so I personally don’t expect this to ever move forward, but that’s just my perspective and we are of course open to new information that might either offer a path forward that works well with the rest of the language as currently defined or a demonstration that this new feature would allow achieving something that isn’t already achievable today, and that is why we still have the open issue #25406 as a place to gather that new information, should anyone discover it.