You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As discovered in hashicorp/hcl-lang#326 there is increasingly more situations where the constraints and real types (as implied from values) mismatch, even if they're compatible.
For example, nested expressions in TemplateExpr - attr = "foo-${var.bar}" - where var.bar may be of type number but is constrained by the outer template expression to string.
Currently we choose to display the real type in that specific context, i.e. number:
similarly for ConditionalExpr, the condition part is constrained to bool but string is convertible to bool:
In general, one type will always communicate only "half of the story" and it is very likely there are other contexts where constraint may be more helpful than the real type.
Proposal
Display both the surrounding constraint and real type of an expression in hover data. We could display it at all times but it may be better to only do it when the two differ as that makes for more meaningful UX.
The text was updated successfully, but these errors were encountered:
Background
As discovered in hashicorp/hcl-lang#326 there is increasingly more situations where the constraints and real types (as implied from values) mismatch, even if they're compatible.
For example, nested expressions in
TemplateExpr
-attr = "foo-${var.bar}"
- wherevar.bar
may be of typenumber
but is constrained by the outer template expression tostring
.Currently we choose to display the real type in that specific context, i.e.
number
:similarly for
ConditionalExpr
, the condition part is constrained tobool
butstring
is convertible tobool
:In general, one type will always communicate only "half of the story" and it is very likely there are other contexts where constraint may be more helpful than the real type.
Proposal
Display both the surrounding constraint and real type of an expression in hover data. We could display it at all times but it may be better to only do it when the two differ as that makes for more meaningful UX.
The text was updated successfully, but these errors were encountered: