schema/decoder: Introduce AddressingMode into AttributeAddrSchema

[radeksimko]

Context

We currently have two boolean fields in both AttributeAddrSchema and BlockAddrSchema to indicate whether the attribute/block is meant to be collected as type-aware, and/or type-only.

In practice, when any *AddrSchema is declared, then at least one of these two is flipped to true. This may not be most obvious to end-users and also results in quite verbose logic whenever reference target collection is involved.

hcl-lang/schema/attribute_schema.go

Lines 70 to 80 in d2c7ba3

	// AsExprType defines whether the value of the attribute
	// is addressable as a matching literal type constraint included
	// in attribute Expr.
	//
	// cty.DynamicPseudoType (also known as "any type") will create
	// reference of the real type if value is present else cty.DynamicPseudoType.
	AsExprType bool
	// AsReference defines whether the attribute
	// is addressable as a type-less reference
	AsReference bool

hcl-lang/schema/block_schema.go

Lines 57 to 64 in d2c7ba3

	// AsReference defines whether the block itself
	// is addressable as a type-less reference
	AsReference bool
	// BodyAsData defines whether the data in the block body
	// is addressable as cty.Object or cty.List(cty.Object),
	// cty.Set(cty.Object) etc. depending on block type
	BodyAsData bool

hcl-lang/decoder/expression.go

Lines 50 to 60 in d2c7ba3

	// AsExprType defines whether the value of the attribute
	// is addressable as a matching literal type constraint included
	// in attribute Expr.
	//
	// cty.DynamicPseudoType (also known as "any type") will create
	// reference of the real type if value is present else cty.DynamicPseudoType.
	AsExprType bool
	// AsReference defines whether the attribute
	// is addressable as a type-less reference
	AsReference bool

Proposal

We could replace the two boolean fields with special type that expects three constants:

• TypeAware
• TypeUnaware
• Both

names TBD, but the main idea is that having a single field means that the common case in Terraform (of both) will be less verbose and the collection related logic can also be less verbose as a result of dealing with one field, instead of two.

It should aid readability on both ends of maintainers and end-users.