• data pulverizer (50/50) May 30 2021 Hi,
• Adam D. Ruppe (15/16) May 30 2021 It is by design: https://dlang.org/articles/hijack.html
• data pulverizer (2/18) May 31 2021 Many thanks

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

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.

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