Naming: Rename imperative verb functions that do not modify an object

[psychicteeth]

Rect2.expand does not expand the Rect2 on which it is called, it returns a copy of the expanded rect. Vector2.normalized, by comparison, being in the perfect tense, does what you might expect it to - it returns a normalized version of the Vector2.
Functions that are named in the imperfect tense (i.e. infinitive without "to") are implicitly imperative and should operate on the object.
In the case of Rect2.expand, this should be deprecated and two new functions, expand_to(point: Vector2) and expanded_to(point: Vector2) should be created, with expand being deprecated to expanded_to. This should be applied to all such functions and become standard naming.

[AThousandShips]

This would break compatibility and couldn't be done in a minor version

[psychicteeth]

Why would it break compatibility? The old functions are still there, deprecated

[AThousandShips]

Having duplicate names just for minor grammar details is very confusing and clutters, we don't deprecate names just because they are different from some pattern

We allow changing the API, but we can't do this without creating confusing and cluttering duplicates, we deprecate methods and properties that are removed or replaced for more critical reasons

[psychicteeth]

I guess I just fundamentally disagree with this, but them's the breaks.

[dalexeev]

We could rename and deprecate the old method, but we have to weigh the pros and cons of that change. For example, we renamed String.is_valid_identifier() to is_valid_ascii_identifier() because we introduced is_valid_unicode_identifier() and the old name is now a bit ambiguous.

In the case of Rect2 methods, the proposed change is more of a stylistic one and it's not an isolated case, we would have to rename too many methods (expand(), grow*(), merge()) without much benefit. Much more important, in my opinion, is the fact that Variant types passed by value (everything except arrays, dictionaries and objects) are immutable, so all their methods are qualifiered const (at least the exposed API). You can keep that in mind regardless of the naming.

Of course, this is not good naming style, and we should consider renaming these methods in 5.0. As for 4.x, I'm not sure that fixing a stylistic error is worth it. We simply don't have counterexamples where the naming would be confusing, since value types don't have mutable methods.

[AThousandShips]

I've seen people be confused about the non-mutable nature of methods that are named in a more clear way (especially normalized) so I'd say that it's not something that's going to guarantee improvement

The main concern I have is that a lot of of the String methods would need to be renamed in this case if we want a strictly uniform case, as there's plenty of methods there that don't follow this pattern (c_(un)escape, capitalize, dedent, indent, erase, json_escape, etc., etc.)

[psychicteeth]

Great points. Cheers folks