https://github.com/D-Programming-Language/dmd/pull/1961

Same as Issue 3603?

(In reply to comment #2)
> Same as Issue 3603?

No.

> Same as Issue 3603?

No, it's a variant of DIP 15. It'll make it so that you could do something like replace std/datetime.d with

std/datetime/common.d
std/datetime/interval.d
std/datetime/package.d
std/datetime/timepoint.d
std/datetime/timezone.d

and std/datetime/pakckage.d could then look something like

--------------
/++ Package documentation here +/
module std.datetime.package;

public import std.datetime.common;
public import std.datetime.interval;
public import std.datetime.timepoint;
public import std.datetime.timezone;
--------------

So, std.datetime could then be broken up and no code would break. It would also likely replace the all.d idiom that some people have been using to make it so that you can import an entire package at once, since it's basically all.d with compiler support. Even better, it also then gives us a way to document packages.

We discussed it with Andrei and Walter at dconf after Adam Wilson was complaining about the lack of this sort of ability in his talk, and we eventually got Andrei and Walter to agree to it.

(In reply to comment #4)
> --------------
> /++ Package documentation here +/
> module std.datetime.package;
> 
> public import std.datetime.common;
> public import std.datetime.interval;
> public import std.datetime.timepoint;
> public import std.datetime.timezone;
> --------------

I see. This is a good idea, but public import modules do have their bugs, e.g. the recently fixed Issue 9919. I've ran into a few others over the years.

(In reply to comment #5)
> 
> I see. This is a good idea, but public import modules do have their bugs, e.g.
> the recently fixed Issue 9919. I've ran into a few others over the years.

Bugs are just bugs, we will just have to fix them as they appear.

http://wiki.dlang.org/DIP37

https://github.com/D-Programming-Language/dmd/pull/2139

This has been implemented.