On Mon, 19 Dec 2011 14:43:07 +0200, Jakob Ovrum <jakobov...@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 <flybo...@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.
