Hi splondike, I disagree with your arguments about what is sensible -- *any* behavior is sensible when you violate the contract of an API.
Of course everybody could get behind the "throwing the error" plan if the cost of throwing that error was zero: zero assessment cost, zero development cost, zero runtime cost, and zero maintenance cost. But those costs are not zero, so as a screener I have to ask myself "should I spend my next half hour looking at this issue, which impacts only broken programs, or one of the (currently 20) screenable tickets, many of which impact *correct* programs? That said, perhaps core.typed can help us here. I believe core.typed can allow us to check programs and detect these kinds of errors, without runtime impact (and without any change to Clojure at all.) I am doing some experiments with exactly this case, and will follow up on a separate thread. Regards, Stu On Mon, Sep 30, 2013 at 2:20 PM, splondike <splond...@gmail.com> wrote: > Thanks for the comment. The current behaviour is sensible for the code > branch where the second argument is the same length or shorter than the > first (see my first post). It is the other branch that does not do what you > would expect. My real issue though is how the behaviour changes > dramatically once we hit this branch (for non set args). > > The original author of the > patch<https://github.com/clojure/clojure/commit/60e805dc7bd42b7b26fc8c8925bf71079729e0e6>which > produced this behaviour noted > this shortcoming himself <http://dev.clojure.org/jira/browse/CLJ-67>, and > only refrained from implementing the check due to being unsure about the > performance penalty. > > I think that people who are currently relying on this function working for > non set arguments are playing a risky game (which, like me, they're > probably not aware of) due to this sudden change in behaviour. I would > argue that existing users would be better served by having an error thrown > rather than having unexpected data generated which is hard to track down. > > On Sunday, September 29, 2013 7:05:17 PM UTC-4, stuart....@gmail.comwrote: >> >> I think the bar for such an enhancement is fairly high, and the value >> delivered fairly low. It isn't so much the impact of assessing this single >> change, as the impact of managing the universe of such changes. >> >> Regards, >> Stu >> > -- > -- > 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/groups/opt_out. > -- -- 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/groups/opt_out.
