Hi there. I've been playing with D and have encountered this really awkward behaviour. Basically I'm getting a compiler error inside a function I wrote in my module as it thinks I'm trying to call itself with invalid parameters, when actually I want it to call the reserve function on the array itself. Is this a bug or expected behaviour? It seems quite strange and potentially annoying to me.

https://run.dlang.io/is/9YyAI9

module bob;

struct Bob
{
    private ubyte[] _data;
}

void reserve(ref Bob system, in size_t capacity)
{
    // bob.reserve(ref Bob system, const(ulong) capacity) is not callable with (ubyte[], const(ulong)).
    system._data.reserve(capacity);
}

void main()
{
}

On Tuesday, 6 November 2018 at 20:40:11 UTC, Peter Campbell wrote:
> Hi there. I've been playing with D and have encountered this really awkward behaviour. Basically I'm getting a compiler error inside a function I wrote in my module as it thinks I'm trying to call itself with invalid parameters, when actually I want it to call the reserve function on the array itself. Is this a bug or expected behaviour? It seems quite strange and potentially annoying to me.

It's not a bug, just the way name resolution works. Better have collision than silent overloads. Possible solutions:

```
void reserve(ref Bob system, in size_t capacity) {
     // explicitly disambiguate
     object.reserve(system._data, capacity);
}
```

or:

// pull in the runtime 'reserve' into this module's scope
alias reserve = object.reserve;

void reserve(ref Bob system, in size_t capacity) {
     // call reserve as usual
     system._data.reserve(capacity);
}

Sorry, forgot to put the spec link into my previous resonse: https://dlang.org/spec/function.html#overload-sets

On Tuesday, 6 November 2018 at 21:03:01 UTC, Stanislav Blinov wrote:
> It's not a bug, just the way name resolution works. Better have collision than silent overloads. Possible solutions:
>
> ```
> void reserve(ref Bob system, in size_t capacity) {
>      // explicitly disambiguate
>      object.reserve(system._data, capacity);
> }
> ```
>
> or:
>
> // pull in the runtime 'reserve' into this module's scope
> alias reserve = object.reserve;
>
> void reserve(ref Bob system, in size_t capacity) {
>      // call reserve as usual
>      system._data.reserve(capacity);
> }

Given your second example that makes me think that, because object functions are provided by the runtime without me explicitly importing it, this is likely only an issue for object functions? Or can this behaviour happen with any free functions with the same name but completely different parameter types?

On 11/6/18 4:19 PM, Peter Campbell wrote:
> On Tuesday, 6 November 2018 at 21:03:01 UTC, Stanislav Blinov wrote:
>> It's not a bug, just the way name resolution works. Better have collision than silent overloads. Possible solutions:
>>
>> ```
>> void reserve(ref Bob system, in size_t capacity) {
>>      // explicitly disambiguate
>>      object.reserve(system._data, capacity);
>> }
>> ```
>>
>> or:
>>
>> // pull in the runtime 'reserve' into this module's scope
>> alias reserve = object.reserve;
>>
>> void reserve(ref Bob system, in size_t capacity) {
>>      // call reserve as usual
>>      system._data.reserve(capacity);
>> }
> 
> Given your second example that makes me think that, because object functions are provided by the runtime without me explicitly importing it, this is likely only an issue for object functions? Or can this behaviour happen with any free functions with the same name but completely different parameter types?

It has nothing to do with the parameters, it has to do with visibility preference. Basically, the current module trumps any imported modules (including object). As Stanislav mentions, you can alias the imported reserve into your module namespace so they have equal footing.

-Steve

On Tuesday, 6 November 2018 at 21:19:29 UTC, Peter Campbell wrote:

> Given your second example that makes me think that, because object functions are provided by the runtime without me explicitly importing it, this is likely only an issue for object functions? Or can this behaviour happen with any free functions with the same name but completely different parameter types?

Not with completely different parameter types, no. But it can happen with functions imported from different modules, as they're from different overload sets. There's an example in that Overload Sets section of the spec.

On Tuesday, 6 November 2018 at 21:29:17 UTC, Stanislav Blinov wrote:
> On Tuesday, 6 November 2018 at 21:19:29 UTC, Peter Campbell wrote:
>
>> Given your second example that makes me think that, because object functions are provided by the runtime without me explicitly importing it, this is likely only an issue for object functions? Or can this behaviour happen with any free functions with the same name but completely different parameter types?
>
> Not with completely different parameter types, no. But it can happen with functions imported from different modules, as they're from different overload sets. There's an example in that Overload Sets section of the spec.

I see what you both mean now and understand what's going on. Thanks for clearing it up