Jacob Carlborg wrote:
> On 2013-03-22 13:34, Dicebot wrote:
> 
> >Yes, but C header translations are not D and should try to mimic behavior that is translated. In C there are no non-public includes, so it sounds pretty natural. Unless root module itself is not imported publically, this should not created any problems for user code.
> 
> BTW, I think it's bad style in C to depend on public includes in general. It do have it's uses cases just as public imports have in D.

Any ideas on how to express this in the documentation?

Jens

On 2013-03-22 15:26, Jens Mueller wrote:

> Any ideas on how to express this in the documentation?

Just say something like: "Avoid public imports as much as possible. This might result in additional imports are needed, without any corresponding C include.".

-- 
/Jacob Carlborg

Jacob Carlborg wrote:
> On 2013-03-22 11:53, Jens Mueller wrote:
> 
> >True. But shouldn't you fix those things as follows:
> >
> >module deimos.a;
> >int a;
> >
> >(BTW Probably we should add shared here?)
> 
> __gshared.

Yes. I should add a section about globals.

> >module deimos.b;
> >public import deimos.a; // shouldn't this fix the problem
> >
> >Does this work?
> >Should I add text about when to use public imports?
> 
> It would work but I think this is bad practice. I would hate that to happened with every C binding. I love that D imports are _not_ public.

Do you want a strict decision here? Because we have two options for those cases a) add more than one import and b) make some imports public. I'm leaning towards b.

Jens

On 2013-03-22 15:47, Jens Mueller wrote:

> Do you want a strict decision here? Because we have two options for
> those cases a) add more than one import and b) make some imports public.
> I'm leaning towards b.

Definitely A.

-- 
/Jacob Carlborg