I agree. It's not much different from a private implementation detail being public by accident and then being changed to private.

If we all agree on just making them private, I can cook up a pull request.

Regards,
Alex

On Wed, May 2, 2012 at 1:42 AM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On Tuesday, May 01, 2012 22:54:43 Alex Rønne Petersen wrote:
> > How are we going to do this? It's not obvious in the documentation that std.concurrency imports these core modules at all anyway. Do we want a proper deprecation process or just private-ify the imports here and now?
>
> There isn't really a way to have a proper deprecation process with imports.
> The best that you can do is give a notice somewhere that they're going to
> be
> made private in the future and then later make them private. deprecate
> can't
> get involved at all AFAIK.
>
> Personally, I'd argue that as long as the fact that the imports are public
> isn't mentioned in the documentation, we might as well just make them
> private
> immediately.
>
> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

> There isn't really a way to have a proper deprecation process with imports.

We can create deprecated aliases for the relevant constructs.
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos