> > Debug.crash is used when you know a condition is impossible. >
I've gone back and forth on whether I think this is a good idea. On the one hand, it's nice documentation for people looking at your code. On the other hand, if you have reasoned incorrectly about your code (I don't think you did, but *if*), and that branch is reachable somehow, then you are ensuring your program responds to the bug in the worst way. If the code is truly unreachable, you can put whatever you want there ... maybe make it the identity function instead. You're right, though. This is a separate use case. But the reason Debug.crash is in core at all is for prototyping. Of these two use cases, it seems the unreachable code scenario is the one which is begging for a better solution. On Thu, Sep 1, 2016 at 5:21 PM, Max Goldstein <maxgoldste...@gmail.com> wrote: > Debug.crash is used when you know a condition is impossible. I have a > library where I sort a non empty list and do case analysis on the result. I > call Debug.crash on the empty list case. It can't happen because sorting > doesn't change the length of the list, but building that into the type > system is way to complicated for Elm's goals. > > Language and tooling features are focusing on "making impossible things > possible" not "making possible things pleasant", so Debug.todo is unlikely > to get implemented anytime soon. But I think it's a pretty neat idea! > > -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to elm-discuss+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
