The last major outstanding package is directory. The maintainer said they will try to update it in time for GHC-9.6. Until then, refer to my branch https://github.com/hasufell/directory/tree/AFPP
The only other package I will migrate myself is hpath, which will then probably be the first strongly typed filepath library that uses OsPath under the hood (current WIP branch is here).
That will be it from my side. Anything else is up to the community to do.
If anyone wants to get this into base (at least the type), you have my support. But I won’t drive that myself.
I see. System.OsPath.MODULE_NAME.Internal.fromString makes use of unsafePerformIO, and so System.OsPath cannot be ‘Safe Haskell’ but it can be declared by its authors to be Trustworthy.
If the authors can properly make that declaration, then it seems to me that some users of filepath may find it useful.
Edit: I’ve added ‘properly’ in the light of the subsequent comments, to clarify my intended meaning.
Could these unnamed users explain how they benefit from Safe (aka unverified code with unsafePerformIO hidden under Trustworthy) Haskell first? I think we all will be much better to stop participating in this safety circus.
Here is a recent example: Data.Array.Byte. The code was ported from Data.Primitive.ByteArray, so it should be as Trustworthy as possible. I originally opposed to marking it as such, but was persuaded otherwise on the grounds that there is literally nothing unsafe you can do with the API provided, because, well, there is no API, right? And that’s how it got released.
stimes i arr
| itgr < 1 = emptyByteArray
| itgr <= (fromIntegral (maxBound :: Int)) = replicateByteArray (fromIntegral itgr) arr
| otherwise = error "Data.Array.Byte#stimes: cannot allocate the requested amount of memory"
where itgr = toInteger i :: Integer
The truth is that the code as written is gullible to integer overflow. Carefully chosen offsets allow any of your dependencies to modify memory of the main program, which defeats the very purpose of Safe Haskell.
Since that mishap I insist that code can be marked as Trustworthy only if it was formally verified.
…as alluded to by the documentation for copyByteArray:
-- Note: this function does not do bounds or overlap checking.
something which the advocates for stimes (somehow) failed to notice. As for it’s formal verification:
it would appear to be needed where copyByteArray is being used, analogous to errantly using 0 with div - perhaps when we all have quantum computers at our disposal…