The use case is https://code.wildfiregames.com/D1726.

In rP22003#33957, @elexis wrote:

• Integer/Schema:

Supporting an integer type in the schema sounds right regardless which templates 0ad provides.

We support integers just fine in our XML schemas. The problem is that multiplying an integer by a decimal sometimes leads to non-integer values.

Going to rephrase this revision to address #3818.

That didn't happen, the ticket is open. The 'multiplied integer schema' use case is not implemented in this repository.

Apparently forgot to close it.

We support integers just fine in our XML schemas. The problem is that multiplying an integer by a decimal sometimes leads to non-integer values.

As far as I understood the idea is to be able to support op="mul" and op="add" with integer types and do the rounding if the type is an integer, otherwise don't do the rounding.
This way the schema / template can continue to use the integer type if that is the datatype intended by the template author.

In rP22003#33969, @elexis wrote:

We support integers just fine in our XML schemas. The problem is that multiplying an integer by a decimal sometimes leads to non-integer values.

As far as I understood the idea is to be able to support op="mul" and op="add" with integer types and do the rounding if the type is an integer, otherwise don't do the rounding.
This way the schema / template can continue to use the integer type if that is the datatype intended by the template author.

Mpf, that actually could be it. I thought it meant that the op should specify we want integer operations - bit unclear. Leper seemed to favour specific operators in https://code.wildfiregames.com/D268.
I'm not sure that silently handling that for the user is better than explicit handling - at least code-wise this is probably the less intrusive implementation.

I also don't care that much about this topic - apparently no-one did either since D268 never got much attention except from leper and the followup neither.

I also don't care that much about this topic - apparently no-one did either since D268 never got much attention except from leper and the followup neither.

• You do care about that topic because you wrote a patch for it and proposed to close the ticket as fixed.
• Noone cared about this since ever, but this isn't a sign that this isn't problematic, but rather uninvestigated.
• If it receives attention of the people who worked on the code, then this is a reason to take that seriously.
• The argument isn't that the patch is introducing a bad trait (other than arguably unused hypothetic code) but that the solution is not the better one to fix the task at hand unless there is further evidence for the this use case not being covered by the integer schema use case.

In rP22003#33971, @elexis wrote:

I also don't care that much about this topic - apparently no-one did either since D268 never got much attention except from leper and the followup neither.

• You do care about that topic because you wrote a patch for it and proposed to close the ticket as fixed.

I don't care that much.

• The argument isn't that the patch is introducing a bad trait (other than arguably unused hypothetic code) but that the solution is not the better one to fix the task at hand unless there is further evidence for the this use case not being covered by the integer schema use case.

This code works just fine, it's easy to maintain, it's readable. It's not certain that the integer-schema thingy would result in cleaner, more maintainable code - I didn't find a way to write it.
I don't really see the point of raising a concern for code that's perfectly fine, only it might not be the best possible implementation. You're just adding noise to the audit queue.