Expressions in Bicep parameters files #10248
Conversation
404980b
to
7902a79
Compare
42f9f64
to
74754a6
Compare
74754a6
to
e2ef0b9
Compare
src/Bicep.Core.Samples/Files/baselines_bicepparam/Invalid_Expressions/parameters.bicepparam
Outdated
Show resolved
Hide resolved
| // We may emit duplicate errors here - type checking will also execute some ARM functions and generate errors | ||
| // This is something we should improve before the first release. |
There was a problem hiding this comment.
One option here may be to use the type of the parameter assignment instead of re-evaluating. I'm not sure if it covers all cases, but if model.GetTypeInfo(parameter.DeclaringSyntax) returns a type for which TypeHelper.IsLiteralType returns true, it can be converted directly to a JToken.
There was a problem hiding this comment.
I started out with a similar approach - relying purely on type analysis to catch issues, but found that there were cases where the conversion wasn't being blocked (leading to a compilation failure). This definitely feels like a viable approach if we're able to guarantee we're always going to get either an error or a literal type.
The approach I'm taking here is definitely too heavy-handed - I'm mostly interested in trying to get some early feedback and use cases while the functionality is behind a feature flag, and plan to re-think it before an actual release.
There was a problem hiding this comment.
That's a good point. The type system doesn't consider it a failure if a type is non-literal, but that's the behavior we want in params files. The evaluator approach is likely to give you better error messaging than just raising a diagnostic if a parameters type is non-literal.
The type system also wouldn't be able to handle the params-for-params scenarios we've discussed.
This adds support for the "sys" namespace in Bicep parameters files - function expressions can be used to generate parameter file values.
Microsoft Reviewers: Open in CodeFlow