Description
Context
As part of #232 in order to avoid duplicate completion we decided to introduce two "toggle" fields, such that we can nest and reuse LiteralType
and AnyExpression
constraints without those negative side effects.
hcl-lang/schema/constraint_any_expression.go
Lines 21 to 23 in 9c3a246
hcl-lang/schema/constraint_literal_type.go
Lines 29 to 31 in 9c3a246
We implemented this as the easiest way of addressing the problem as we were nearing the planned release date.
However, this introduced new API surface which should ideally in practice remain an implementation detail. i.e. a schema author shouldn't have to be concerned about this detail and should have some easier way of expressing e.g. "list or any expression evaluating to list" and similar constraints.
i.e. this does not make for the most readable code
Constraint: schema.OneOf{
schema.AnyExpression{OfType: cty.Map(cty.String), SkipLiteralComplexTypes: true},
schema.Map{
Elem: schema.AnyExpression{OfType: cty.String},
},
},
Notes
One additional complexity to consider is that there's certain metadata in complex types which we should be surfacing somewhere, esp. in completion and hover and this metadata often applies not just to the literal expression but to any expression which - when evaluated - complies with the constraint.
For example:
List
/Set
-Description
,MinItems
,MaxItems
Tuple
-Description
Map
-Description
,Name
,MinItems
,MaxItems
Object
-Description
,Name
This suggests that we could re-implement this such that e.g. schema.Map
complies with any interpretation of a map (including references or function calls), and leave AnyExpression
only for situations where the extra metadata isn't needed.
Proposal
- Explore other ways the same constraint could be expressed in the schema
- Look at other products (other than Terraform) to understand their needs in this area