I agree. It's not much different from a private implementation detail being public by accident and then being changed to private.<div><br></div><div>If we all agree on just making them private, I can cook up a pull request.<br>
<div><br></div><div>Regards,</div><div>Alex<br><br><div class="gmail_quote">On Wed, May 2, 2012 at 1:42 AM, Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisProg@gmx.com" target="_blank">jmdavisProg@gmx.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tuesday, May 01, 2012 22:54:43 Alex Rønne Petersen wrote:<br>
> How are we going to do this? It's not obvious in the documentation that<br>
> std.concurrency imports these core modules at all anyway. Do we want a<br>
> proper deprecation process or just private-ify the imports here and now?<br>
<br>
</div>There isn't really a way to have a proper deprecation process with imports.<br>
The best that you can do is give a notice somewhere that they're going to be<br>
made private in the future and then later make them private. deprecate can't<br>
get involved at all AFAIK.<br>
<br>
Personally, I'd argue that as long as the fact that the imports are public<br>
isn't mentioned in the documentation, we might as well just make them private<br>
immediately.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Jonathan M Davis<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
phobos mailing list<br>
<a href="mailto:phobos@puremagic.com">phobos@puremagic.com</a><br>
<a href="http://lists.puremagic.com/mailman/listinfo/phobos" target="_blank">http://lists.puremagic.com/mailman/listinfo/phobos</a></div></div></blockquote></div><br></div></div>