Why?

Hipreme msnmancini at hotmail.com
Thu Apr 4 13:15:50 UTC 2024


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:
>>> On Thursday, 4 April 2024 at 10:18:10 UTC, Richard (Rikki) 
>>> Andrew Cattermole wrote:
>>>> On 04/04/2024 10:55 PM, Paolo Invernizzi wrote:
>>>>> https://github.com/dlang/dmd/pull/16348
>>>>>
>>>>> *sigh*
>>>>>
>>>>> /P
>>>>
>>>> I can certainly see it being used with shared libraries.
>>> 
>>> If you mean shared code for libraries, I don't see how. Isn't 
>>> dub the *official* tool to use for library? What's the 
>>> problem in revamping the way dub download / organise / handle 
>>> source distributions?
>>
>> 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.


More information about the Digitalmars-d mailing list