Algorithms should be free from rich types

[Atila Neves]

On Friday, 30 June 2023 at 14:41:00 UTC, bachmeier wrote:
> On Friday, 30 June 2023 at 11:07:33 UTC, Atila Neves wrote:
>
>> API design is indeed hard. Which makes it all the more 
>> imperative to not accidentally design one with implementation 
>> details that users downstream start depending on. That is: API 
>> design needs to be a conscious opt-in decision and not "I 
>> guess I didn't think about the consequences of leaving the 
>> door to my flat open all the time and now there are people 
>> camping in my living room".
>
> Private is more like locking everyone else's doors for their 
> own safety.

I don't see how - it only applies to your own code, adding 
private doesn't make someone else's code no longer accessible.

> In the cases that it keeps an intruder out, it was helpful to 
> them. When grandma had to sleep on the sidewalk, not so much.

This is where the analogy breaks down. The whole point of private 
is to make a conscious choice over what is an implementation 
detail and what is part of the API. If it's the default, the 
programmer is nudged towards thinking of a good API instead of it 
being ad-hoc.

> I should have the option to override those decisions.

As a library author, I don't think you should. It's on me to 
support usage of private functions that I'm nominally allowed to 
delete, but not really if someone is going to complain.

> If something blows up, or if my code gets broken in the future, 
> it's my fault, because I was the one that made that decision.

In theory, yes. In practice, yelling. We told people that `in` 
was in flux and because of that, to not use it. People (including 
me!) did it anyway. Some of them later complained when we decided 
what to do with it.