[mdaniel]

I think you missed the error message; I wasn't whining about for_each syntax masquerading as if it was a property of the resource, I was pointing out the moronic behavior of attempting to iterate over a list of strings and being given the finger

It is claiming the provided thing is not a set of strings it's a tuple

The fix is

    for_each = toset(var.my_list)

but who in their right mind would say "oh, I see you have a list of things, but I only accept unordered things"

[Spivak]

It's not about them being ordered it's about them being unique. You're generating a resource for each element and that resource has a unique name. The stackoverflow way to iterate over a list is to use toset() but more often what people want is

    zipmap(range(length(var.my_list)), var.my_list)

where you get {0 => item, 1=>item} and your resources will be named .0, .1, .2. I get the annoyance about the type naming but in HCL lists and tuples are the same thing.

[mdaniel]

> It's not about them being ordered it's about them being unique

Ok, so which one of ["a", "b"] in my example isn't unique?

And I definitely, unquestionably, never want resources named foo.0 and foo.1 when the input was foo.alpha and foo.beta

[Spivak]

I'm confused by your question, lists don't enforce uniqueness—you can do ["a", "a"] and it's perfectly valid. Sets and the key values of hash maps can't have repeating elements. You can for_each over lists that come from a data block so you can't statically know if a list is effectively a set.

If you don't want .0, .1 then you agree with Terraform's design because that's the only way you could for_each over an arbitrary list that might contain duplicate values. Terraform making you turn your lists into sets gets you what you want.