https://issues.dlang.org/show_bug.cgi?id=24682

          Issue ID: 24682
           Summary: [next edition] Require named arguments in certain
                    circumstances
           Product: D
           Version: D2
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: dmd
          Assignee: nobody@puremagic.com
          Reporter: qs.il.paperinik@gmail.com

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.

--