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

[jamie]

When playing with HELPERS, I found that if I have both a FUNCTION and PROCEDURE of the same name using the
same prototype, the compiler see's only the First one in the list and Code tools see's the last one in the list.

 So for example, If I were to have the PROCEDURE version first, and then try to use it for as a FUNCTION, the compiler
the complains about it not being a function but there is a function version of it, compiler just refuses to use it.

 Of course I applied the usual  "Overload" but that does not seem to help.
 
 The purpose of this exercise was to have a function version that would simply return a value from data collected from
the input arguments and then Have a Procedure version of it to actually directly alter the input arguments as they are
past via reference..
 
 This way I could act directly on an item with out using a "Item := Item.(..)" or use the function version where the arguments do not get altered but simply return data based on those arguments without effecting the arguments.

has anyone noticed how the compiler  being blind to alternate calls in Helpers? I am not sure if this also is the
case else where?

[bzman24]

Explain to us again "WHY" would you use the same name for a PROCEDURE and a FUNCTION!!  I have been programming for over 30 years and NEVER have I ever thought of doing this.  I'm not sure why you would even think this would be a good idea and work!

BZMan

[jamie]

Very simple..

lets assume I added a SHL function to the BYTE helper, one has a function and one has a procedure..

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

1. Var
2.  A,B :Byte;
3. Begin
4.  A := 1;  //make it something;
5.  B := A.SL(Count);   //Function; B = A shift left Count times, A is retained
6.  A.SL(Count)  // Procedure version; A = A Shl Count Times; A is now changed
7.  

 I could do this using a FUNCTION version of it if I had a way of knowing how the variable is being parsed.
 
 As returning a results or a direct operation on the variable.

 Using the "SELF" identifier in the helper I can directly alter the arguments and being a function it returns dead weight
in code if I am not using it as a function, although not much code.

 So if the compiler could decide on using a PROCEDURE if the call Is PROCEDURE based over a function in cases like this, this
would work out perfectly!

 Procedure would not have the dead code for the return and I could directly alter the arguments via reference and then
if it was function based in nature it would just call the function instead.


 This would prevent requiring two different identifiers in the helper , one as a PROCEDURE and other a FUNCTION...
P.S.

 This is inline code also!

Do you understand now ?

[taazz]

No it can't overload functions are linked based on the list of parameters they accept not the results they return if the parameters are identical use only the procedure it can accommodate all your requirements easier.

[mangakissa]

Just add an extra parameter to your function. The function doesn't have returning a value.

[Thaddy]

Also note that because of some - major - modes that allow to ignore the function result you should never ever have a procedure and function with the same name and signature.
That also means you should be able to rewrite your function such that it can act as both procedure and function. Will add example later.

[jamie]

Yes but the issue is I need a way to know if the function is being used as a VOID return so I can decide to
modify the arguments if it is being used as a VOID return or simply define the RESULT only if the function's result is
expected.
 
 I have not found a way to indicate if the caller  is ignoring the RESULTS.

 I code these helpers using inline code and I can see even if I don't set the return value it looks like the
code is still being generated for a return ( unwanted code)

 I just found it ironic that the compiler does not flag a duplicate in the helper so this would lead me to believe that
the compiler knows the difference between a procedure and Function and it would only make sense for the compiler to
check for an equivalent call prototyped as a PROCEDURE if the call was voiding the return, and if there isn't, then the compiler
can simply use the Function if the optional extend syntax is on as a procedure.



 But i guess it would be ok If I knew how to determine the way the function is getting used, because then I could use a
inline case which the compiler seems to understand clearly.

 Thanks for the help, maybe something will popup.

[PascalDragon]

In Object Pascal overloaded routines are solely picked based on their arguments, not their result. What you're trying to do is simply not supported and we have no intention to change that.

[Thaddy]

In C and C++ it is the same case: you can not recognize void over any other argument result. In practice it is the exact equivalent of a procedure... A void (not a void *) is indetermined depending on your compiler. Never use it to "recognize" anything ......

[jamie]

ok, if that being the case then maybe the compiler should be fixed to not allow a procedure and function of the same in the
same scope., like the Helpers for example. Because currently I can do that and the compiler just ignores the second entry
without any warnings, code tools only see's the second entry but not the first which is what the compiler is using..

 Kind of a mixed up mess I guess.

[furious programming]

@Jamie: one of the following is a procedure, and one is a function:

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

1. A.SL(Count);
2. A.SL(Count);

Which one which? This code is compilable. The problem is that the compiler allows you not to use the function result. In this case, this is not a compiler (or language) problem. You are doing' this wrong, not in accordance with the language specification.

Do not be crazy with these helpers, because you'll write more code than the standard library contains.

[jamie]

I don't recall writing it that way?

B:= A.SL(1);   //Function.   A does not get changed but results is placed in B;

 or

A.SL(1);   //Procedure     A get's changed!

See the difference?
 
 For this to work correctly without dead code, the compiler needs to parse the two by which the caller is using it.

 Look, it's not a big deal but would nice if it would work, I don't see why the compiler can't figure this out ?

 But in any case, I guess if not for what I wish for the compiler should be fixed to reject a Procedure and Function of the
same name and arguments in the helper...

I will close this as not possible...

Thanks/

[reinerr]

I think it should be the job of the compiler optimization to not generate "dead" code.

What does your intended function look like in comparison to your procedure (what does SL actually do)? If its a shl then you're going to be differentiating between b := b shl x and Result := b shl x - i.e. the same thing (I guess it depends what your SL is going to be doing). You could check the generated assembly to see what the difference is.

But I think your point about the compiler allowing an overloaded method to exist with the same parameters (i.e. the function and procedure) is valid and should be a syntax error. The compiler wouldn't let me do it for an object - I don't use class helpers.

[Zoran]

ok, if that being the case then maybe the compiler should be fixed to not allow a procedure and function of the same in the
same scope.

Yes, I am very surprised that declaring two routines with same name and with same signature passes compilation.
However, I just tried, and it does! Isn't it a bug?

To be precise, when you declare two routines with same result type this is compile time error, but when they have different result types, the compilation passes.

So, I reported this -- bug 33604, so let's see there what will core developers say.

[furious programming]

@Zoran: similar behavior with the following case:

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

1. program Project1;
2.  
3. {$MODE OBJFPC}{$LONGSTRINGS ON}
4.  
5.   function TestFunc(N: Integer): Char;
6.   begin
7.     Write('TestFunc with Char as result');
8.     Result := Chr(N);
9.   end;
10.  
11.   function TestFunc(N: Integer): Integer;
12.   begin
13.     Write('TestFunc with Integer as result');
14.     Result := N;
15.   end;
16.  
17. begin
18.   TestFunc(2);
19. end.

Output:

Code: [Select]

TestFunc with Char as result
Two functions, same parameters, different result data type. No compile time errors, no hints, program works.