The name of parameters with showkey=False should be determined dynamically

[Rua]

Let's say you have this code parsed:

{{list|item1|item2|item3}}

If you want to insert an item in the middle of the list, all the parameters keep their old names. This means you end up with duplicate parameter names, and you have to rename all the parameters manually, which is rather tedious. It would be much more useful if the numbers updated automatically in this case.

This could be done by making the .name property of parameters look up the parameter's current position, if showkey=False. Alternatively, whenever an unnamed parameter is inserted, the template could update all parameter names with showkey=False. However, this could lead to more inconsistencies: if you change showkey from False to True on a parameter, or vice versa, then the numbering of other parameters ought to change accordingly.

[lahwaacz]

Since there is no such thing as wrong wikitext, templates with duplicate named parameters can (and they really do) occur. How would you parse such templates with this dynamic behaviour? How would you guarantee that immediate serialization after parsing produces the same wikitext?

[Rua]

This question is about unnamed parameters, which can't be duplicated (although an unnamed parameter can be duplicated by a named one). And it only concerns how the parameters are named after edits are made to the wikitext. Only the names of parameters with showkey=False would be changed by this behaviour, parameters with showkey=True will continue to work as is, taking their name from the value stored in the object.

The proposal is more about making it easier for users to ensure that their wikitext remains consistent. If I insert a new unnamed parameter in a list of unnamed parameters, I don't want everything to break like it does now.

[lahwaacz]

If this is about unnamed parameters, I don't understand how you can "end up with duplicate parameter names". Can you provide more complete example, possibly including some code showing the problematic behaviour of mwparserfromhell?

[earwig]

Can you give an example? Struggling to come up with a situation where mwparserfromhell does not do what you expect it to...

[earwig]

Aha, GitHub, that's great! Daylight savings time messed up the comment order. Oh man.