Page MenuHomePhabricator

Parser Functions should support named parameters
Open, Needs TriagePublic


To quote :

Parser functions do not support named parameters the way templates and tag extensions do, but it is occasionally useful to fake it.

For uniformity of template syntax parsing, and to prevent continued slightly-incompatible wheel reinvention, we should fix this. When a parser function is registered with SFH_NAMED_ARGS as a flag to [Parser::setFunctionHook]( standardized parsing of named arguments should be done by core. Users should be encouraged to migrate to this.

We should think carefully through the desired behavior for whitespace-stripping of argument values, and ensure it makes sense with T114432: [RFC] Heredoc arguments for templates (aka "hygienic" or "long" arguments).

(Note that argument values for extension tags is whitespace-stripped in core, which is arguably a misfeature: T267974#6625861 )

Event Timeline

I note that the code at that link seems a bit outdated. A parser function that wants named arguments today should probably use SFH_OBJECT_ARGS and use PPNode->splitArg(), more or less like PPFrame_Hash::newChild() does or like Parser::braceSubstitution() does for special page transclusion.

That's not to oppose this task, I think a new SFH_NAMED_ARGS flag to make it even easier for implementers would be a good idea.

When opting in to "standard" named argument parsing, you might want to opt-in to replacing the first colon with a vertical bar to look even more like a "standard" template invocation: T204371: Replace initial colon in (hash-prefixed) parser function invocation with vertical bar.

Removing task assignee due to inactivity, as this open task has been assigned to the same person for more than two years (see the emails sent to the task assignee on Oct27 and Nov23). Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome.
(See for tips how to best manage your individual work in Phabricator.)