[fpc-devel] Feedback please - semantics of private vs strict private

[Martin Frb]

I started a proposal to add strict private/protected to DWARF.

If I could have some thoughts on the below question please.

If I understand that correct, the idea may be to add DW_VIS_local / 
DW_VIS_exported in addition to DW_ACCESS_private.
And this would indicate if a private symbol can be seen within its 
containing unit. (same for protected)


1) from a language design point: how fitting is this?

2) Is this complete, as in: No "side effect" of "strict" is being 
overlooked? (strict really only affects code of the same unit, that is 
outside the class and its decendents / no decendent is affected, not in, 
nor outside the unit)

-------- Forwarded Message --------
Subject: 	Re: New Issue: Accessibility Declarations for FreePascal

	

	

	

	



Hey Martin,

We have been discussing your request for new Accessibility Declarations 
for Free Pascal. https://dwarfstd.org/issues/260428.1.html

If you look at the latest version of the draft standard 
https://snapshots.sourceware.org/dwarfstd/dwarf-spec/2026-09-20_22-49_1789944541/dwarf6-20260920-2248.pdf 
on page 30 there are two sections very close to each other. 
Accessibility of Declarations and Visibility of Declarations and it 
needs to be understood that the second one does not refer to ELF symbol 
visibility it is language level visibility.

When we refer to your language 
https://www.freepascal.org/docs-html/ref/refse35.html specification it 
talks about


--class visibility 
specifier-------------private------------------------- |-strict-| 
-protected--|| |-------public---------| -------published -------

And so it specifies "class visibility specifier". So we are trying to 
figure out if FreePascal should use visibility rather than or in 
addition to Accessibility of Declarations. The problem is I don't think 
any of us are really well versed in FreePascal or the old Delphi and 
Borland TurboPascal and the language semantics of those compilers to be 
able to really be able to know what the intent is for sure.

So far what we have kind of decided that strict private and strict 
protected map more closely to  DW_ACCESS_private and DW_ACCESS_protected 
since they are conceptually closer to C++'s private and protected.

Then in my draft we have added DW_ACCESS_module_private and 
DW_ACCESS_module_protected but is that actually more like 
DW_ACCESS_public with DW_VIS_local. Would you be able to shed some light 
on the matter with regards to how Delphi and now FreePascal understand 
the visibility and accessability question. I'm sorry, while there are a 
few of us who have some Familiariaty with Modula 2 but it is a distant 
recollection from University and I don't think any of us have any 
experience with the later evolution of Pascal and so we are all a bit 
confused by this.

-ben

On 4/28/26 10:37 AM, Ben Woodard wrote:
>
> Cary, this references the DWARF discussion "Additional values for 
> DW_AT_accessibility" recently on DWARF-discuss. If this actually needs 
> a champion, I'll champion it. Super simple, add a couple of defines. 
> Like the recent errata, I feel like it is a wave-through.
>
> ---------------------------------
>
> Issue:
>
> DWARF5 only has Accessibility declarations DW_ACCESS_public 
> DW_ACCESS_private and DW_ACCESS_protecte. However, FreePascal has a 
> couple more that need to be represented. This is needed so that 
> debuggers can report it back to users and so that ABI checkers like 
> libabigail can detect changes to the API which would then change the 
> ABI of an object.
>
> The full list can be found at: 
> https://www.freepascal.org/docs-html/ref/refse35.html
>
> Proposal:
>
> In Section 2.7 in Table 2.4 Add two more accessibility codes: 
> DW_ACCESS_strict_private and DW_ACCESS_strict_protected.
>
> In Section 8.9 in Table 8.14 Add the following entries to table 8.14:
>
> Accessibility code name 	Value
> DW_ACCESS_strict_private 	TBD
> DW_ACCESS_strict_protected 	TBD
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20261013/49b49a93/attachment.htm>