Fix #2529: explicit protection package #3651

[Dmitry Olshansky via Digitalmars-d-announce]

On Tuesday, 19 August 2014 at 17:08:25 UTC, Walter Bright wrote:
> On 8/19/2014 7:01 AM, Dicebot wrote:
> > Walter, now that release is out can you please state your
> opinion about
> > https://github.com/D-Programming-Language/dmd/pull/3651 ? It
> is blocking Phobos
> > module split and decoupling.
>
> I keep thinking there's gotta be a way to do this without 
> language changes.

For what it's worth I don't care how things turn out w.r.t. 
syntax, language extension or convention but the problem must be 
solved.


The way I see the problem:

There must be nice and clean way to have internal stuff that is 
invisible for user. Preferably this stuff must not be monolithic 
and have form of package.

Example structure:
mod/package.d
mod/internal/bar.d
mod/...

I actually face it in Phobos right now, my blocked pull:
https://github.com/D-Programming-Language/phobos/pull/2412

Options:

1. Use current package attribute.
Disadvantages:
a) Must retain internals in the same package, user may still 
import them no problem at all. At least it does not do much harm 
as nothing is accessible.
b) Can't use std.mod.internal.bar 'package' stuff in std.mod 
(upper one). That makes it next to unusable. Basically it means 
we have to push internals up, instead of pushing them down.

2. Use separate public internal package.
Main disadvantage:
a) Now user may import and actually USE internal stuff.
b) Not only that but also internal methods of equally internal 
structs and classes leak out. In other words: a struct defined in 
internal module may never be exposed without some kind of 
wrapping. Ugly and unnecessary complication.


I'd rather have a language feature, but whatever you guys invent 
as 3rd option that doesn't suck will have my vote.


---
Dmitry Olshansky