Parameter passing oddities

[Nitorami]

When I call your example as "add (C1,C2,C1)", then C1 will be changed. The compiler cannot detect that, it does not know that two parameters are at the same address.

So I do change a const parameter.

The wiki says on constref (https://wiki.freepascal.org/Constref): "not only the parameter, but also the variable (...) passed by the caller (...) must not be changed until the call with the constref parameter has returned."

So - is that legal or not ?

[Thaddy]

Basically that is legal, because c1 is passed in and subsequently passed out in a different guise.. At the point of the calculation the first C1 is treated as const, but the result calculation that is passed out changes C1 in a legal way, since it is a store outside of the procedure itself.
const is confusing, but not that confusing.
Which is less disturbing than this:

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

1. var
2.   i:integer;
3. begin
4.   for i := 0 to 10 do
5.   begin
6.    writeln(i);
7.    inc(pinteger(@i)^);
8.   end;
9. end.

Which should be illegal, but isn't...
They are related, though.

[KodeZwerg]

When I call your example as "add (C1,C2,C1)", then C1 will be changed. The compiler cannot detect that, it does not know that two parameters are at the same address.

It depend on what C1 you talking about, the first stay unchanged the second, where the programmer chooses to write to, will be written to.
Dont you understand stand we turn in circles?
3 arguments, 3 variables, but just one where your method writes to.
So if you call Add(c1, c1, c1) what in your world of logic should happen? Are you now saying that it would write 3 times to c1 or do you finally accept my first given answer that the developer is in charge about what variable will be used as output and only the last c1 (variable c internal) is the one where the writing happen?

Add(
constref a: Integer; // this will be passed by reference to maybe do compare address with "c" -> unchangable
const b: Integer; // this will be passed by value, no checks beside for value are possible -> unchangable
out c: Integer; // this is passed by reference and its the only variable where you can write to -> changable
);

So the compiler knows, aha! Variable "c" is open to be modified, also the compiler knows that "a" and "b" are read-only.
If you think that Add(c1, c1, c1) would all be treated as "a" than you are total wrong.

So what did I told.....

If on the other hand you as developer call such method in a (a, b, a) way, then its upon you to decide if its smart or not.

[/quote]

[Thaddy]

That is what I wrote, but much more confusing.
Also this part is dubious:

So the compiler knows, aha! Variable "c" is open to be modified, also the compiler knows that "a" and "b" are read-only.
If you think that Add(c1, c1, c1) would all be treated as "a" than you are total wrong.

He is wrong, but you are too. It is what I wrote.

[KodeZwerg]

He is wrong, but you are too. It is what I wrote.

I do not agree you, whatever you meant to proof with your abstract example, I am right.
>> the developer is in charge what arguments he fill in for what purpose <<

[Thaddy]

Correct.

[Nitorami]

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

1. procedure add (constref a,b: integer; var c: integer);
2. begin
3.   c := a+b;
4.   writeln (a:8,b:8,c:8);
5. end;
6.  
7. var C1,C2,C3: integer;
8. begin
9.   C1 := 1;
10.   add (C1,8,C1);
11. end.

Output: 9 8 9

As expected. Inside the procedure, the compiler will think a should be constant, but it changes, because it has the same address as c. 
Of course it is the responsibility of the programmer to handle this correctly, I don't doubt this. My question was - is it legal to do this ?

Thaddy says yes, so I'll accept that and leave it at it.

[Nitorami]

Just for fun, I asked Microsoft's Copilot for its opinion. Here is the response.

Certainly! Let’s analyze the provided Pascal code:

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

1. procedure add(const a, b: integer; var c: integer);
2. begin
3.   c := a + b;
4. end;
5.  
6. var
7.   C1, C2, C3: integer;
8. begin
9.   add(C1, 8, C1);
10. end.

The code defines a procedure called add that takes two constant parameters (a and b) and one variable parameter (c). The procedure adds a and b and assigns the result to c.

However, there is an issue with the code. In Pascal, a constant parameter cannot be modified within the procedure. The line add(C1, 8, C1); attempts to modify the constant parameter C1, which is not allowed.

To fix this, you should either change the parameter c to be a variable parameter or avoid modifying C1 within the procedure.

[KodeZwerg]

Correct.

IKR. 

Thaddy says yes, so I'll accept that and leave it at it.

Cool that since 2 pages, where almost everyone told same, me included, gets ignored.

Just for fun

Ask your AI better questions, like in what relation are the arguments or what are your "legal" choices to play with them.
Ask your AI if should be forbid to write to a "var/out" variable.
Ask your AI for a demo that handle all your wishes, I am curious.

[Nitorami]

Kodezwerg, calm down, Mate. We're just having a chat here, your voice is heard, I don't know what gave you the impression that I don't listen. I'm having a job and need to travel a lot, and can't focus on the forum 100% of the time, and maybe that is the reason why my responses sometimes are not what you would expect. But trust me I hear what you say, and if you think that I don't understand, don't make it your problem. It's not worth it.

[PascalDragon]

But all that would not be necessary if there was a method of passing parameters which works like const but avoids the "constant" assumption. I don't know how other languages handle this. Just feel something is missing in Pascal.

Other languages have the same problems. var, out and constref in all cases as well as const depending on the ABI and the size involved are passed as pointers instead of copies to either faciliate the “modifyable” need or to improve performance (which is normally the case for const). Same is true in other languages. So as soon as pointers are involved (e.g. in C++ “const Complex&” for the input parameters and Complex& for the output) you'll have the same problem in any language.

However your specific example of Add(C1, C2, C1) is totally fine, cause you're only using A and B for the single assignment and thus you as a developer of the Add-routine can ensure that it works correctly. However if you'd do other stuff with the input parameters after the assignment to C inside your function that it would be your fault as the developer that your function isn't safe. Or if you'd modify some global variable inside your function that is in turn also passed in as a const-parameter (which is one of the main issues users experience in that context).