Algorithms should be free from rich types

[Dukc]

On Tuesday, 27 June 2023 at 21:53:59 UTC, Ali Çehreli wrote:
> The main topic here is about the harm caused by rich types 
> surrounding algorithms. Let's say I am interested in using an 
> open source algorithm that works with a memory area. (Not 
> related to D.) We all know that a memory area can be described 
> by a fat pointer like D's slices. So, that is what the 
> algorithm should take.
>
> Unfortunately, the poor little algorithm is not free to be 
> used: It is written to work with a custom type of that library; 
> let's call it MySlice, which is produced by MyMemoryMappedFile, 
> which is produced by MyFile, which is initialized only by types 
> like MyFilePath. (I may have gotten the relationships wrong 
> there.)
>
> But my data is already in a memory area that I own! How can I 
> call that algorithm? Should I write it to a file first and then 
> use those rich types to access the algorithm? That should not 
> be necessary...

The language-agnostic answer is to patch the library yourself to 
do what you want.

Since D is a systems programming language, you also have another 
choice: bypass the type system, create `MySlice` by pointer 
casting it from the data representing a D slice.

Now, neither of these solutions are exactly inviting. But they 
cannot be: to create `MySlice` in a way the library doesn't 
support, you have to know it's private implementation details. 
Even if the language didn't give the library author a way to 
protect those details, you'd be relying on undocumented 
version-specific details.

Not having `private` would better in the sense you'd be more 
likely to get compiler errors instead of memory corruption if the 
private details change. Maybe `__traits(getMember, /+...+/)`, or 
declaring a private function as external `extern(C)` function, 
CTFE-mangling the D name, would be safer than the pointer cast I 
proposed.