RFC 0009: Adding looping functionality in CFN Template (Fn::For) #8
Conversation
mingujo
changed the title
RFCs/0009-Fn::For.md
Outdated
| #### Use case: Replicate a single Resource | ||
|
|
||
| * In Json | ||
| ```aidl |
There was a problem hiding this comment.
Would you mind removing these aidl things?
There was a problem hiding this comment.
oh right. Thank you. Removed them
| - ["Index", "Value"], | ||
| - "CollectionToIterate", | ||
| - "TemplateSnippet" | ||
| - "LogicalId" |
There was a problem hiding this comment.
I think we had briefly touched on it in a discussion, but I don't quite remember why we wouldn't put the LogicalId before the TemplateSnippet. The snippet will be the largest value whereas the Logicalid is just a short string. I think readability would be better if the LogicalId comes before the snippet. Is it because it's optional? Do you think it would be too confusing to have an optional parameter in the second to last position?
There was a problem hiding this comment.
Yes, we briefly talked about placing LogicalId before TemplateSnippet. We discussed that it could be tricky for users since it's an optional parameter while parameters are positional, not named ones.
There was a problem hiding this comment.
I don't quite follow the argument, but I'm ok putting the RFC out like this. I'm curious to hear from customers, if they think this parameter should go in the third position or last. I don't see a technical reason why that wouldn't be possible and I think it would improve readability (although I acknowledge that having an optional parameter that's not in the last position is unusual.)
There was a problem hiding this comment.
Usually optional parameters are placed at the end so they can be truly optional, but I can see arguments from the other side as well. Let see what customers think about this.
| - ["Index", "Value"], | ||
| - "CollectionToIterate", | ||
| - "TemplateSnippet" | ||
| - "LogicalId" |
There was a problem hiding this comment.
Usually optional parameters are placed at the end so they can be truly optional, but I can see arguments from the other side as well. Let see what customers think about this.
Language Enhancement Request For Comment
This is a request for comments about a new Language Extensions intrinsic function
Fn::For. See TRACKING_ISSUE foradditional details.
Licensing
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.