(suggestion) Convert sdl.Rect Fields from int32 to int

[Priff13]

Would you mind converting the sdl.Rect field types from int32 to int?
This would help code readability when defining new rectangles.

[veeableful]

Hi @Priff13, it was done to keep compatibility with SDL2’s native C integers. Would you happen to have a suggestion on how to make the fields int and keep them compatible?

[Priff13]

Hi @Priff13, it was done to keep compatibility with SDL2’s native C integers. Would you happen to have a suggestion on how to make the fields int and keep them compatible?

@veeableful, the way that I would go about it is like this:
I would convert the struct types to int, but keep the old struct, like this:

type Rect struct {
	X, Y, W, H int
}

type rect_internal struct {
	X, Y, W, H int32
}

I see that the function func (a *Rect) cptr() *C.SDL_Rect is the primary function that is used when interacting with C, so I would adjust it to work like this:

func (a *Rect) cptr() *C.SDL_Rect {
	b := &rect_internal{ X: int32(*a.X), Y: int32(*a.Y), W: int32(*a.W), H: int32(*a.H) }
	return (*C.SDL_Rect)(unsafe.Pointer(b))
}

In the rest of the cases where sdl.Rect is used, all that would need to be done is convert the fields to or from int32.

It's not an insignificant amount of changes, but I believe that it would be overall beneficial for the developer experience.

PS: Applying the same changes to sdl.Point would be greatly appreciated.

[veeableful]

Thanks @Priff13. I think I will have to postpone it due to the amount of effort that it would require for me to maintain by myself but if you would like to create a pull request, it would be greatly appreciated!

[jabolopes]

Hi,

According to W3schools, on 64-bit architectures, golang's int is 64 bits wide, whereas, int32 is always 32 bits.

If the Golang SDL API accepts int (in sdl.Rect, sdl.Point, and others), what will the API do when it receives a value for an int that is too large for the int32 type required by the underlying SDL implementation?

Coercing the value from int to int32 will change the actual value and this is going to create subtle bugs that will be hard to debug.

Having int32 at the API level makes callers of this SDL wrapper library clearly aware of the size constraints of the underlying SDL library implemented in C, and it forces game devs to think rigorously about the types and values in their game. It prevents bugs.

Using int32 will also consume less memory on 64 bit architectures.

IMHO I feel like the benefits of compatibility (keeping int32 instead of int) outweigh the benefits of readability.

Best regards,
Jose