`restricted` member variables

[forkit]

On Thursday, 23 June 2022 at 04:34:03 UTC, Mike Parker wrote:
>
> ...
> Yes, it's true that the class boundary is violated in the 
> module.

Oh. you just said it better than I ;-)

'the class boundary is violated in the module'.

D's claim to fame. I'm sure that will attract all those millions 
of OOP out there. They'll be banging down your door to get in, so 
they can start using D.

> But because the module is part of the private API, that doesn't 
> matter one bit.

Umm. If it's not in the api of my class, then it shouldn't be in 
the api of my class.

Don't force your own api into my class. On what basis should i 
accept that?

Not only has the D module redefined the concept of a strong 
abstract data type, it's also trying to redefine the very basis 
of OOP (a strong abstract data type).

btw. Why won't the module let me put "wtf" into an int?

Oh. cause built in types are strongly typed. the compiler ensures 
its invariants are upheld. but your user-defined types do not get 
that privledge in D.

You can call it ideological, philosophical, or whatever, but I 
just cannot accept it.

A language that I use (outside of playing with it), must support 
the concept of a strong abstract data type. offering of a 
constraining workaround just to simulate one, is absurd.