Untie Win32 from bytestring about win32 HOT 3 CLOSED

Hi,

Moreover, this function is unused: neither Hackage nor GHC refer to it.

Well there are plenty of projects not on Hackage though :)

The code itself is prone to be broken in future, because it relies on an internal API (there are actually ideas to back ByteString by ByteArray# instead of ForeignPtr).

Interesting, Wouldn't this represent a regression for code that read from an I/O source. Currently the I/O manager can feed bytestring efficiently from a native pointer that's maintained from the Buffers inside GHC. By forcing it to use a ByteArray# that would require moving memory from the C side to Haskell would it not?

It would seem to me that bytestring would always require a way to create a binary representation from an unmanaged pointer...

That said I have no problem removing this function as it's functionality questionably shouldn't be in Win32 anyway which is meant to just be a low level interface to platform APIs. It would however in the grand scheme of things be very unfortunate not to be able to use bytestring...

from win32.

Interesting, Wouldn't this represent a regression for code that read from an I/O source.

Practically speaking, this particular change is not gonna happen any time soon. There is an ongoing discussion at haskell/bytestring#193, feel free to chime in. My point was more about relying on internal API in general.

That said I have no problem removing this function as it's functionality questionably shouldn't be in Win32 anyway which is meant to just be a low level interface to platform APIs.

Would you like me to raise a PR?

from win32.

Would you like me to raise a PR?

If you would that would be grand :) Thanks!

from win32.