Private property of a Generic Type

[Okoba]

I have codes like this that worked just find until recent versions, but current Trunk says "unit1.pas(22,5) Error: Identifier idents no member "A""
Why? And what can I do to fix it? I do not want to expose these fields.

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

1. program Project1;
2.  
3. {$mode Delphi}
4.  
5. uses
6.   unit1;
7.  
8. var
9.   V: TTest<Integer>;
10. begin
11.   Inc<Integer>(V);
12.   ReadLn;
13. end.

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

1. unit Unit1;
2.  
3. {$mode Delphi}
4.  
5. interface
6.  
7. type
8.   TTest<T> = record
9.   private
10.     A: T;
11.   end;
12.  
13. procedure Inc<T>(var v: TTest<T>);
14.  
15. implementation
16.  
17. procedure Inc<T>(var v: TTest<T>);
18. begin
19.   V.A += 1; //Error!
20. end;
21.  
22. end.

[ASerge]

...until recent versions...

Which?

[TRon]

I assume Okoba meant 3.2.2 ASerge.

Code: [Select]

fpc -B project1.pas
Free Pascal Compiler version 3.2.2 [2021/05/16] for x86_64
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling project1.pas
Compiling unit1.pas
unit1.pas(10,9) Note: Private field "<record type>.A" is never used
Linking project1
35 lines compiled, 0.0 sec
1 note(s) issued
Note the irony 

My most recent trunk is apparently too old as 3.3.1 compiles the project for me as well.

Compilation with brand new trunk:

Code: [Select]

$ fpc-trunk -B project1.pas
Free Pascal Compiler version 3.3.1 [2024/02/26] for x86_64
Copyright (c) 1993-2024 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling project1.pas
Compiling unit1.pas
unit1.pas(10,9) Note: Private field "<record type>.A" is never used
unit1.pas(19,9) Error: Identifier idents no member "A"
project1.pas(14) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Error: /media/ramdisk/fpc/3.3.1/bin/ppcx64 returned an error exitcode


[Okoba]

@ASerge I dont know. What I know is until 2024-02-02 it is working but when I get the latest trunk I get this error.

[zamtmn]

Yes, they closed the loophole. It's just not clear why you should try to hide everything, it's often not justified((
I used write access to container data, now it's not allowed and I need to add it to the rtl code
https://gitlab.com/freepascal.org/fpc/source/-/issues/40656
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/593

[Okoba]

No not privatizing all properties, it was just a demo to show the problem.
Imagine this:

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

1. type
2.   TTest<T> = record
3.     B: Integer;
4.     X: String;
5.   private
6.     MyPrivateValueToHandle: T;
7.   end;
8.  
9. procedure Inc<T>(var v: TTest<T>);
10.  
11. implementation
12.  
13. procedure Inc<T>(var v: TTest<T>);
14. begin
15.   V.MyPrivateValueToHandle += 1; //Error!
16. end;
17.  
18. end.      

There are values that you don't want outside can handle, or even IDE suggest it in code suggestion.

And it is not consistent and logical that a function has no access to a property in the same unit. Even if we say the type was specialized in the program, the Add function was specialized there too, so both should see each other.

[Martin_fr]

Yes, they closed the loophole. It's just not clear why you should try to hide everything, it's often not justified((

That "close the loophole" did go to strict on a couple of other constructs too.

It is quite possible that this too, is a bug. I suggest to report it, and wait.

[Okoba]

I reported the issue: https://gitlab.com/freepascal.org/fpc/source/-/issues/40670

[Thaddy]

side note:
This line  V.MyPrivateValueToHandle += 1; //Error!.
makes an assumption that T is an ordinal which we can not yet write as a restriction. Like procedure test<T:ordinal>(); // makes the code safer because T can now only specialize as ordinal.
This kind of type restriction seems on the todo list and has been discussed.
So technically speaking it is currently a bug in your example, the assumption, that is.
I know it is only to demo, but just in case.

[Okoba]

I know that Thaddy and I am looking forward to the feature, but for now and this sample, the point is accessing private properties form the same unit.

[PascalDragon]

So technically speaking it is currently a bug in your example, the assumption, that is.

It's not a bug, because in FPC the most type checking only happens at the specialization time (like with C++) while in Delphi all needs to be fine at the time the generic is defined. FPC's generics are more flexible than Delphi's in that regard.

[Thaddy]

I wrote about his assumption and both of our wish: <T:ordinal>