Why?

[Paolo Invernizzi]

On Thursday, 4 April 2024 at 13:15:50 UTC, Hipreme wrote:
> On Thursday, 4 April 2024 at 12:27:00 UTC, Paolo Invernizzi 
> wrote:
>> On Thursday, 4 April 2024 at 11:10:04 UTC, Richard (Rikki) 
>> Andrew Cattermole wrote:
>>>
>>> On 05/04/2024 12:07 AM, Paolo Invernizzi wrote:
>>>> [...]
>>>
>>> No I meant shared libraries.
>>>
>>> Specifically the distribution of the source files that act as 
>>> the interface to it.
>>>
>>> That way you have the .sar file and the .dll and that's 
>>> everything you need to use it.
>>
>> Aren't 'di' sources the target solution for library API? 
>> What's the problem in distributing a zip or tar?
>>
>> In C++ you usually have a specific "include" directory with 
>> all you need, what's the burden in doing a zip with the shared 
>> library binary and the 'di' directories?
>>
>> /P
>
> The .di feature is a big flop of D. They are nearly useless, 
> their generation is dumb since no code analysis is done for 
> removing useless imports. It should analyze the code and: check 
> if the type import is used or not. Also, public imports are 
> always kept.
> There's no reason nowadays to use auto DI generation. One must 
> either completely ignore this feature or just create their own 
> DI files.

Let's put aside the implementation of the automatic way to 
generate '.di', and rephrase:
Are .di intended to be the correct way to expose _public_ API of 
an opaque library binary?

What's the problem SAR targets to solve that a package manager 
can't solve? Why D needs it?