Is defining get/set methods for every field overkill?

On Wednesday, 23 November 2022 at 09:51:46 UTC, FeepingCreature 
wrote:
>
> The module is the capsule. D is simply not interested in 
> building a capsule around a class. D does not let "anyone" pass 
> through, it lets "anyone in the module" pass through, because 
> the module is the wall. I think this is a stronger concept of 
> encapsulation than C++ friends because the encapsulation is 
> lexical rather than just declarative.

But if I write a class specification, then that class will be its 
own capsule.

It will be its own type, just like a built in type.

It will have its own interface by which other code can interact 
with it, just like a built in type.

Why then should a programming language insist that all other code 
in the module should be able to bypass my specification, and do 
as it pleases to my type?

If this applied to built in types, imagine the chaos that could 
follow from that.

Well, the class is a type as well.

I struggle to see how treating other code in the module as though 
it is a part of the specification of my type (ie. all that code 
is essentially inside the perimeter of my class type), benefits 
me as software engineer.

I am surely missing something here.

In C++, if I want another type to interact with my type, in a 
tightly coupled manner, then I can explicately authorise that 
interaction very easily, using friend. Now when I see my code, or 
others read my code, they know intent.

In a D module, intent cannot be discovered so easily, since it 
cannot be explicately declared. Not even the compiler knows your 
intent. It can only assume everything you typed in the module is 
correct. And now your counter class overflows...and boom!