| |
 | Posted by zxinsworld@gmail.com |  Permalink Reply |
|
zxinsworld@gmail.com 
| https://issues.dlang.org/show_bug.cgi?id=24682
zxinsworld@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |zxinsworld@gmail.com
--- Comment #1 from zxinsworld@gmail.com ---
(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.
--
|
