today the contract for sequence functions is seqable? to seqable?, whether map returns () or nil is not something you should be thinking about

any opinions on this @mfikes or @slipset?

(if (map a-fn coll) (do-something) (do-else))

Of the top of my head, I’ve thought map returns (s/nilable seq?)

That is correct, it is part of a contract though? - yeah minus nil

Actually, perhaps nix the nilable part

that’s the question. also: should we consider different return specs for different seq functions, or treat them under the same contract

Is the rough idea seqable? in, seq? out?

@mfikes given that () or nil may be treated as the same value (punning), the question is: is this important enough to spec differently

Trying to think of things that might return nil…

@mfikes start reading here: https://clojurians.slack.com/archives/CDJGJ3QVA/p1547221885081900

map, remove, filter can't return nil - I think it is a bug to write code that relies on them returning nil. If that changes in the future, so will your execution

you are turning things around: you should not rely on them to return () instead of nil, that should be un-important

since empty seqs can be nil-punned

so you should not rely on them returning a more specific value than seqable?

there are no such things as empty seqs

I think

’()

isn't that an emptylist?

(seq? '()) ;; true

anyhow, I am attacking this mostly from ide tooling angle. I would like to be able to mark code doing (if) on the return of a map as incorrect

Another example where this is relevant:

(re-seq #"\w+" "")

@andreas862 as @alexmiller pointed out, you should always call seq on a sequence if used as a truthy value

Another example where you shouldn’t rely on seq? “Returns a sequence of values”

(vals nil) ;;=> nil
(vals {}) ;;=> nil

My argument has always been about the ones that I classified as not nil-punnable. map, filter, remove etc. I did know about some others returning nil

But have to say that I do probably use some nil return directly

have a lot of code to fix

probably re-seq, not sure about the rest

you were depending on re-seq being able to return nil, despite the docstring?

I think in that case you should use re-find

if you want to check if there is at least one match

not that sure about re-seq, have to check. But there is a big risk that I would use one of them if I found that it seemed to leave nil for empty.

We already discussed this in the very start of speculative: https://github.com/borkdude/speculative/issues/45 That’s why we made it seqable? in the first place. Sorry I forgot about this @andreas862. Should have remembered when I merged the change.

a non-nil seqable isn't invalidated by that issue.

seq? goes out the door though

For now I reverted back to #45. Any changes to this we should discuss in that issue or at least keep the most important notes there, so we can fall back on that.