import std.math;
real round(real val, int prec)
{
    real pow = 10 ^^ prec;
    return round(val * pow) / pow;
}

Trying to compile this I get:

foo.d(5): Error: function foo.round (real val, int prec) is not callable using argument types (real)

When I've imported std.math which contains round(real), why is the compiler complaining about not being able to call the overload function defined in *this* module?

I don't see anything in http://dlang.org/module.html that says I cannot define an overload of an imported function. Did I miss something?

-- 
Shriramana Sharma, Penguin #395953

http://dlang.org/hijack.html

On Wednesday, October 21, 2015 02:05 PM, Shriramana Sharma wrote:

> When I've imported std.math which contains round(real), why is the compiler complaining about not being able to call the overload function defined in *this* module?

The functions don't form an overload set. You need to bring them together explicitly using `alias`:

----
import std.math;
alias round = std.math.round;
real round(real val, int prec) {...}
----

This is so to avoid function hijacking. See <http://dlang.org/hijack.html>.

> I don't see anything in http://dlang.org/module.html that says I cannot define an overload of an imported function. Did I miss something?

That page doesn't seem to mention overloads at all. <http://dlang.org/function.html#overload-sets> covers overload sets from different imports, but it doesn't mention this specific case where there is a local overload set, too.

On Wednesday, 21 October 2015 at 12:05:27 UTC, Shriramana Sharma wrote:
> import std.math;
> real round(real val, int prec)
> {
>     real pow = 10 ^^ prec;
>     return round(val * pow) / pow;
> }
>
> Trying to compile this I get:
>
> foo.d(5): Error: function foo.round (real val, int prec) is not callable using argument types (real)
>
> When I've imported std.math which contains round(real), why is the compiler complaining about not being able to call the overload function defined in *this* module?
>
> I don't see anything in http://dlang.org/module.html that says I cannot define an overload of an imported function. Did I miss something?

You might find something useful in section 2 of https://github.com/DlangScience/design/blob/master/design.pdf and also somewhat related: http://arsdnet.net/this-week-in-d/sep-27.html

Kagamin wrote:

> http://dlang.org/hijack.html

Thanks people, but even as per the rules:

1. Perform overload resolution independently on each overload set
2. If there is no match in any overload set, then error
3. If there is a match in exactly one overload set, then go with that
4. If there is a match in more than one overload set, then error

Here there is only one round(real, int) i.e. in the current module and only one round(real) i.e. in the imported module, so as per rule 3, there should be a clear resolution.

So why the conflict then?

-- 
Shriramana Sharma, Penguin #395953

On Wednesday, October 21, 2015 08:28 PM, Shriramana Sharma wrote:

> Kagamin wrote:
> 
>> http://dlang.org/hijack.html
> 
> Thanks people, but even as per the rules:
> 
> 1. Perform overload resolution independently on each overload set
> 2. If there is no match in any overload set, then error
> 3. If there is a match in exactly one overload set, then go with that
> 4. If there is a match in more than one overload set, then error
> 
> Here there is only one round(real, int) i.e. in the current module and
> only one round(real) i.e. in the imported module, so as per rule 3, there
> should be a clear resolution.
> 
> So why the conflict then?

Huh. I can't find any specification on this, but apparently the local overload set shadows any imported overload sets completely.

I don't know if there's a good reason for this. All I can think of is I don't want some local `write` function to conflict with std.stdio.write. But the local overload set wouldn't need to shadow the others completely for that. It would be enough if it took precedence on conflict.

anonymous wrote:

> Huh. I can't find any specification on this, but apparently the local overload set shadows any imported overload sets completely.

Should I file a bug on this then?

-- 
Shriramana Sharma, Penguin #395953

On 22.10.2015 06:14, Shriramana Sharma wrote:
> anonymous wrote:
>
>> Huh. I can't find any specification on this, but apparently the local
>> overload set shadows any imported overload sets completely.
>
> Should I file a bug on this then?

I'm not sure. Maybe make a thread on the main group first. It's not clear to me if the compiler is wrong, or if the spec needs to be made more precise. Or maybe I just failed to find the relevant part of the spec.

Forwarding a thread from the D.learn forum:

Shriramana Sharma wrote:

> import std.math;
> real round(real val, int prec)
> {
>     real pow = 10 ^^ prec;
>     return round(val * pow) / pow;
> }
> 
> Trying to compile this I get:
> 
> foo.d(5): Error: function foo.round (real val, int prec) is not callable
> using argument types (real)
> 
> When I've imported std.math which contains round(real), why is the compiler complaining about not being able to call the overload function defined in *this* module?
> 
> I don't see anything in http://dlang.org/module.html that says I cannot define an overload of an imported function. Did I miss something?

Kagamin wrote:

> http://dlang.org/hijack.html

Shriramana Sharma wrote:

> Thanks people, but even as per the rules:
> 
> 1. Perform overload resolution independently on each overload set
> 2. If there is no match in any overload set, then error
> 3. If there is a match in exactly one overload set, then go with that
> 4. If there is a match in more than one overload set, then error
> 
> Here there is only one round(real, int) i.e. in the current module and
> only one round(real) i.e. in the imported module, so as per rule 3, there
> should be a clear resolution.
> 
> So why the conflict then?

Clearly when the signature of the overload in the current module is different from that in the imported module, there should be no hijacking and thus no measures needed to prevent it. Yet I am not able to compile.

Should I file a bug? Please advise.

-- 
Shriramana Sharma, Penguin #395953

On Wednesday, 21 October 2015 at 12:05:27 UTC, Shriramana Sharma wrote:
> import std.math;
> real round(real val, int prec)
> {
>     real pow = 10 ^^ prec;
>     return round(val * pow) / pow;
> }
>
> Trying to compile this I get:
>
> foo.d(5): Error: function foo.round (real val, int prec) is not callable using argument types (real)
>
> When I've imported std.math which contains round(real), why is the compiler complaining about not being able to call the overload function defined in *this* module?
>
> I don't see anything in http://dlang.org/module.html that says I cannot define an overload of an imported function. Did I miss something?

My guess is that <filename>.round shadows math.round. But you can get desired behavior
by moving declaration of math.round inside scope of <filename>.round. This compiles:

real round(real val, int prec)
{
    import std.math;
    real pow = 10 ^^ prec;
    return round(val * pow) / pow;
}