Why with allows assignment

[PascalDragon]

Delphi nowadays forbids changing fields of a record that is a return value of a function to matter if with is used or not. Older Delphi versions did not, just like older FPC versions or TP did not. FPC nowadays forbids it directly for the function result, but not yet if the function result is captured in a with-statement. But that is only because that is simply not implemented in FPC, because it requires explicit code to forbid this and doesn't stem from the language itself.

I just want to make sure I am interpreting the above corretly.

Does the above mean that FPC will "eventually" forbid "changing fields of a record that is a return value of a function to matter if with is used or not." ?

A "yes" answer would definitely be encouraging.

The answer is indeed yes. When is a different question however. 😅

I have no intention of re-igniting debates here, but I made a simple test, both with record and object. Both seem to work correctly.

This will stop working in the future, because the value returned by the functions (in your case GetRange and GetRangeObj) will only be temporary and won't propagate back to the original memory. So in that case one needs to explicitly capture the returned value in a variable and then use with. Users using this accidentally or wondering why it doesn't work the way they expect outweigh useful cases like this.

[dseligo]

This will stop working in the future, because the value returned by the functions (in your case GetRange and GetRangeObj) will only be temporary and won't propagate back to the original memory. So in that case one needs to explicitly capture the returned value in a variable and then use with. Users using this accidentally or wondering why it doesn't work the way they expect outweigh useful cases like this.

Will this also stop working in the future?

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

1.   with TfrmVIES.Create(nil) do
2.   try
3.     ShowModal;
4.   finally
5.     Release;
6.   end;

[jamie]

Have you ever heard the term "Bricking" / "Brick" ?

Jamie

[BrunoK]

Have you ever heard the term "Bricking" / "Brick" ?

Jamie

You mean as in https://en.wikipedia.org/wiki/Brick_(electronics) ?

If that's so, we need to make sure to never update to their trunk fantasies.

They are not even able to correctly multiply 2 currency values togehter correctly ...

[TBMan]

Speaking of readability: please use [code=pascal][/code] to improve readabililty and to avoid the forum software interpreting the code.

The forum software is a compiler that will run code in a post?

[440bx]

The answer is indeed yes. When is a different question however. 😅

It's good to know assigning a result to a function outside the function itself will eventually be disallowed.

Of course, the sooner the better but, as you said, that's a different issue/question.

[jamie]

Have you ever heard the term "Bricking" / "Brick" ?

Jamie

You mean as in https://en.wikipedia.org/wiki/Brick_(electronics) ?

If that's so, we need to make sure to never update to their trunk fantasies.

They are not even able to correctly multiply 2 currency values togehter correctly ...

Some people aren't happy unless they can break something. With changes comes unintended behaviors and years to fix.

 You have some old timers that would rather copy and paste the same line over and over to get to multiple deep properties, it boosts their ego of total size of source files they create in a project.

Jamie

[dbannon]

PascalDragon, I confess I have not followed this thread closely because of the unpleasantness exhibited. But I do use TestOne below and would like you to assure me it is future safe.

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

1. program Project1;
2. {$mode objfpc}
3.  
4. type
5.     TaRec = record
6.         TheInt : integer;
7.         TheString : string;
8.     end;
9.      
10. function Test() : TaRec;
11. begin
12.     result.TheInt := 42;
13.     result.TheString := 'FortyTwo';
14. end;
15.    
16. var
17.         aRec : TaRec;
18. begin
19.     aRec := Test();          // Test One
20.     WriteLn('Test One TheInt ', aRec.TheInt);
21.     writeln('Test One TheString ', aRec.TheString);
22.  
23.     with Test() do begin     // Test Two
24.         WriteLn('Test Two TheInt ', TheInt);
25.         writeln('Test Two TheString ', TheString);
26.     end;
27. end.

Thanks,
Davo

[440bx]

@dbannon,

I know you didn't ask me but, Test One should most definitely keep working.  There is no reason why it should not.

I believe Test Two will keep working as well but, for that one I believe the documentation should be very detailed as to _how_ it works.  Any details PascalDragon can offer about how it works would definitely be most welcome.

What will eventually stop working, which currently works, is to assign a value _in the scope of the "with"_ to the function's result.  That will eventually not work (PascalDragon stated that much in his posts above.)

ETA:

Added the qualifier "in the scope of the "with""

[jamie]

yeah well, I have a rather large app that I was able to get fpc to compile that uses lots of code like this.

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

1.  
2.   with GetNodeByIndex(1{one for now}) do
3.   begin
4.     NormalizeValues;
5.     if X = -1 then X := Adefault; //Constant for now but changes.
6.     if Y = -1 then Y := ADefault; //Place Null nodes to a common place.
7.     if Z = -1 then Z := ADefault;
8.     ProcessNode;
9.     // more code after this.
10.   end;                                              
11.  
12.  

That function GetNodeByIndex returns a Record, in Delphi mode to get advanced records and as you can see, I have procedures, and I do change the values within.
That does not mean they get changed in the original source, they don't.

 But it appears to be too much for some to handle, what a shame, or should I say sham.

Jamie

[440bx]

That does not mean they get changed in the original source, they don't.

Semantically, that code you posted shows that the values returned by the function are being changed.  That's what that code means and that is not only wrong, it is non-sensical not to mention mathematically appalling.

You want to do that kind of stuff then do it right, assign the function's result to a temporary variable.  Since the temporary variable is NOT the function's result (only a copy of its values) you can do whatever you want with it.

Declaring a variable to hold a function's result isn't a big deal nor a whole lot of work and, the explicit assignment to the temporary makes the code's intent explicit and thus a lot clearer.

[jamie]

The blind leading the blind. The destroyer of clean and easy syntax and bloat generator.

Have a good day, I've had enough of this non-sense.

Jamie

[alpine]

The blind leading the blind. The destroyer of clean and easy syntax and bloat generator.

+1

I don't see anything wrong with functions returning a temporary record result, the case when it is a property accessor maybe is the only case in which assigning the field doesn't bring the desired side effect. But then that's what functions are for - (ideally) to be side-effect free. They (Delphi) could have made it a warning instead of an error, or at least checked for the particular case. They chose the easy way.

[440bx]

The blind leading the blind. The destroyer of clean and easy syntax and bloat generator.

Have a good day, I've had enough of this non-sense.

Jamie

It's more like "the blind ignorants are whining about the future loss of their defective toy".... awwww... poor things!

Have all a wonderful day... enjoy your non-sense and ignorance, don't forget to feel miserable about the future loss of your toy. 

[jamie]

neo luddism.