DI Generation Needs your Help!

Adam Wilson flyboynw at gmail.com
Mon Dec 19 16:15:51 PST 2011


On Mon, 19 Dec 2011 15:53:02 -0800, Jakob Ovrum <jakobovrum at gmail.com>  
wrote:

> On Monday, 19 December 2011 at 21:04:28 UTC, so wrote:
>> On Mon, 19 Dec 2011 22:24:18 +0200, Adam Wilson <flyboynw at gmail.com>  
>> wrote:
>>
>>> So the consensus is to keep all private members/imports/etc?
>>
>> Ideally to get most out of the auto generation of di files (by  
>> definition of module system) we need to strip ALL private stuff.
>> Only this way we can say the automation is on par with handcrafting.
>> But if it does not look doable somehow, we can always handcraft them  
>> (which i'll generally prefer),
>
> Private members can still be used from public templates and whatnot. You  
> can't take them out unless you can statically proved all references  
> within the same .di to that private member was removed in the stripping  
> process.

It sounds at this point we will just be leaving everything private in the  
DI files, sans implementations.

> foo.d
> ------
>
> private i = 42;
>
> // Is a public template, has to be left in
> void bar()()
> {
>     /* Uses 'i' */
> }
>
> void baz()
> {
>     /* Also uses 'i' */
> }
> ------
>
> foo.di
> ------
>
> void bar()()
> {
>     /* Still uses 'i', where did it go!? */
> }
>
> void baz(); // Fine, no longer need 'i'
> ------
>
> Also, on a side note, function parameters can use types from private  
> imports too. Be it function, data or import, it has to be left in even  
> if private.

This was discovered by drey_ on IRC and will be fixed by leaving all  
privates intact. I'll upload a patch to my git account this evening.

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/


More information about the Digitalmars-d mailing list