> f it helps anyone sleep better at night, were the behavior of distinct ever > to change in a way that breaks one's application, the original one is right > there in the git history, available for everyone's copying and use, with > whatever promises in the doc string you choose to add.
I understand it is easy to just fix it once it breaks. The point I had is just that without a guarantee it's an assumption. And if you don't think about it and it later changes, it can be subtle and hard to find. This actually came up as a discussion with my coworkers one day. Someone mentioned Clojure doesn't seem to have any clear contract around if distinct preserves order or not. And I had a hard time arguing that you can "just trust it" since it doesn't really state that it does. So the main suggestion I'm getting is to just write my own test for this sort of assumption to avoid issues. I'd prefer some sort of doc or a generalized idea that all seq consuming, lazy seq returning functions build in a order preserving way. If that makes any sense. (I'm thinking like map and filter and so on relate to this idea). It's not really a big deal. Just a discussion I had come up "in the wild before". -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
