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.
