On Monday, 5 November 2018 at 05:55:02 UTC, unprotected-entity
wrote:
On Saturday, 3 November 2018 at 21:28:22 UTC, Stanislav Blinov
wrote:
The only difference is that `func` became a member function.
And now what? You can just as easily "forget" what's in your
struct/class as in your whole module.
ok. Now, what are your options then (assuming you want an
independent type)?
(option 1) define one encapsulated type, per module.
(option 2) have a means for type independence within a module -
i.e. selective hiding.
Option 3 - don't access private state unless you intend to.
That's literally how you write implementations, in pretty much
any language that has access modifiers.
D only gives you one choice here, not two.
Nope. You can have a type spanning several modules. That's what
packages do, among other things.
I would say, that your response backs up my argument, that is,
a second option might actually be worthwhile. perhaps,
something like: __private
No, it really doesn't. Your argument was that the programmer
might accidentally forget, and I've shown quite clearly that no
keyword is going to protect them from that. If you can forget in
module scope, you can forget in class scope. There can be only
one solution: don't forget. As in: stop inventing imaginary
examples. People, in practice, don't "accidentally" modify the
guts of their own types. That horse is quite dead, I'm afraid.
(now __private is everything private already is, but
additionally, its private outside the scope of the type
declaring it, and now, you'd get a compile time guarantee of
correctness - e.g. if you accidently tried to ignore that types
independence.
No, you do not. You still have that same "problem" inside the
type's definition.
It's call 'type encapsulation' ;-)
If you're afraid of implicit conversions, define your own type
that disallows them, problem solved. Has nothing to do with
private. That is what's called 'type encapsulation'.
