Can I add it to scoop? #scoop

This release includes some changes to var interning as per the post. While we have thought of and tried many scenarios, it is hard to tell if we found them all. We really would appreciate you giving this a try early while you're developing and reloading etc to see if you encounter anything unexpected and drop us a question at https://ask.clojure.org if so.

Updating deps.edn at work to test it... 🙂

Exciting!

Alex, would you say that this reflects a desire from the core team to shift toward smaller and more frequent new versions, or is that just how it happened to turn out this time?

We always desire smaller and more frequent versions, we’re just sometimes better at succeeding :)

Does CLJ-1872 mean (seq coll) is not going to be an idiom for (not (empty? coll)) going forward?

@U08BJGV6E The empty? docstring has been updated: "To check the emptiness of a seq, please use the idiom (seq x) rather than (not (empty? x))"

Does this mean that clj-kondo should not warn on (not (empty? ...)) anymore unless it knows 100% sure the argument is a seq already?

It does sound like to me that going forward, (not (empty? coll)) should generally be preferred in cases where you don’t want to make any assumptions wrt what coll is

Maybe I'll just remove the linter then or disable it by default.

Do note that I’m not on the core team (yet 😄) so I’m by no means a good source of information, I’m just speculating

feels like Christmas in July 🙂

Well this is an alpha1, so I wouldn't go run around changing anything yet

I think I'd flip that advice around and say that when you DO know you have something counted like a persistent coll, it is better to build a conditional on empty? than seq (esp if you are not doing anything else with seqs). If you are in a seq context, then keep using seq.

Generally I arrange the branches of the condition to not use not in either case if possible

So do I. I just find that there is a bit of an imbalance introduced here, with idiomatic (empty? x) being extended onto non-seq xes, but the so-far-idiomatic nonempty? check (seq x) isn’t. empty? is now generic across seqs and counteds but there isn’t a similarly generic counterpart I feel.

Maybe Clojure can have a (not-empty? ...) predicate which does the right thing for the right type.

Backwards-compatibility isn’t affected as far as I can tell, but it might be surprising in new code that relies on empty? supporting counted colls that aren’t seqable

Well there’s not-empty

And then this debate can be over :)

true

Maybe not-empty should be based on empty?

I think the difference is seqs have nil punning, other colls don't

So it's not symmetric

My vote would be on maintaining symmetry

symmetry of what?

vote on what?

not sure what you're even advocating

Apologies Alex, I misread your reply. Allow me to clarify

I think basing non-empty on empty? is a step in the right way. Note that it would still result in double negations in the seqable branch. Implementing a notempty? or not-empty? similarly to the new implementation of empty? could save that. Really what I’m looking for is the ‘one idiomatic way’ of checking both. Pre-1.12 that would be empty?/`seq`, from 1.12 it could be empty?/`x` where x is one specific function/macro and not a conditional expression.

(defn populated?
  [coll]
  (boolean (not-empty coll)))

I tried hard to come up with a word that didn't include not in the name. The internet suggests populated, occupied, and cherished 🙂

I think I prefer not-empty? ;)

Come on, what's wrong with cherished?

I'm disappointed in the English language here. We have "nothing", "something", and "everything", mapping to "empty", <go fish>, and "full".

Well, we have *, ? and + in regexes to denote 0 or more, 0 or 1 or 1 or more. So why not use: (+? coll) , that seems like an excellent choice to me... 😁