www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Module function conflicting with reserve function

reply Peter Campbell <peteypoo pm.me> writes:
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()
{
}
Nov 06 2018
next sibling parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
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);
}
Nov 06 2018
parent reply Peter Campbell <peteypoo pm.me> writes:
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?
Nov 06 2018
next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
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
Nov 06 2018
prev sibling parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
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.
Nov 06 2018
parent Peter Campbell <peteypoo pm.me> writes:
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
Nov 07 2018
prev sibling parent Stanislav Blinov <stanislav.blinov gmail.com> writes:
Sorry, forgot to put the spec link into my previous resonse: 
https://dlang.org/spec/function.html#overload-sets
Nov 06 2018