Make Vector.bsearch and bsearch_custom const

[monxa]

Description

This pull request updates Vector's bsearch and bsearch_custom methods to be marked as const by using ptr() instead of the write pointer ptrw(). This adjustment ensures that these methods don't modify the Vector instance, aligning the behavior with Array.bsearch, which is already const.

This change is particularly relevant when using GDExtensions, as it enables the use of const references for PackedXXXArrays casted from Variants when using bsearch.

Backward compatibility

The transition to const methods is straightforward in theory, as non-const methods can call const methods without issue. However, this modification alters the "is_const" property in the API dictionary generation and affects method hashes due to their dependency on method constness.
Even though this is not an issue for me, it does affect backward compatibility for some GDExtension modules. At least those modules that use bsearch need to be recompiled with the newly dumped api currently.
So, this might be a major issue.

I believe backward compatibility issues have been addressed before in scenarios like this, but I'm not entirely sure how. If you have any insights or previous experiences on providing backward compatibility, I'd be glad to collaborate.

Documentation

Const qualifiers get added to PackedXXXArray.xml like so:
<method name="bsearch" qualifiers="const">

My knowledge regarding documentation is limited. So, if there is more to do, I am happy about any input.

[monxa]

I see. I will investigate why godot --doctool does not produce the const qualifiers for PackedByteArray, PackedColorArray and PackedFloat32Array specifically.

[AThousandShips]

It does, you didn't update them yourself, the automated check generates them correctly, you must have forgotten to git add them

[monxa]

It does, you didn't update them yourself, the automated check generates them correctly, you must have forgotten to git add them

You are awesome! I had no idea about documentation before. Ran --doctool, added everything as suggested.

[AThousandShips]

As you can see the compatibility is broken and we can't (currently) bind compatibility methods for these methods, see:

• Make Vector<T>::duplicate() const #79140 (comment)

Just like that one this can't be merged before such a system is implemented

[monxa]

As you can see the compatibility is broken and we can't (currently) bind compatibility methods for these methods, see:

* [Make Vector<T>::duplicate() const #79140 (comment)](https://github.com/godotengine/godot/pull/79140#discussion_r1417289615)

Just like that one this can't be merged before such a system is implemented

You got it! I was thinking, providing compatibility binding for Variants/core builtins would be a huge improvement. I already decided to dedicate myself to that. But as a preamble: My solutions will not be the prettiest. There is a lot to consider and I will need careful reviews for the iterations to come.

[AThousandShips]

You'll have to wait until that's implemented, there's no way to do this right now, it should be in a separate PR, and to add this would require a lot of knowledge on the lower level stuff, I'd not suggest it for a new contributor

[monxa]

You'll have to wait until that's implemented, there's no way to do this right now, it should be in a separate PR, and to add this would require a lot of knowledge on the lower level stuff, I'd not suggest it for a new contributor

I agree. After all, variants are bound directly in variant_call.cpp through Variant::register_types. Methods are then bound using the bind_method precompiler variants. This is as core as it gets and your suggestion is more than well founded. If you hadn't advised that, I would have set the expectations myself.

And I don't want to spam this project with unnecessarily bad requests with insufficient solutions for such an important problem. But still, am I allowed to try?
One approach would be: I would work my way back from ClassDB::add_compatibility_class, try to imitate the behavior to implement a variant.compat.inc.

[AThousandShips]

You're very welcome to try, but this is a very complex part of the engine, you'd want the functionality of bind_compatibility_method, not class though, but there's no methodology for this as these types aren't registered via ClassDB, so there would need to be an entirely new system, which would be a lot of work

The complexity of this and that it requires a whole new system is the reason it hasn't been done yet, even by the team who implemented the original feature

[AThousandShips]

I would say that the best solution here is a new system for all compatibility methods, or rather a new backing for it, which the ClassDB uses along with Variant, including the stuff under @GlobalScope so that we can have it all in one central system, so ClassDB would just engage with that system to carry it out, that'd IMO be the most robust and proper solution, but that'd be very involved and would have to be done carefully not to break things

[monxa]

I would say that the best solution here is a new system for all compatibility methods, or rather a new backing for it, which the ClassDB uses along with Variant, including the stuff under @GlobalScope so that we can have it all in one central system, so ClassDB would just engage with that system to carry it out, that'd IMO be the most robust and proper solution, but that'd be very involved and would have to be done carefully not to break things

I will try to draft something according to your suggestion. I will mention it here.

I can't promise anything because of the complexity, so I'd suggest giving me some time and see, if I can come up with something. If I manage, I'd be very happy about any further suggestions.