Algorithms should be free from rich types

[Steven Schveighoffer]

On 7/3/23 3:57 AM, Atila Neves wrote:
> On Friday, 30 June 2023 at 14:41:00 UTC, bachmeier wrote:
>> 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.

That is the issue. For instance, if you do:

```d
libFunction(cast(int *)0xdeadbeef);
```

And then complain that `libFunction`'s author didn't handle that case, 
you can rightfully be told to RTFM.

Same thing with circumventing private. It should be *possible*, but 
absolutely unsupported.

>> 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.

The definition of `private` shouldn't change at all. The ability to 
circumvent it still should remain for those wanting to muck with 
internal data, and I don't think there's any way to get around that 
(there's always reinterpret casting). The thing is, it's important to 
identify the *consequences* of changing private data -- it can *never* 
be within spec for a library to allow private data access.

So one can muck around with private data, and pay the cost of zero 
support (and rightfully so). Or one can petition the library author to 
provide access to that private data.

-Steve