proposal: Go 2: integer array <-> integer type conversion

[jfcg]

Integer types are convertable to each other. I propose to extend it to arrays:

a := [2]uint16{1, 2}
b := int32(a)
c := [4]byte(a)

d := uint32(65537)
e := [2]int16(d)

This will allow to see:

• sub-bytes or sub-words of a larger integer variable
• bytes/words in an array as a larger integer

without unsafe.Pointer tricks.

What should the endianness of the converted value be?

[ianlancetaylor]

For language change proposals, please fill out the template at https://go.googlesource.com/proposal/+/refs/heads/master/go2-language-changes.md .

When you are done, please reply to the issue with @gopherbot please remove label WaitingForInfo.

Thanks!

[josharian]

This can be done now using encoding/binary. The compiler generates very good code for these routines, equivalent (I strongly suspect) to what a built-in conversion would do. It would be good to explain why encoding/binary is insufficient here.

[jfcg]

• I am experienced Go programmer.
• I have extensive experience with C, C++, Python.
• This change enhances type conversions and eliminates some uses of unsafe.Pointer (a more advanced feature) or shift & convert, so I believe this change slightly extends what novice programmers can do and it can improve Go learning experience.
• Afaik this feature was not proposed before.
• All Go users benefit from this with extended type conversions.
• This proposal introduces a) integer array <-> integer array b) integer array <-> integer type conversions.
• The language spec would extend with the proposed conversions.
• This change is backward compatible.
• I believe implementation cost is minimal.
• Compile time cost is similar to integer <-> integer conversion.
• There is no run time cost.
• Like a uint64(int64) conversion, this change is a unique feature and orthogonal with other features in Go.
• This change is not a performance improvement, just a convenient type conversion.

@gopherbot please remove label WaitingForInfo

[jfcg]

What should the endianness of the converted value be?

Whatever the target's endianness is at compile time. It should behave like an unsafe.Pointer conversion.

[josharian]

Whatever the target's endianness is at compile time.

This was discussed indirectly at #35398

[jfcg]

Ok, so because of endianness:

a := uint16(258)
b := [2]byte(a)

c := byte(a) // always 2
d := b[0]    // not well defined

right? We cant just think like unsafe.Pointer conversion.

How about we make it well-defined. We define the conversion such that b[0]=c=2 and b[1]=1 is always true and consistent across platforms. What do you think?

Josh, encoding/binary doesn't seem very convenient in terms of intuition & readability. It looks more suitable for run-time conversion, whereas this is a compile time feature. Though I am sure the compiler can be made to output efficient assembly for it.

[josharian]

It looks more suitable for run-time conversion, whereas this is a compile time feature.

I’m not sure I understand the distinction here. I believe that are functionally identical. Can you explain more?