Comment #0 by qs.il.paperinik — 2024-07-25T09:59:43Z
In certain circumstances, e.g. passing a `true` or `false` as function parameters, named arguments should be required (unless the bound function parameter is unnamed, of course, which is common for function pointers and delegates).
Examples of “problematic” arguments are basic literals (bool literals, `null`, numbers, and strings, but not e.g. (associative) array literals or lambda expressions), as quite often, it’s unclear at the function invocation what those mean. In contrast, calling a function with a named variable or expression usually gives a hint about what the argument means. (Associative) array literals and lambda expressions likewise often enough carry enough information what the parameter is for so that such an error would be a false positive.
Also, some other basic expressions should count as literals, in particular, literals under a cast (think `cast(byte)0`) or function-call-like type conversion (e.g. `byte(0)`), as those are essentially literals.
The error message should print a copy of the function call expression with named arguments added, or indicate exactly where the parameter name were to be added in some other way. Examples:
```
Error: Basic literals require a named argument when passed to a function.
f(someArg, mustUse: true);
```
or
Error: Basic literals require a named argument when passed to a function.
f(someArg, true);
~~~~ mustUse: true
```
or
Error: Basic literals require a named argument when passed to a function.
f(someArg, true);
^ mustUse:
```
This enhancement is in line with D’s policy to make code invalid that would have a formally clear interpretation, but may be confusing to read, when a trivial mitigation is possible and reasonable. Other examples are banning `=> {}` and requiring parentheses to clarify operator precedence of bit-wise and comparison operators.
Comment #1 by zxinsworld — 2024-07-25T12:46:40Z
(In reply to Bolpat from comment #0)
> Examples of “problematic” arguments are basic literals (bool literals,
> `null`, numbers, and strings, but not e.g. (associative) array literals or
> lambda expressions), as quite often, it’s unclear at the function invocation
> what those mean. In contrast, calling a function with a named variable or
> expression usually gives a hint about what the argument means. (Associative)
> array literals and lambda expressions likewise often enough carry enough
> information what the parameter is for so that such an error would be a false
> positive.
Using blanket assumptions about how types are used to force people to call functions in a certain way is a recipe for frustration. Take this function call:
```
file.setReadOnly(true);
```
This is already perfectly verbose without any named parameters. On the other hand, the assumption that array literal or lambda expression parameters are never ambiguous is simply untrue. AA’s `update` is a perfect example of this:
```
aa.update(
"key",
() => 0,
(int a){},
);
```
This is a case where I usually use named parameters, which wouldn’t be forced upon me. Whereas, in the situations where it would be forced, it wouldn’t always be of any benefit. It would also be annoying to memorise what types have this arbitrary behaviour, and would require exceptions for variadic templates, `opDispatch`, etc.
This would also be a major threat to meta-programming, requiring a huge amount of work just to create a correctly forwarded function call. In particular, a lot of code I have written with meta-programming would require hours of unnecessary work to fix errors caused by this unnecessary change.
Comment #2 by robert.schadek — 2024-12-13T19:36:44Z