Module function conflicting with reserve function
Steven Schveighoffer
schveiguy at gmail.com
Tue Nov 6 21:22:09 UTC 2018
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
More information about the Digitalmars-d-learn
mailing list