Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Int32 type #801

Open
pgier opened this issue Jul 13, 2023 · 4 comments
Open

Add Int32 type #801

pgier opened this issue Jul 13, 2023 · 4 comments
Labels
enhancement New feature or request types Issues and pull requests about our types abstraction and implementations.

Comments

@pgier
Copy link

pgier commented Jul 13, 2023

Module version

github.com/hashicorp/terraform-plugin-framework v1.3.2

Use-cases

Any time you want to use a default int in golang.

Attempted Solutions

Currently using the schema.Int64Attribute and related types. I have to do type conversions in various places.

Proposal

Add an Int type similar to Int64 which just returns a default golang int.

@pgier pgier added the enhancement New feature or request label Jul 13, 2023
@bflad
Copy link
Member

bflad commented Jul 13, 2023

Hi @pgier 👋 Thank you for raising this.

One thing that has come up occasionally before is specifically supporting a 32-bit integer type, but this is the first direct request for a Go-specific int type. One of the challenges with the Go int type is that it is defined by the CPU architecture running the code (or lower, such as running a 32-bit binary on 64-bit CPU), so supported integers may be 64-bit or 32-bit depending on where the provider was running. This can ultimately leading to practitioner confusion when there is an unexpected integer overflow when the API may happen to return integers larger than 32 bits.

Can you describe where/why you're running into these type conversions? Are you working with an API SDK that deals exclusively with the loosely-defined int/*int types? For example, would providing a way to create a types.Int64 value from a Go int help? That sort of operation is safe because a 64-bit or lower integer can always be represented by the larger sized type.

@bflad bflad added types Issues and pull requests about our types abstraction and implementations. waiting-response Issues or pull requests waiting for an external response labels Jul 13, 2023
@pgier
Copy link
Author

pgier commented Jul 13, 2023

I guess an int32 type would be fine. My specific cases that I've run into are:

  1. Writing code against an existing client library which uses in32 types.
  2. Using things like strconv.Atoi where it would be nice to just pass a plain int type

For (1), I'm now using ObjectValue.As to do the type conversions and that seems to be working fine.
For (2), I should probably just use strconv.FormatInt or something else that accepts an int64.

If there is already a request for an int32 type, I think you can close this as a duplicate.

@github-actions github-actions bot removed the waiting-response Issues or pull requests waiting for an external response label Jul 13, 2023
@bflad
Copy link
Member

bflad commented Jul 13, 2023

Writing code against an existing client library which uses in32 types.

Just to ensure we are on the same page, are those client library types the Go built-in int32 type or just int? When we have thought about introducing something like types.Int32/schema.Int32Attribute, it would explicitly be the int32 type to prevent any confusion about the value storage. Maybe it would be okay to have functionality on that those that also allowed int to and from though, since I'm doubtful that Go would support an architecture with less than 32 bits.

If there is already a request for an int32 type, I think you can close this as a duplicate.

I don't believe there is a public one in this issue tracker at the moment, so if you're okay with that we can re-title this.

@pgier
Copy link
Author

pgier commented Jul 14, 2023

Just to ensure we are on the same page, are those client library types the Go built-in int32 type or just int?

This particular library is using specifically int32 types.

if you're okay with that we can re-title this

Yes, that's fine with me

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request types Issues and pull requests about our types abstraction and implementations.
Projects
None yet
Development

No branches or pull requests

2 participants