Thread overview
Module function conflicting with reserve function
November 06
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()
{
}
November 06
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);
}
November 06
Sorry, forgot to put the spec link into my previous resonse: https://dlang.org/spec/function.html#overload-sets
November 06
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?
November 06
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
November 06
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.
November 07
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