`ImageFormatLoaderExtension::_load_image`'s image parameter is const

[Spartan322]

Godot version

4.6.stable

godot-cpp version

10.0.0-rc1

System information

Godot v4.6.stable - Arch Linux #1 ZEN SMP PREEMPT_DYNAMIC Sun, 18 Jan 2026 00:33:55 +0000 on X11 - X11 display driver, Multi-window, 1 monitor - Vulkan (Forward+) - dedicated AMD Radeon RX 6600 XT (RADV NAVI23) - AMD Ryzen 5 2600 Six-Core Processor (12 threads) - 31.26 GiB memory

Issue description

ImageFormatLoaderExtension::_load_image's image parameter is const meaning in order to actually assign anything to the image parameter you need to const_cast away the image parameter's const. This appears to be a major oversight with the class for GDExtensions that has no effect in GDScript, I presume this is a consequence of how Godot handles binding the GDVIRTUAL macro declarations.

This makes this class unintuitive and as a C++ developer having a const_cast casting away const is precarious as its undefined behavior and stands against most if not all common guidelines and standards regarding C++.

Steps to reproduce

N/A

Minimal reproduction project

N/A

[dsnopek]

Thanks!

I think the const in const Ref<Image> &p_image means that you can't change which Image * the Ref<T> points to, not that you can't modify the underlying Image * object.

So, I think you should still be able to do p_image->set_data(...) which is what Godot's built-in image loaders do.

Is that not working for you? Or, am I misunderstanding how this API works?

[Spartan322]

ImageLoader classes in Godot don't use a const Ref<Image>& as their return parameter, they use a Ref<Image>, that in itself threw me off when inspecting how to implement my own. (in my mind incidentally reinforcing the next point)

But that aside I seem to have ran into a case of my intellisense (clangd) straight up lying to me, before it was treating non-const function calls on the image to be an error (specifically reporting about the const vs. non-const issue) and now its not doing that. I presume it was some really stupid compilation problem on my end, that issue has gone away.

Thing I could say is you can't reassign the Image's pointer (which is trivial to workaround) through a GDExtensions whereas it appears you can do so in Godot's inbuilt ImageLoaders. I don't know if that's considered a problem or not, given available functions I'm not really sure what point reassigning the pointer would even have.

Given all that if you want me to I can close it since technically the issue seemed to be local, at best this would only be pointing out a codestyle misnomer between GDExtensions and modules.

[dsnopek]

Ah, great, I'm glad it's working!

So long as p_image->set_data(...) works, I think this API works as intended and we can close this issue. If it's really necessary to reassign the Image * that's pointed to by the Ref<T> (in this API or another), then we can come back to it in a new issue.