On Monday, 13 June 2022 at 09:12:47 UTC, user1234 wrote:

{$MODE OBJFPC}{$H+}
{$MODESWITCH ADVANCEDRECORDS}
type TS = record
  private
    a: integer;
  strict private
    b: integer;
end;

var
 s: TS;

begin
  s.a := 1; // OK
  s.b := 1; // NG
end.

You should have used compiler explorer. :)

https://godbolt.org/z/6M7be7M57

On Monday, 13 June 2022 at 10:44:43 UTC, bauss wrote:

And I'm arguing that this is exactly what we should expect from private-to-the-module, since B is not declared in the same module as the superclass, so it's neither unfinished nor a bug.

On Monday, 13 June 2022 at 10:49:37 UTC, Paulo Pinto wrote:

{$MODE OBJFPC}{$H+}
{$MODESWITCH ADVANCEDRECORDS}
type TS = record
  private
    a: integer;
  strict private
    b: integer;
end;

var
 s: TS;

begin
  s.a := 1; // OK
  s.b := 1; // NG
end.

nice, even highlighting of "strict private" is correct there.
one more kudo for compiler explorer.

On Monday, 13 June 2022 at 10:51:10 UTC, Mike Parker wrote:

It breaks the sub-typing requirement.

If you get more access by recasting a pointer to the super-type then the sub-typing relation cannot be satisfied.

Hence, it is certainly broken. If it is not a bug, then it is broken by design. Which is no better.

On Monday, 13 June 2022 at 10:55:36 UTC, Ola Fosheim Grøstad wrote:

Or to explain it in simple terms:

A cast to a supertype should only imply additional restrictions.

In this case the opposite happens. So this aspect of the type system is broken.

On Monday, 13 June 2022 at 11:00:17 UTC, Ola Fosheim Grøstad wrote:

Or perhaps this formulation is less confusing:

A cast to a superclass is an act of forgetfulness

Being forgetful should not enable you do do more. The less you know, the less you should be able to do. The more you know, the more you should be able to do.

On Monday, 13 June 2022 at 10:51:10 UTC, Mike Parker wrote:

Now THIS is why D is unpopular. It is a unfinished or a bug, while the people maintaining it say it isn't.

Take the source code from the original post: https://forum.dlang.org/post/yyurtzlglypsvgizxodg@forum.dlang.org

import b;
void handle(Bar child)
{
    child.Foo._c += child.c; // works
    child._c     += child.c; // error no property _c
}

Both work, you can access _c through child and it is a also private and can't be accessed through child. So which is it? Is this what you define as "working" as intended?

It's the name of the language ;-)

Try to find "D". You will get a long list of results from everything and everyone.
Renaming to something like would DFutureC help.

Regards, Ozan

On Monday, 13 June 2022 at 10:55:36 UTC, Ola Fosheim Grøstad wrote:

And the reason is the private member of the class shouldn't be accessible outside its declaration scope in the first place. Module-level 'private' is dysfunctional by design.

On Monday, 13 June 2022 at 12:03:10 UTC, Max Samukha wrote:

No! We don't need encapsulation!
We are all friends.
Your variable, I will use it if I want to!You should happy however I use it,we are friends!