Adding a new design constraint to D

[The Zealot]

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.