https://issues.dlang.org/show_bug.cgi?id=24682
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #1 from [email protected] --- (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. --
