Sean Corfield <s...@corfield.org> writes: > Undefined behavior is deliberately very broad
I acknowledge the value of having undefined behaviour, implementation-defined behaviour and unspecified behaviour in an implementation, and I embrace that approach. However, none of those are distinguished on the spec, which only limits itself to saying things like "is not legal", where "legal" is also unspecified. So we have to stretch that a bit and interpret what is forbidden, undefined, unspecified, etc. > a system can silently accept > erroneous input with any outcome it chooses or it can dump core or launch > missiles. It's generally the user's responsibility to ensure they do not > provide erroneous input. You're right on principle here, but there is this really fine distinction between exploiting on the implementation-defined behaviour and relying on implementation-defined behaviour. I can already see using an edn implementation other than clojure.edn reporting a bug saying "implementation X can't process all edn that clojure.edn does". The answer to that is also what you said: implementation X is also correct, and the user is responsible to stop feeding erroneous input. That's a WONT_FIX, because it isn't a bug. All of that said, it is probably true that what I called "not being spec compliant" isn't a bug, but rather implementation details that leak up, and it wouldn't merit a patch to "match the specification". Thanks for the response. It helped me get a clearer view of the value proposition of the specification. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/878sbye623.fsf%40euandre.org.