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.

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:
>
> https://forum.dlang.org/post/mailman.1117.1581368593.31109.digitalmars-d@puremagic.com
>
> "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.

Hi,

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()),
  py(tuple!("data", "columns")(numpyArray, py(["a", "b"]))));

vs.

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

Kind regards
André

On Thursday, 8 October 2020 at 14:05:14 UTC, Andre Pany wrote:
> how to this new feature interact with opDispatch? Will there be any possibility to extract the argument names in opDispatch?

Good catch. The DIP doesn't mention opDispatch and it's probably too late to change. I also don't really see a non-breaking way to tell opDispatch about parameter names.
Giving opDispatch a string[] of named arguments' names (with "" for a name-less argument) would probably do the job, but it's a breaking change.

A different solution would be a new operator method called `opDispatchNamed` or alike that does exactly that. However, opDispatch is designed to be used when `c` in expr.c cannot be resolved, where expr.c(args) is a special case where `c` happens to be "something callable".

I'd say, the problem should be solved on a more general level: function templates *in general* (opDispatch included) should have a way to get named arguments' names. One possibility would be a magic __ARG_NAMES__ that returns a compile-time string[] that contains that names, like __FILE__ and __LINE__ at call site if used as a default parameter. So you'd use it like:

    auto opDispatch(
        string methodName,
        string[] argNames = __ARG_NAMES__,
        T, Ts...
    )(T arg, Ts args)
    {
        // argNames[0] will be "arg" always since it's not an pack.
    }

That way, it could be non-breaking and more useful.

On Wednesday, 28 October 2020 at 02:22:14 UTC, Q. Schroll wrote:
> On Thursday, 8 October 2020 at 14:05:14 UTC, Andre Pany wrote:
>> [...]
>
> Good catch. The DIP doesn't mention opDispatch and it's probably too late to change. I also don't really see a non-breaking way to tell opDispatch about parameter names.
> Giving opDispatch a string[] of named arguments' names (with "" for a name-less argument) would probably do the job, but it's a breaking change.
>
> [...]

Thank you a lot for your analysis. Once the feature is implemented I will create a feature request and add your proposal.

Kind regards
Andre

On Thursday, 17 September 2020 at 12:59:05 UTC, Mike Parker wrote:
> On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker wrote:
>> DIP 1030, "Named Arguments", has been accepted.
>>
>
> https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1030.md

Fantastic news.

The fact that it is a caller decision to use or not names emphasizes the D "syntax sugar" oriented conventions (like "dot notation"): same method can be called using the way it fits better with your on convention.

countOcurrences("hello", "e");
"hello".countOcurrences("e");
"hello".countOcurrences(of:"e"),
countOcurrences(of:"e", in:"hello");

I use rdmd as scripting tool, and I have to say that I will adopt immediately named parameters usage:  in addition to scope(...), ranges and the simplicity/power of the standard library, D becomes an expressive and powerful scripting language.

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:
>
> https://forum.dlang.org/post/mailman.1117.1581368593.31109.digitalmars-d@puremagic.com
>
> "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.

Very practical features, similar to trailing closures, are expected.

On Monday, 7 December 2020 at 12:13:35 UTC, zoujiaqing wrote:
> On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker wrote:
>> [...]
>
> Very practical features, similar to trailing closures, are expected.

Implementing the DIP is added to the list of possible gsoc21 projects. Hopefully D is this year elected.

https://github.com/dlang/projects/issues/76

It will also make porting python libraries to D easier as it minimizes coding differences.

Kind regards
Andre