:reduce-without-init false-ish positive

[vemv]

(reduce into [a b c]) does not seem possibly subject to the pitfall that is guarded by :reduce-without-init.

My reasoning being that [a b c] is known at compile-time to be a coll of > 2 elements.

WDYT?

[vemv]

Another interesting case is reduce + coll. + has a explicit "arity 0" that returns 0.

So if we know at compile-time that reduce is being passed + as its first argument, then similarly there's no pitfall to guard against?

Edit: that's not the precise reason, but regardless reduce + coll seems always safe, whether it's [], [42] or more.

[borkdude]

@vemv I think in these cases we could relax this linter:

1. Invoked on a statically known coll of size >= 1 (i.e. non-empty)
2. Invoked on function which implements 0-arity function (this is most likely returning the identity element)

[vemv]

Cheers. The case for 0-arity might need some extra consideration:

(reduce (fn
          ([]
           1)
          ([a b]
           2))
        [:a])

...this fn has a 0-arity, but no arity is ever invoked here, which is the root problem that the linter is trying to prevent, afaict.

I would say that the reason why reduce + coll is always safe is because + can be considered type-preserving: numbers in, numbers out. Which implies that not invoking + is equivalent to invoking + with 1 argument. The same cannot be said of str.

[borkdude]

Yes, so the function should have:

1. a 0-arity which returns the identity element
2. a 1-arity type preserving overload (probably identity in most cases)
3. a 2-arity type preserving overload

(i.e. monoid stuff https://hackage.haskell.org/package/base-4.16.0.0/docs/Data-Monoid.html)

[borkdude]

@vemv We could make a hard-coded list of excluded functions like + and * and an option :exclude to add more of those that are known to be safe. Not sure if we could do this entirely automatically (as we don't have the means to law-check the monoid-properties of an inferred group).

[vemv]

SGTM! Thanks for the hammocking.

[borkdude]

Btw, (reduce max []) and (apply max []) both suffer from the same problem so warning about that seems closely related to this linter.

[borkdude]

One more thought: even when a collection has more than two elements, it isn't always safe to use with reduce, since sometimes the init value is a map or so, and then args are other types, like numbers.