September 23
On 9/23/2020 7:01 AM, Arun wrote:
>> How does the compiler handle function lookup when there is an ambiguous match, but the ambiguous function is in a different module?
> What would be the solution?

The same way it handles it without named arguments - an error.
October 08
On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker wrote:
> DIP 1030, "Named Arguments", has been accepted.
> During the assessment, Walter and Atila had a discussion regarding this particular criticism:
> "Named arguments breaks this very important pattern:
> auto wrapper(alias origFun)(Parameters!origFun args)
> {
>   // special sauce
>   return origFun(args);
> }"
> They say that, though it's true that `Parameters!func` will not work in a wrapper, it "doesn't really work now"---default arguments and storage classes must be accounted for. This can be done with string mixins, or using a technique referred to by Jean-Louis Leroy as "refraction", both of which are clumsy.
> So they decided that a new `std.traits` template and a corresponding `__traits` option are needed which expand into the exact function signature of another function.
> They also acknowledge that when an API's parameter names change, code depending on the old parameter names will break. Struct literals have the same problem and no one complains (the same is true for C99). And in any case, when such a change occurs, it's a hard failure as any code using named arguments with the old parameter names will fail to compile, making it easy to see how to resolve the issue. Given this, they find the benefits of the feature outweigh the potential for such breakage.


how to this new feature interact with opDispatch? Will there be any possibility
to extract the argument names in opDispatch?

If yes, this "might" increase the usability of pyd:
auto df = pd.DataFrame.unpack_call(
  py(tuple!("data", "columns")(numpyArray, py(["a", "b"]))));


auto df = pd.DataFrame(data=numpyArray, columns=["a", "b"]);

Kind regards
Next ›   Last »
1 2 3