www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Naming issue importing different function overloads

reply data pulverizer <data.pulverizer gmail.com> writes:
Hi,

There's issue in importing functions I came across some time ago 
that I wonder if it is a purposeful design or if it is something 
that will be changed in the future.

Say I have module like this:

```d
module funs;


double myfun(double x)
{
   return x*x;
}
```

and I call `myfun` in a function in another module:

```d
module call;

import funs;


double myfun(double y, double x)
{
    return myfun(x)/y;
}

void main()
{
   import std.stdio: writeln;
   writeln("Demo myfun(2, 3): ", myfun(2, 3));
}

```

If I attempt to compile this I shall get the error:


```
$ dmd call.d funs.d
call.d(8): Error: function call.myfun(double y, double x) is not 
callable using argument types (double)

```

Even though the function signatures are different I have to call 
`myfun` with `funs.myfun(...)` in the `call.d` module. I 
understand sometimes it's is good practice to do this, but 
shouldn't I expect the D compiler to be "clever enough" to ignore 
correct use but detect when function signatures clash and 
throwing an error with an appropriate message when they do, 
rather than a cryptic message telling me that the function 
signature is wrong?

In the current situation, you can import `funs.d` and call 
`myfun` with no issue until you decide to overload it in that 
module, when you suddenly get errors. If you are not aware of 
this issue and you are writing a large and highly detailed 
module, it's an error that seems to come out of nowhere, the 
module has suddenly lost visibility of the imported function.

I guess an alternative is to use `mixin(import("funs.d"));` but 
you then lose the functionality of the formal `import` statement.

Thank you
May 30
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 30 May 2021 at 18:42:34 UTC, data pulverizer wrote:
 I wonder if it is a purposeful design
It is by design: https://dlang.org/articles/hijack.html Basically the idea behind it is to make sure that a change in a lib you import doesn't change your existing code without you realizing it. You can merge them at the import site by doing import funs; doubme myfun(...) {} alias myfun = funs.myfun; // this line merges them You can also use a selective import to merge them: import funs : myfun; double myfun(...) {} now both myfuns work. this works because the `import x : y;` is actually shorthand for a local alias.
May 30
parent data pulverizer <data.pulverizer gmail.com> writes:
On Sunday, 30 May 2021 at 18:50:25 UTC, Adam D. Ruppe wrote:
 On Sunday, 30 May 2021 at 18:42:34 UTC, data pulverizer wrote:
 I wonder if it is a purposeful design
It is by design: https://dlang.org/articles/hijack.html Basically the idea behind it is to make sure that a change in a lib you import doesn't change your existing code without you realizing it. You can merge them at the import site by doing import funs; doubme myfun(...) {} alias myfun = funs.myfun; // this line merges them You can also use a selective import to merge them: import funs : myfun; double myfun(...) {} now both myfuns work. this works because the `import x : y;` is actually shorthand for a local alias.
Many thanks
May 31