On Fri, 06 Apr 2012 20:25:23 -0400, Jonathan M Davis <jmdavisp...@gmx.com>
wrote:
DIP15 doesn't fix the explicit path problem though. You can't change
std/algorithm.d into std/algorithm/ (with sorting.d, search.d, etc.)
without
breaking code. You could make std/algorithm.d publicly import std/alg/*
and
then DIP15 would allow you to import std.alg to get all of its
sub-modules,
but you're still forced to use a module to publicly import symbols as
part of
a migration path, and you can't split a module in place.
I think either you or I am missing something.
In DIP15, if you define std/algorithm/_.d, and then import std.algorithm,
it imports std/algorithm/_.d, which then 1. publicly imports other
modules, and 2. aliases symbols to the name std.algorithm.symbol. At
least, this is how I understand the intent. It seems equivalent to me to
the package.d proposal, it's just using _.d instead of package.d.
If you import std.algorithm.sorting, and try and use std.algorithm.sort,
yes it will not work. But this does not break existing code (which does
not import std.algorithm.sorting), and I find it odd that we want to make
std.algorithm.sort work if you don't import std.algorithm.
-Steve
