I'm not sure if I'm missing something obvious here, but the following code compiles and runs:

void foo() {}
void foo() {}

void main() {}

Although if I do call "foo", the compiler will complain that it matches both versions of "foo".

Is this expected behavior of how function overloading works? Is it possible to for the compiler to report this error? At least this example is pretty obvious for a human to see.

-- 
/Jacob Carlborg

On Saturday, 15 April 2017 at 09:17:08 UTC, Jacob Carlborg wrote:
> I'm not sure if I'm missing something obvious here, but the following code compiles and runs:
>
> void foo() {}
> void foo() {}
>
> void main() {}
>
> Although if I do call "foo", the compiler will complain that it matches both versions of "foo".
>
> Is this expected behavior of how function overloading works? Is it possible to for the compiler to report this error? At least this example is pretty obvious for a human to see.

It would requires an O(n^2) check per declaration.
Even it is never used.
which would make imports that much more expensive.

On 2017-04-15 13:10, Stefan Koch wrote:

> It would requires an O(n^2) check per declaration.
> Even it is never used.
> which would make imports that much more expensive.

Does it need to be that bad? Isn't it possible to do some simple checks with less overhead? Something like first checking the name and the number of parameters (shouldn't require semantic analyze?) and only do the check for those functions that match. I would guess that would be quite few functions that falls within that criteria. Also, only within a single module.

-- 
/Jacob Carlborg

On Saturday, 15 April 2017 at 11:10:01 UTC, Stefan Koch wrote:
> It would requires an O(n^2) check per declaration.
> Even it is never used.
> which would make imports that much more expensive.

 Seems wrong to me...

 If you made a list/array of all the functions (based purely on signatures) then sorted them, then any duplicates would be adjacent. Scanning that list would be O(n-1).

 This assumes it's done after all functions are scanned and identified, doing it earlier is a waste of time and energy.

On Sunday, 16 April 2017 at 10:56:37 UTC, Era Scarecrow wrote:
> On Saturday, 15 April 2017 at 11:10:01 UTC, Stefan Koch wrote:
>> It would requires an O(n^2) check per declaration.
>> Even it is never used.
>> which would make imports that much more expensive.
>
>  Seems wrong to me...
>
>  If you made a list/array of all the functions (based purely on signatures) then sorted them, then any duplicates would be adjacent. Scanning that list would be O(n-1).
>
>  This assumes it's done after all functions are scanned and identified, doing it earlier is a waste of time and energy.


sorting has O(n^2) worst case complexity.
Therefore totaling to O(n^2) worst case again.

On Sunday, 16 April 2017 at 15:54:16 UTC, Stefan Koch wrote:
> On Sunday, 16 April 2017 at 10:56:37 UTC, Era Scarecrow wrote:
>> On Saturday, 15 April 2017 at 11:10:01 UTC, Stefan Koch wrote:
>>> It would requires an O(n^2) check per declaration.
>>> Even it is never used.
>>> which would make imports that much more expensive.
>>
>>  Seems wrong to me...
>>
>>  If you made a list/array of all the functions (based purely on signatures) then sorted them, then any duplicates would be adjacent. Scanning that list would be O(n-1).
>>
>>  This assumes it's done after all functions are scanned and identified, doing it earlier is a waste of time and energy.
>
>
> sorting has O(n^2) worst case complexity.
> Therefore totaling to O(n^2) worst case again.

Why this difficulty ?
Function[args][name] funcs;

AA lookup is O(1).

On Sunday, 16 April 2017 at 17:10:14 UTC, Temtaime wrote:
> On Sunday, 16 April 2017 at 15:54:16 UTC, Stefan Koch wrote:
>> On Sunday, 16 April 2017 at 10:56:37 UTC, Era Scarecrow wrote:
>>> On Saturday, 15 April 2017 at 11:10:01 UTC, Stefan Koch wrote:
>>>> It would requires an O(n^2) check per declaration.
>>>> Even it is never used.
>>>> which would make imports that much more expensive.
>>>
>>>  Seems wrong to me...
>>>
>>>  If you made a list/array of all the functions (based purely on signatures) then sorted them, then any duplicates would be adjacent. Scanning that list would be O(n-1).
>>>
>>>  This assumes it's done after all functions are scanned and identified, doing it earlier is a waste of time and energy.
>>
>>
>> sorting has O(n^2) worst case complexity.
>> Therefore totaling to O(n^2) worst case again.
>
> Why this difficulty ?
> Function[args][name] funcs;
>
> AA lookup is O(1).

AA lookup is _NOT_ O(1).
Worst case is O(n).

On Sunday, 16 April 2017 at 15:54:16 UTC, Stefan Koch wrote:
> sorting has O(n^2) worst case complexity.
> Therefore totaling to O(n^2) worst case again.

Sorting with comparison is solved in O(n log n). If you have an upper limit on signature length then the problem is solvable for the whole program in O(n).

Not that this says an awful lot...