Algorithms should be free from rich types

[FeepingCreature]

On Tuesday, 27 June 2023 at 21:53:59 UTC, Ali Çehreli wrote:
> My mind is not fully clear on this topic yet but some related 
> things have been brewing in me for years.
>
> First, an aside: You may remember my minor complaint about 
> 'private' during a DConf presentation years ago. Today, I feel 
> even stronger that disallowing access to parts of software 
> "just because" of good design is a mistake. I've seen multiple 
> examples of this in professional life where a developer uses 
> 'private' only because it is "of course" better to do so. (The 
> Turkish word "işgüzar" and the German word "verschlimmbessern" 
> describe the situation pretty well for me but the English 
> language lacks such a word.)
>
> To give an example from D's ecosystem, the D runtime's garbage 
> collector statistics object used to be 'private'. (I think 
> there is an interface for it now.) What an inconvenience it was 
> to copy/paste that type's definition from the runtime to user 
> code, get the compiled symbol of the object from the library, 
> and pointer cast it to be able to access the members! A 'static 
> assert' attempts to protect the project from changes to that 
> type...
>
> The idea of 'private' should be to just give the developer 
> freedom to change the implementation in the future. It should 
> not impede use cases that people come up with. That can be 
> achieved practically with an underscore: Make everything 
> 'public' and name your implementation details with an 
> underscore. People who need them will surely know they are 
> implementation details that can change in the future but they 
> will be happy: They will get things done.
>

I like this approach:

```
class C {
     private int i;
}
...
void main() @system {
     auto c = new C;
     c.private.i = 5;
}
```