DIP16: Transparently substitute module with package

[deadalnix]

Le 05/04/2012 13:46, Steven Schveighoffer a écrit :
> I don't like this proposal, simply because this means one
> function/symbol per submodule. It should be more flexible than that. But
> I like the line of thinking.
>
> Let's re-examine the issue. We need to allow splitting of a module X.d
> into pieces for maintenance (or possibly accessibility -- disallowing
> friends). But we don't want to break code which currently uses FQN to
> access X's symbols.
>
> I think the following might work:
>
> algorithm.d:
>
> import this = std.algorithm_impl.sort;
>
> Which then imports std.algorithm_impl.sort, and effectively aliases all
> its symbols into algorithm.d. If std.algorithm_impl.sort defines a
> function called sort, then it's also aliased to std.algorithm.sort. In
> essence, sort has *two* FQN, but there are no FQN that refer to more
> than one symbol.
>
> I purposely left out the package.d idea because it's orthogonal to this.
>
> -Steve

The behavior you described has been proposed for public import, and have 
been discussed. This is interesting.

You propose an alternative syntax with is fine and have the advantage to 
not disturb already existing public imports, but have the drawback to 
create a new syntax, again.

If such a syntax is adopted, what would be the point of public imports ? 
If it is still useful, then your syntax is a better choice, otherwise, 
we'd better modify public import.