The documentation indicates that the ValueFoo() methods in the basetypes package like Int64Value{}.ValueInt64() will return zero values when the object is marked as null or unknown.
But the methods don’t implement any check for unknown/null condition. They just return the underlying value which, I dunno, might have something else in there?
// ValueInt64 returns the known int64 value. If Int64 is null or unknown, returns
// 0.
func (i Int64Value) ValueInt64() int64 {
return i.value
}
Is it safe for provider developers to invoke these ValueFoo() methods without first checking IsNull() and IsUnknown()?
I’m confident that guard rails which ensure we never get into a has-value-but-marked-unknown condition could exist, but I’m less confident in my ability to evaluate them
I’m expecting to hear that it’s fine, but the comment above (function does vs. function assumes) has left me wallowing in doubt.
Is it safe for provider developers to invoke these ValueFoo() methods without first checking IsNull() and IsUnknown() ?
It is safe, in that the Value{TYPE}() methods will return the zero value for the type, for instance, false for BoolValue.ValueBool().
However, if the logic within the provider requires that a determination of whether BoolValue was explicitly set as false, for instance, in the supplied configuration, then checking BoolValue.IsNull() and BoolValue.IsUnknown() would be recommended.
I understand that phenomenon from the perspective of the Go type system, I was just looking for confidence that it would be impossible for me to create a situation where one of values from the basetypes package is null or unknown according to its state element, but has a leftover value in its value element.
I don’t have that problem. In this specific case, the API I’m talking to accepts strings like “option1”, “option2” and “” (which disables the feature). I have an attribute validator which forces the user to only supply “option1” or “option2” - the user is expected indicate the “disabled” condition by omitting this Optional: True attribute.
My intent is to use the output of feature.ValueString() directly without evaluating for null/unknown state.
The general design around the framework’s most recent type system is that values, once created, should be immutable. While technically something in the framework code could break that assumption, anything doing that would be considered a bug, and it should not be possible from provider code since those underlying type system details are not directly exposed. We could explicitly add the value state checking guardrails in the type system implementations, if there are issues with these choices.
