Add support for indexing into variables #3
Conversation
|
cc @phinze, @mitchellh. |
jen20
force-pushed
the
f-index-operation
branch
from
f74742c to
350ebe6
Compare
| } | ||
|
|
||
| func (n *Index) Accept(v Visitor) Node { | ||
| //n.Key = n.Key.Accept(v) |
There was a problem hiding this comment.
Good catch - will fix - that was actually what was causing the panic :-)
jen20
force-pushed
the
f-index-operation
branch
from
350ebe6 to
0d1756f
Compare
| true, | ||
| nil, | ||
| ast.TypeInvalid, | ||
| }, |
There was a problem hiding this comment.
We should add a test here for tests sake that the index can be a reference to another variable ${foo[bar]}.
There was a problem hiding this comment.
👍 and also that it can be the result of a second indexing operation. I'll add these.
jen20
force-pushed
the
f-index-operation
branch
from
0d1756f to
865db3d
Compare
This adds support for indexing into variables of the new type "List".
The syntax is typical C-style array syntax, so for example, the
following is valid for interpolating the element of the list in variable
foo at position 1:
"${foo[1]}"
There is a restriction that lists must be homogenous in type. This is to
enable the type checker to work without having to actually perform the
indexing operation. During discussion there was no compelling use case
for lists of heterogenous types - this is open for discussion in future
though if one is found.
jen20
force-pushed
the
f-index-operation
branch
from
865db3d to
730ac9b
Compare
|
@mitchellh I went with your suggestion of listing the types which are present in the error - which was actually my original implementation hence the stray |
|
LGTM! Woohoo! |
Add support for indexing into variables
|
Is this feature would be present in next Terraform release? |
This adds support for indexing into variables of the new type "List". The syntax is typical C-style array syntax, so for example, the following is valid for interpolating the element of the list in variable
fooat position 1:There is a restriction that lists must be homogenous in type. This is to enable the type checker to work without having to actually perform the indexing operation. During discussion there was no compelling use case for lists of heterogenous types - this is open for discussion in future though if one is found.