I don't have a particularly strong feeling here.

I confess I _was_ trying to subtly slide in the condition about where the export-should happen from. Exporting it from .Internals is probably the right direction in an idealized world from the standpoint of minimizing the exposure of users to the change and making it easier to update the API with a more sweeping design change in the future.

On the other hand, if that leads to a baroquely complicated patch because of, say, .Internals exporting other stuff that is used elsewhere in the package I'm more than happy to bend in the name of pragmatism.

-Edward

On Fri, Nov 28, 2014 at 7:48 AM, Ganesh Sittampalam <ganesh@earth.li> wrote:

There seems to be some confusion here.

Edward seems to be saying that it should only be exported from Internals:

On 26/11/2014 06:58, Edward Kmett wrote:
> FWIW- I have no problem with exporting anything you like from the
> `.Internals` module, especially if it is being exported form there
> rather than System.Process.
>
> Ultimately, that is what such modules are for, they can let you violate
> overly enthusiastic attempts at encapsulation until a better design can
> be locked in.
>
> So, +1.

Whereas Michael seems to be saying:

> 2. Let's not let such a discussion derail the possibility of a one-line patch
> which is very much backwards-compatible and simply avoids the need for people
> to reach for the .Internal module.

And his patch is exactly about exporting this from System.Process, not
from System.Process.Internals.

Am I missing something?

Ganesh