Thread overview
Naming issue importing different function overloads
May 30, 2021
data pulverizer
May 30, 2021
Adam D. Ruppe
May 31, 2021
data pulverizer
May 30, 2021

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:

module funs;


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

and I call myfun in a function in another module:

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)
call.d(8):        missing argument for parameter #2: double x

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, 2021

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 31, 2021

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