Thread overview | |||||||||
---|---|---|---|---|---|---|---|---|---|
|
November 06, 2018 Module function conflicting with reserve function | ||||
---|---|---|---|---|
| ||||
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, 2018 Re: Module function conflicting with reserve function | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Campbell | 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, 2018 Re: Module function conflicting with reserve function | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Campbell | Sorry, forgot to put the spec link into my previous resonse: https://dlang.org/spec/function.html#overload-sets |
November 06, 2018 Re: Module function conflicting with reserve function | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stanislav Blinov | 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, 2018 Re: Module function conflicting with reserve function | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Campbell | 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, 2018 Re: Module function conflicting with reserve function | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Campbell | 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, 2018 Re: Module function conflicting with reserve function | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stanislav Blinov | 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
|
Copyright © 1999-2021 by the D Language Foundation