feat(attribute): add int32 support

[cpeliciari]

• Extend Value with Int32Value and Int32SliceValue.
• Extend KeyValue with Int32 and Int32Slice.
• Extend the Key type with Int32 and Int32Slice methods.

[linux-foundation-easycla]

• ✅login: cpeliciari / (c0a9fe9)

The committers listed above are authorized under a signed CLA.

[dmathieu]

https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#attribute

A primitive type: string, boolean, double precision floating point (IEEE 754-1985) or signed 64 bit integer.

Int32 is not spec compliant.
You should convert your int32 to an int64 within your codebase.

[cpeliciari]

https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#attribute

A primitive type: string, boolean, double precision floating point (IEEE 754-1985) or signed 64 bit integer.

Int32 is not spec compliant. You should convert your int32 to an int64 within your codebase.

What I created is a way to convert int32 values to int64. If you look at the commit, you’ll see that I’m not implementing int32 within the attribute, but rather performing a conversion.

I noticed that there is one for Int, but not for Int32.

opentelemetry-go/attribute/key.go

Lines 32 to 41 in c0a9fe9

	// Int creates a KeyValue instance with an INT64 Value.
	//
	// If creating both a key and value at the same time, use the provided
	// convenience function instead -- Int(name, value).
	func (k Key) Int(v int) KeyValue {
	return KeyValue{
	Key: k,
	Value: IntValue(v),
	}
	}

[pellared]

int32 within the attribute, but rather performing a conversion.

I think that adding this would be violating the Principle of Least Astonishment.

Moreover conversion (for slices) is coming with an overhead. I think it is in Go philosophy that things that needs to be converted or have additional cost are required to be done explicitly. "Write boring Go code".

If the specification would extend the to support int32 then we would need to make a behavioral change of Int32 variants that are introduced in this PR.

[pellared]

Closing per #6299 (review)

@open-telemetry/go-maintainers, feel free to reopen or discuss at the SIG meeting if you disagree with my decision.

@cpeliciari, I still want to thank you for your contribution. I deeply appreciate your efforts and time spend on this PR. I simply think that adding this can bring confusion to other users of the API. Notice that the changes you are proposing can also done as (local) helper functions.