-
Notifications
You must be signed in to change notification settings - Fork 195
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Warn on use of unsafe decodeUtf8 #1280
base: master
Are you sure you want to change the base?
Conversation
cd5e753
to
772014d
Compare
Thanks for the patch. As a general rule, the RHS should be equivalent to the RHS - in this case However, if |
That's fair, a deprecation would be better. I'll raise it again, but I'm not hugely hopeful. I guess I am effectively asking for a back-door deprecation via hlint. It's fair enough if you'd rather leave that to upstream, but I do think it would be a service to the ecosystem to start nudging people to avoid it. (This was prompted by me discovering a use of this in an upstream library that rendered a nominally-pure parsing function impure - and thus vulnerable to malicious input. It's quite a nasty problem!) |
Another thing worth mentioning is that even if it gets deprecated in |
If you get upstream agreement, even to mark it with a documentation comment saying "don't use this", that's enough to make it clear that HLint should warn against it. Happy to use HLint to backport these suggestions. |
The text maintainers seem to be active once more, with new releases, so you might have more chance of getting a response from them now. |
I hadn't actually considered that `decodeUtf8` must be partial until stumbling across ndmitchell/hlint#1280. It would actually be very odd for us to hit this in practice, so there's no need to do more sophisticated error handling. The string passed to `fail` will end up in a thrown `LifxError.DecodeFailure`. The impossible case covers a deprecated constructor. When it is finally removed, we'll get a warning prompting us to remove the redundant wildcard.
decodeUtf8
throws an exception, this is quite unexpected. There has been various discussion about this over time:decodeUtf8
/decodeUtf8'
situation haskell/text#247However, I think many people are unaware that this is partial - it doesn't look partial. So a hint is helpful.
I'd like some feedback, though: it's not clear to me what the RHS of such a rule should be. In particular, I don't know whether it's expected to typecheck. The "simplest" rule is what I've written here: replace
decodeUtf8
withdecodeUtf8'
, but the latter has a different type. I could instead make the RHS something like\bss -> case decodeUtf8' bs of { Left e -> error "fixme"; Right t -> t }
?