On Tuesday, 14 June 2022 at 12:19:40 UTC, Mike Parker wrote:
> On Tuesday, 14 June 2022 at 10:50:56 UTC, bauss wrote:
>
>> No you really can't and I already proved that with a couple examples in the other discussions on this topic; there are situations where you cannot do that, such as accessing private fields on a parent class using a sub class type within the parent class' module.
>
> And Paul did show you how to do that with `child.Foo._c`.

Which is a pointless thing to say, you are still violating the subtyping relationship.

On Tuesday, 14 June 2022 at 12:19:40 UTC, Mike Parker wrote:
> On Tuesday, 14 June 2022 at 10:50:56 UTC, bauss wrote:
>
>> No you really can't and I already proved that with a couple examples in the other discussions on this topic; there are situations where you cannot do that, such as accessing private fields on a parent class using a sub class type within the parent class' module.
>
> And Paul did show you how to do that with `child.Foo._c`.

Not in a legal way.

On Tuesday, 14 June 2022 at 12:35:24 UTC, bauss wrote:
> On Tuesday, 14 June 2022 at 12:19:40 UTC, Mike Parker wrote:
>> And Paul did show you how to do that with `child.Foo._c`.
>
> Not in a legal way.

What do you mean?

On Tuesday, 14 June 2022 at 12:09:57 UTC, bauss wrote:
> On Tuesday, 14 June 2022 at 11:04:55 UTC, The Zealot wrote:
>> On Tuesday, 14 June 2022 at 10:50:56 UTC, bauss wrote:
>>> On Tuesday, 14 June 2022 at 10:21:34 UTC, The Zealot wrote:
>>>>
>>>> a) put the class in it's own module.
>>>>
>>>
>>> No you really can't and I already proved that with a couple examples in the other discussions on this topic; there are situations where you cannot do that, such as accessing private fields on a parent class using a sub class type within the parent class' module.
>>>
>>> That's why the module-level private is a lie in D or at least incomplete.
>>
>> The code you posted works exactly as it should. your function void handle(Bar child) does access the class Bar of another module, and the members of foo are not accessible.
>> and you can implement the desired behaviour like this:
>>
>> import b;
>> void handle(Bar child) if(isDerivedFrom!(Foo, Bar))
>> {
>>   (cast(Foo)child)._c += child.c;
>> }
>
> No it does not. You should never have to cast to a parent type, NEVER!
>
> That is a red flag if you have to do that, a major one at that.

no this is actually perfectly fine, as the code ensures at compiletime that Bar is in fact a subtype of Foo, so the cast is always valid. You have to be explicit that you actually want to use Foo's _c; or else adding a _c variable to Bar silently changes the behaviour of your code. This works as intended.

>>> import b;
>>> void handle(Bar child) if(isDerivedFrom!(Foo, Bar))
>>> {
>>>   (cast(Foo)child)._c += child.c;
>>> }
>>
>> No it does not. You should never have to cast to a parent type, NEVER!
>>
>> That is a red flag if you have to do that, a major one at that.
>
> no this is actually perfectly fine, as the code ensures at compiletime that Bar is in fact a subtype of Foo, so the cast is always valid. You have to be explicit that you actually want to use Foo's _c; or else adding a _c variable to Bar silently changes the behaviour of your code. This works as intended.

and just to be clear, you don't even need to do it with an explicit cast.
All you have to do is access _c through a baseclass pointer.