Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
For formatting, it seems pretty clear to me that it should just be analogous to type hints in the definition:
// Single-line call:
foo($a, bar: $b);
// Multi-line call:
foo(
$a,
bar: $b,
);
I.e., no space before the colon, one space after the colon.
I’d leave it pretty open when a named parameter should be used. Of course, if #3183180: [policy, no patch] Document named arguments BC policy concludes that parameter names are not part of the public API, then using named parameters in call to Core’s (other modules’) code would automatically be discouraged. But otherwise, I’d just let developers decide for themselves when using a named parameter makes sense.
Comments
Comment #2
drunken monkeyFor formatting, it seems pretty clear to me that it should just be analogous to type hints in the definition:
I.e., no space before the colon, one space after the colon.
I’d leave it pretty open when a named parameter should be used. Of course, if #3183180: [policy, no patch] Document named arguments BC policy concludes that parameter names are not part of the public API, then using named parameters in call to Core’s (other modules’) code would automatically be discouraged. But otherwise, I’d just let developers decide for themselves when using a named parameter makes sense.