Board Thread:Watercooler/@comment-3032314-20181119015150/@comment-3032314-20190129214934

I haven't really thought about preserving T's legacy behavior. If flags were the only breaking change then, as you say, we could just manipulate args to align with Parsemageddon. However, there's another change which is, as far as I can tell, irreconcilable. Consider the following example:

According to the current documentation:


 * and  are "parameter names"
 * is a "parameter description"
 * is a "literal parameter value"

The problem is, parameter names and literal parameter values do the same thing (they both describe a specific value), but are written in different ways (one requires quotes, the other doesn't). Aside from being annoying, this inconsistency makes it impossible to generalize parameter descriptions. For example, imagine you wanted to describe this:

With generalized descriptions, you could write something like this:

...to get something like this:

Additionally, generalized descriptions would improve usability, removing some annoying restrictions and making T more consistent.

So why is the quotes-versus-no-quotes thing "irreconcilable" with generalized descriptions? Let's take a closer look at the current (pre-Parsemageddon) syntax:


 * 1) The parser splits each parameter into a left- and right-hand side.
 * 2) The parser implicitly interprets the LHS as a literal value.
 * 3) The parser implicitly interprets the RHS as a description. The user can explicitly tell it to interpret the RHS as a literal value instead.

Although we could technically keep the two sides inconsistent, doing so would a) make the parser more complicated, and b) make T as a whole more difficult to use. That option is a nonstarter for me. Therefore, we have two choices:


 * Default to literal values, with descriptions as an opt-in. This is (more-or-less) what the LHS does now.
 * Default to descriptions, with literal values as an opt-in. This is what the RHS does now.

The first option would change the way  and   are interpreted when placed on the RHS. The second option would change the way  is interpreted when placed on the LHS. Either way, we're guaranteed to break something.

I'm still not sure how to handle these breaking changes, though! One approach I've been considering is:


 * 1) Copy the code from Module:T to [ Module:T/legacy]
 * 2) Write a short article explaining how to keep using the legacy version
 * 3) Make ,  , and   all throw an error with a short explanation about the legacy version and a link to the explainer

What do you think?