Closed hasufell closed 1 year ago
Overall looks good. @vdukhovni could you please take a look?
@vdukhovni @hs-viktor @hasufell is there any conclusion? We have to make a release soon, to accompany GHC 9.8.
We haven't come to a conclusion wrt ioe_filename
and I was actually planning to consult with GHC devs about this. Or even CLC. It's not clear what the API of this record is to the end user.
Based on that, we can more easily decide what to do.
I don't feel very strongly about encoding choices, but I am quite adamant about error values not containing bottoms. Pick the encoding strategy that will be least surprising, and never ever have any of the fields of IOError throw when forced.
When working with paths that are ByteStrings, if they make sense as UTF8, assume they're UTF8, otherwise raw? Assuming the default system filename encoding (as suggested) is another. No encoding choice will be always right, we simply don't know. Part of the reason the IO operation failed, could well be a poor choice of encoding... :-(
but I am quite adamant about error values not containing bottoms
Yes, as I explained above, the current code using TransliterateCodingFailure
never throws.
Whatever we do, we have to document it in base, IMO: https://hackage.haskell.org/package/base-4.18.0.0/docs/GHC-IO-Exception.html#v:ioe_filename
It'll be utterly confusing to end users otherwise, looking for the properties of this record field.
We haven't come to a conclusion wrt
ioe_filename
and I was actually planning to consult with GHC devs about this. Or even CLC. It's not clear what the API of this record is to the end user.Based on that, we can more easily decide what to do.
AFAIU this is no longer a blocker, right?
Correct. I need to update the PR.
Should be settled.
Follows:
@bgamari @Bodigrim