[Core] Minor: it would be nice to make fontId pointer sized

[mikejsavage]

Very minor, but with certain renderer designs the implementation would be a tiny bit simpler if Clay_TextElementConfig::textId could fit a pointer instead of just a u16

[nicbarker]

@ColleagueRiley raised a similar point and I think you're right - the ergonomics are likely worth the increase in struct size here 🙂

[ColleagueRiley]

@nicbarker
Either using void* or size_t would be a potential solution.
Another solution could be:

#ifndef CLAY_FONT_ID
#define CLAY_FONT_ID u16
#endif

This would allow users to use whatever type they like for their "font id", the same could be done for textures. If you choose that route.

worth the increase in struct size here

I agree, I don't think anyone will complain about an extra 48 bits.

[FintasticMan]

intptr_t would also be good.

[ColleagueRiley]

@FintasticMan Yes, I think that's about the same as size_t except that it's explicitly intended for pointers. So it would probably be better to use intptr_t.

[sammonius]

On a related note, I think the same could also go for the index in CLAY_IDI(). That way, structs could be used to store certain properties of an element, and a poiner to the struct could be the ID. (I had a similar issue to that and I was trying to get the first half of the pointer using casts and bitwise operations but i ended up giving up after like half an hour.)

intptr_t would be nice but I think that's part of the standard library, isn't it?

[FintasticMan]

It's part of the standard library, but not the part that you have to link against, so it's fair game for Clay. Clay can use things that are available in freestanding C implementations, just not things that are only available in hosted implementations.