Simplify Extending Primitive Types

[bflad]

Module version

v0.2.0

Use-cases

Provider developers may wish to implement higher level types based off the primitive types in the current types package. For example, this may be a string-based attribute type that implements common validation checks on top.

Attempted Solutions

Currently, this seems more difficult than it should be since these higher level types cannot extend BoolType, NumberType, and StringType. A current possible workaround can be seen in the internal/testing/types package, which reimplements those types as structures.

Trying with type aliasing fails:

type BoolTypeWithValidateError types.BoolType

types.BoolType (constant 2 of type types.primitive) is not a type (NotAType)

Creating a struct type (with pointer or concrete) fails:

type BoolTypeWithValidateError struct {
	types.BoolType
}

types.BoolType (constant 2 of type types.primitive) is not a type (NotAType)

Trying as a variable also sensibly fails:

var BoolTypeWithValidateError = types.BoolType

func (t BoolTypeWithValidateError) Validate(ctx context.Context, in tftypes.Value) []*tfprotov6.Diagnostic {
	return []*tfprotov6.Diagnostic{TestErrorDiagnostic}
}

BoolTypeWithValidateError (variable of type types.primitive) is not a type (NotAType)

Other current types, such as ListType, MapType, and ObjectType are not affected as they are already structure types.

Proposal

This functionality should be designed with a holistic view on custom types, as such it has been marked with the design-doc label to signify that extra documentation should be provided on decision making.

One possible path forward would be to switch BoolType, NumberType, and StringType to structure types, similar to what is done in the current internal/testing/types package.

References

• Introduce attr.TypeWithValidate handling to internal/reflect and tfsdk #82

[paddycarver]

Agree with the thrust of this, just dropping in the additional context that they started out as struct types, and we moved to the current implementation to avoid people needing to type {} after them everywhere.

[tmccombs]

and we moved to the current implementation to avoid people needing to type {} after them everywhere.

Maybe have a Const that is defined as StringType{}?

[paddycarver]

I'm no longer working on this, but if memory serves the underlying problem here is that primitives are of an unexported primitive type and share an implementation, with each primitive getting its own constant.

In theory, primitives could be changed to their own types instead of being the unexported primitive type, but that would require them to be instantiated (including {} if they're a struct type, including ("") if they're a string type, including (0) if they're an integer type, etc.)

Primitives could be changed to their own types instead of being the unexported primitive type and a constant for each could be created, but what would the type/constant be named? Either the constant is named unintuitively for "normal" use or the type is named unintuitively for use as a base type implementation.

The unexported primitive type could be exported, but that exposes a lot more surface area that wasn't intended to be exposed, and I'm not sure that design makes sense.

I think my pitch would be to have a github.com/hashicorp/terraform-plugin-framework/types/base package or something that implemented types that were built to be extended, and maybe even refactor github.com/hashicorp/terraform-plugin-framework/types to extend those base types. Then "normal" usage would still be types.StringType but you could extend from base.StringType if you wanted a special kind of string.

[bflad]

Similar to the above comment, a types/basetypes package has been created which contains the extendable Go types for implementing custom types. Aliasing has been setup so existing types usage in providers should not require changes.

Maybe for the next major version, we can consider cleaning this up slightly, but this should make life easier for now.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.