It seems to be also the case for all Dict implementations that support any key type (all the ones I looked at use a k -> comparable function argument for Dict.empty), for example elm-dictset or any-dict.
A known rule of The Elm Architecture is to never put functions in your Model or Msg types, so I wonder what are the exact impacts in 0.19 to do so.
I guess it would break the debugger serialization and therefore import/export/time travel, but I would like to know if there are other consequences like those discussed in 0.17 concerning equality tests?
Could this break Html.Lazy? Could this break dicts comparisons?
My intent is to know if it should be really avoided to use these kinds of types in the model (which would severely limit their usefulness).
There was a related discussion a few months ago concerning functions in messages but I don’t think that this gives all the answers:
I have been using k -> comparable based data structures and did not really stop to think about the implications of putting functions in the model that result from it, so it interesting to raise the issue.
I think debugger import/export would be broken, but generally not the debugger or time-travel. That simply retains references to older versions of the model and does not, so far as I am aware, need to serialize them.
Similarly, Html.Lazy compares by reference, not by value, so should also not be broken.
Its not recommended practice to put functions in the model, but I don’t think the consequences of doing so are so bad.
I do feel that it would be very beneficial to get the hash tables @robin.heggelund was working on into elm, to replace these k -> comparable dicts with.
It’s a lurking potential runtime crash if you ever compare such structures for equality because comparing non-identical functions for equality throws an exception. Given the choice between being able to build dictionaries with keys that the compiler can’t know are comparable and making widespread use of equality comparisons, I opt for the former and risk the runtime crashes. (I also mostly know that the things I do compare for equality will be using the same functions and so aren’t really a danger but my early Elm code did have places that would crash seemingly randomly because of an equality comparison on functions.)
There is no problem with Html.Lazy because it uses reference equality rather than structural equality.
Could the situation be improved by always having an equality on functions evaluation to a Bool (even if it is always False)? At least no runtime exception.