Commit Graph

6 Commits

Author SHA1 Message Date
Alisdair McDiarmid 7f97bd4489 functions: Fix missing defaults for objects/tuples
If no default is specified for a nested optional structural typed
attribute, the defaults function should just pass through its input.
Before this commit the function assumed that the fallback value was
always of the correct type, which would panic.
2021-03-12 18:14:14 -05:00
Alisdair McDiarmid 0bbe583eb8 functions: Fix defaults for null objects/tuples
When using defaults with a value which contains null objects or tuples,
we cannot continue to traverse the value and apply defaults. Instead,
when we find an attribute which is null, we return early and stop
processing this branch.
2021-03-12 08:23:41 -05:00
Alisdair McDiarmid 66f8d1c1c2 functions: Fix defaults mismatched types fallback
We allow primitive fallback values which have mismatched types, but only
if there is a conversion to the target type. Previously we would allow
unsafe conversions (e.g. string to bool), but later had no capacity to
return an error if the conversion failed due to the value of the
fallback being unable to convert to the target type.

This commit makes the more conservative requirement that default
fallback values must have a safe conversion.
2021-03-04 10:43:09 -05:00
Alisdair McDiarmid 178a9b32d7 functions: Fix defaults null collections panic
When applying default values to collection types, null collections in
the input should result in empty collections in the output.
2021-03-04 10:13:41 -05:00
James Bardin e08422511e lang/funcs: staticcheck 2020-12-02 13:59:19 -05:00
Martin Atkins cec4578005 lang/funcs: Experimental "defaults" function
This is a new part of the existing module_variable_optional_attrs
experiment, because it's intended to complement the ability to declare
an input variable whose type constraint is an object type with optional
attributes. Module authors can use this to replace null values (that were
either explicitly set or implied by attribute omission) with other
non-null values of the same type.

This function is a bit more type-fussy than our functions typically are
because it's intended for use primarily with input variables that have
fully-specified type constraints, and thus it uses that type information
to help inform how the defaults data structure should be interpreted.

Other uses of this function will probably be harder today because it takes
a lot of extra annotation to build a value of a specific type if it isn't
passing through a variable type constraint. Perhaps later language
features for more general type conversion will make this more applicable,
but for now the more general form of this problem is better solved other
ways.
2020-11-13 17:27:20 -08:00