-
Notifications
You must be signed in to change notification settings - Fork 82
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
Remove false COMPLETE statement #248
Conversation
I think it's useful tbh? Anyone going to the trouble of making a case statement with all twelve month names is likely already working with a For example, any |
Parse, don't validate. That's what the sum type would have been for, but if you don't want it then we should at least not lie to the compiler by saying that |
For the time library I've broadly prioritised usefulness and simplicity over type-safety. But I'll consider this PR if you have examples of the COMPLETE pragma causing an actual real-life code defect. ...or can even plausibly imagine someone being tripped up by it. |
As an example of the cost in simplicity, consider two scenarios:
|
Please re-open this. While I have some sympathies for the arguments against #134, this makes no sense to me at all. I can't think of any other Haskell library where pattern-matching can fail at runtime with no warning and without using any obviously unsafe functions. Yet here we have, for example, the innocuous-looking: f = case minBound of
January -> ()
February -> ()
March -> ()
April -> ()
May -> ()
June -> ()
July -> ()
August -> ()
September -> ()
October -> ()
November -> ()
December -> ()
If you're not convinced, I'm happy to run a poll on Haskell Discourse or something. I'm pretty certain that the vast majority of the community would consider 313bd8f a horrifying abuse of the |
That doesn't look at all innocuous to me, I can't imagine anyone actually writing that in code. As I said, I'll consider this PR if you have examples of the COMPLETE pragma causing an actual real-life code defect. |
When I ask GHC to make any non-exhaustive pattern an error, I expect that I'm safe on that front when there is no error. I would be pretty pissed to have made that effort and to have a runtime error blow up in the face of my users anyway. |
Given that it looks like #134 is not going to happen, and it looks like #246 and #247 won't make it in, the least we can do is remove a false
COMPLETE
pragma.