Make the move_toward(a, b, delta) work with vectors

[TotoShampoin]

Describe the project you are working on

A platformer game. In context, I use move_toward for the walking velocity.

Describe the problem or limitation you are having in your project

Everytime I use move_toward with a vector, I write it as a.move_toward(b, delta). I then see that nothing happens, because I forgot that it's actually a = a.move_toward(b, delta).

(This is definitely a skill issue on my part, and I am well aware)

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Maybe keep the "og" way of doing it, maybe also add #5596 for consistency on that part...

But my proposal is to have move_toward(a, b, delta) accept vectors too.
I do belive that a = move_toward(a, b, delta) is more intuitive, and less prone to making the mistake I described.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

I don't know if move_toward is built into the binary or if it's a hidden gdscript function, but if it is the latter, a check could be added. If it is the former, then C++ overloading, I guess.

Either way, it would be as simple as

func move_toward(a: Vector2, b: Vector2, float delta) -> Vector2:
    # a.move_toward(b, delta) implementation

If this enhancement will not be used often, can it be worked around with a few lines of script?

I don't think so. Not without defining another function with another name

func my_move_toward(a, b, delta: float):
    if typeof(a) != typeof(b):
        push_error("Must be same type")
    if a is Vector2 or a is Vector3:
        return a.move_toward(b, delta)
    return move_toward(a, b, delta)

Is there a reason why this should be core and not an add-on in the asset library?

Because it's a change brought to a core function

[KoBeWi]

move_toward() method takes float argument, it can't work with vectors. Compare with lerp(), which takes Variant and returns Variant, but has an alternatives of lerpf(). Changing argument type is not possible now due to compatibility, the only option is adding move_towardv(), which uses vectors.

[Mickeon]

If anything I'd make it so that you can call functions directly from floats and ints, like some other languages out there.

It would also hammer the point that these are all Variant types and they can infact behave like this.

[TotoShampoin]

move_toward() method takes float argument, it can't work with vectors. Compare with lerp(), which takes Variant and returns Variant, but has an alternatives of lerpf(). Changing argument type is not possible now due to compatibility, the only option is adding move_towardv(), which uses vectors.

I guess that'd work, I guess... But why would replacing float with Variant on move_toward() break compatibility?

If anything I'd make it so that you can call functions directly from floats and ints, like some other languages out there.

It would also hammer the point that these are all Variant types and they can infact behave like this.

I mean, I guess that'd be in favor of consistency, but as I said, from.move_toward(to, delta) intuitively implies (to me at least) that from gets modified. Maybe because "move toward" is a verb.

[KoBeWi]

why would replacing float with Variant on move_toward() break compatibility?

Type inference would stop working, resulting in errors.