July 25 [Issue 24682] New: [next edition] Require named arguments in certain circumstances | ||||
---|---|---|---|---|
| ||||
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. -- |
Copyright © 1999-2021 by the D Language Foundation