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