DI Generation Needs your Help!

[so]

On Mon, 19 Dec 2011 14:43:07 +0200, Jakob Ovrum <jakobovrum at gmail.com>  
wrote:

> On Monday, 19 December 2011 at 12:11:32 UTC, so wrote:
>> On Mon, 19 Dec 2011 10:11:25 +0200, Adam Wilson <flyboynw at gmail.com>  
>> wrote:
>>
>>> Everything else is left alone. Templates and mixins are not addressed  
>>> with this code and *should* not be modified. That's where I need your  
>>> help, the test cases I have written cover some basic scenarios but I  
>>> don't have the capability to test these changes with the diverse code  
>>> base that the community has created.
>>
>> I am not exactly sure about your problem with templates and mixins but  
>> i'll give it a try regardless :)
>> Since with templates there is no distinction between definition and  
>> decleration,
>> exposing them IMO should be solely based on thier module access  
>> signatures.
>>
>> private struct A() // hide
>> public struct B()  // expose
>>
>> Now if B or some another exposed structure in ".di" should call A,
>> compiler will take care of it by outputting an error as usual.
>
> And if the public template tries to access the private one?
>
> Private module members must be treated like any other unless the  
> compiler can prove it removed all references to the private member.

You are right it was obscure, i'll try to clarify.
By "B or some another exposed structure" i meant things resides  
"completely" in ".di" file.
Things like Templates, mixins and if we get them one day inlined functions.
In this scenario a "original.d" file should be interpreted as:

original.d
   public void A()()
   private void B()()

whatitwasmeant.di
   public void A()()

whatitwasmeant.d
   private void B()()

Here B can call A but not the opposite.
A simple doesn't see B here. Things that resides completely in ".di" file  
have no way to access the things in its ".d" file unless it wasn't  
"exported".
Imagine the final/generated ".di" file IS the user and the original ".d"  
file is the library designer. While i think this is the right way, it  
probably not that easy to implement.