Add reset to CowData, to bring it on-par with other collections.

[Ivorforce]

In most APIs, clear() destroys all elements but keeps the capacity intact. This is the case for STL collections, as well as LocalVector. LocalVector additionally declares reset to give up the backing buffer.

CowData and related classes have no way to shrink without giving up the buffer (godotengine/godot-proposals#2954). As such, clear() behavior cannot be changed to be on-par with LocalVector. But we can certainly bring the APIs closer together by adding reset() and letting users use that instead of clear() if an explicit dealloc of the buffer is wanted (which is probably most cases).

[AThousandShips]

Not sure about this one, it's identical to clear and is only present in three other types, LocalVector, AHashMap and HashMap, and only the first is really relevant for that, so I don't think there's much syncing up with other containers here

I don't see the usefulness of this, which should be the guiding principle behind new features

[Ivorforce]

Not sure about this one, it's identical to clear and is only present in two other types, LocalVector and HashMap, and only the former is really relevant for that, so I don't think there's much syncing up with other containers here

I don't see the usefulness of this, which should be the guiding principle behind new features

For me this is about API consistency, which is key to reducing complexity in large codebases. imo, it was incorrect to call the function clear in the first place. Ideally, this would be amended in the future.

[AThousandShips]

But this doesn't add consistency, it adds something that's present in three out of 15 or more classes to three more, that's reducing consistency

If it did something unique I'd say it would make sense, but now it just creates an alias for clear which is just confusing

[Ivorforce]

But this doesn't add consistency, it adds something that's present in three out of 15 or more classes to three more, that's reducing consistency

If it did something unique I'd say it would make sense, but now it just creates an alias for clear which is just confusing

😄 you got a point there!
I did expect more containers to offer reset so I'm somewhat surprised this is not the case.

The reason I chose reset for this function is that, whenever collections have both, clear means "destruct objects but not buffer", but reset means "also destruct buffer". This is also consistent with STL's concept of clear.
In that sense, I'd view renaming clear to reset in all other cases as the best choice. But that's very large task, and the similar discussion about ptr() isn't even through yet (#100555), so I wanted to see if people generally agree we should attempt to work towards consistency in this way.

[AThousandShips]

I'd say consistency in this case means "a class has the function if it actually needs it", not "slap the function on anything".

Also this method should either be bound on String or not added to String, otherwise it adds an annoying additional thing to keep an eye out for when dealing with extensions and modules etc. because String is a bound class (it would have to be added to godot-cpp as well) and should also be added to Packed*Array binds for the same reason

The exact same concept applies to ptr/ptrw IMO

[Ivorforce]

Also this method should either be bound on String or not added to String

Yeah, that's probably true! Valid reason to stall merging this PR until clear can actually be implemented differently (and even then we'll have future API compatibility concerns...).

[AThousandShips]

Agreed, I think adding a reset before it actually is functionally different will either:

• Never be used as it doesn't make any difference, or,
• Will be used inconsistently and will make changing it to actually have distinct functionality a mess