Welcome! Please see the About page for a little more info on how this works.

0 votes
in Java Interop by

The > function is inconsistent wrt to their behaviour for 0 arity.

`

user> (doc >)

clojure.core/>
([x] [x y] [x y & more])
Returns non-nil if nums are in monotonically decreasing order,
otherwise false.
nil
user> (> 3 2)
true
user> (> 3)
true
user> (>)
ArityException Wrong number of args (0) passed to: core/> clojure.lang.AFn.throwArity (AFn.java:429)
`

This is mostly likely to become problematic when using > via apply where

`
(or (= 0 (count l))

(apply > l))

`

It seems that the documentation should be updated, 0-arg case should return true, or the 1-arg case should also throw an exception.

This affects the other comparators also.

2 Answers

0 votes
by

_Comment made by: roberttweed

As per my original post on this (here: https://groups.google.com/d/msg/clojure/8zkpO9FBN64/u2LAQsR93IgJ), while the question of whether an empty set has monotonic order perhaps has more than one answer in theory, from a purely pragmatic engineering perspective, it makes the most sense to evaluate to true here.

This /should/ not be a breaking change. Therefore it is fairly safe to introduce into a minor revision. It's a also a trivial fix. But it is possible (though highly unlikely) that someone could have code that depends on the exception being raised at runtime (as it does now) to handle empty lists in some special way. Such code is horrible and ought to be rewritten, so should not be seen as justification for retaining the current behaviour, which limits the general usefulness of these functions and may be responsible for subtle bugs in existing production code.

However such a change should probably not be backported to existing 1.6.x branches, just to be 100% safe, since it is not a security issue. My suggestion therefore would be to add a note to the docs in existing maintenance branches (any future 1.6.x) and evaluate to true in future versions (1.7+).

0 votes
by
Reference: https://clojure.atlassian.net/browse/CLJ-1526 (reported by alex+import)
...