Compiler can't see both PROCEDURE and FUNCTIOn of the same name...

[Zoran]

Yes, Furious, it is more or less the same example that I gave in the bug report.
The point is -- it should not compile and it should not work (you cannot be sure which function will be called, and the other function just cannot be called).

[furious programming]

I think the same. I wonder if the FPC developers too.

[Zoran]

I think the same. I wonder if the FPC developers too.

They probably do. If I had provided the patch which solves it properly, they would probably accept it.
But I didn't, I just reported this.

Now when the problem is at least reported, the question is will someone want (and have time) to take this and fix. Perhaps it is easy, perhaps not.

And we have to admit that this is not a critical bug which prevents compilation of well written code. We know that we should not write two functions with same name and same arguments in same scope, so we don't do it and we don't have problems with it, do we?

[jamie]

Having multiple functions with the same name and argument but with different result types,  is perfectly fine and I do
this a lot depending on the resulting type, the compiler uses the result type as part of the selection process.

 But the real issue is if the compiler detects a call that is PROCEDURE in nature not function, it should look for a
PROCEDURE match and if not found then test for the Extend option to allow using functions as PROCEDURES and then
find a match on those. If after that fails, then the compiler should flag an error..

 But the problem is that the compiler is simply taking the first one it finds and not checking for PPOCEDURAL or
FUNCTION style of calling..

 It would be interesting if someone could test this in a recent release of Delphi..

[Zoran]

Having multiple functions with the same name and argument but with different result types,  is perfectly fine and I do
this a lot depending on the resulting type, the compiler uses the result type as part of the selection process.

I doubt that. May I ask you for simple compilable code where such functions are used?

It would be interesting if someone could test this in a recent release of Delphi..

Why don't we just take a look at the docs:

Overloaded routines must be distinguished by the number of parameters they take or the types of their parameters. Hence the following pair of declarations causes a compilation error:

 function Cap(S: string): string; overload;
   ...
 procedure Cap(var Str: string); overload;
   ...

See what Marco Cantù wrote in his Essential Pascal (bold by me):

The differences must be in the number or type of the parameters, or both. The return type, instead, cannot be used to distinguish among two routines.

Let's see other languages.

C++:

Here is what learncpp says about function overloading:

Function return types are not considered for uniqueness

Note that the function’s return type is NOT considered when overloading functions.

And tutorialspoint says:

You cannot overload function declarations that differ only by return type.

Java:

From the official Java Tutorial:

The compiler does not consider return type when differentiating methods, so you cannot declare two methods with the same signature even if they have a different return type.

C#:

From Microsoft docs:

Note

Changing the return type of a method does not make the method unique as stated in the common language runtime specification. You cannot define overloads that vary only by return type.

Enough?

[jamie]

This is PASCAL, must we repeat the mistakes of others?

 In any case, I must of been thinking something else, I do several languages including PLC's etc.
 
 My head does get mixed up at times.

[Thaddy]

Alternatively: use just procedures and instead of result specify out parameters. Or even functions, but with the out parameter too.

[marcov]

This is PASCAL, must we repeat the mistakes of others?

Enable mode delphi. Then overloading must be explicit.

[Thaddy]

This is PASCAL, must we repeat the mistakes of others?

Enable mode delphi. Then overloading must be explicit.

Yes, and it warns with that code... Now add the overload directives... recompile.... same issue: no errors, compiler picks first one...

[marcov]

Yes, and it warns with that code... Now add the overload directives... recompile.... same issue: no errors, compiler picks first one...

That's like accidentally removing your armor and the safety pin before shooting yourself.

[Thaddy]

That's like accidentally removing your armor and the safety pin before shooting yourself.

Not quite.. I already tested your mode delphi scenario yesterday. In BOTH modes - delphi mode: overload added - the compiler shows no error and picks the first one instead of throwing "can't determine which overloaded function to call" or something.
The issue is in both modes.  How bad the initial code may be, there should be a warning or error. Silly mode or Delphi mode.
[edit] QED

Code: Pascal  [Select][+][-]

1. {$mode delphi}{$H+}
2.  
3. procedure TestOverload(N: Integer);overload;
4. begin
5.   writeln('Version with no result called');
6. end;
7.  
8. function TestOverload(N: Integer): Integer;overload;
9. begin
10.   writeln('Integer version called');
11.   Result := 0;
12. end;
13.  
14. function TestOverload(N: Integer): String;overload;
15. begin
16.   writeln('String version called');
17.   Result := '';
18. end;
19.  
20. begin
21.   TestOverload(0);
22. end.

I have added it to the bug report.